Mysterious "Follina" zero-day hole in Office

Interesting stuff. Thanks for sharing.

 

I also came across this ghacks.net article that noted:

https://www.ghacks.net/2022/06/02/here-is-how-to-protect-windows-pcs-from-protocol-vulnerabilities/

I disabled troubleshooting wizards per Group Policy as noted in the article.

 

OK, thanks for explanation.

 

Thanks! I did it now also via Group Policy.

 

Same here, thanks. My Win 8.1 is free of this bug but 10 not.

 

Well, I wasn't talking about Outlook since it obviously needs to connect to the network, but MS Word doesn't on most systems. In fact, my whole strategy is to block most processes from the ability to make outbound connections, except for the ones who can't function without it like browsers, email clients and file downloaders. And no, I don't use auto-update functions of any app.

So isn't it true that when it comes to ''remote code execution'' exploits, the exploited app always needs to download malware from some server? But what if the exploited app and spawned system processes don't have the ability to connect out? Then how are they going to download the payload? Strange that nobody mentions this stuff, or perhaps I'm missing something.

 

Sounds like an interesting game of whack-a-mole. Maybe you can block it, if you know in advance how to. That may be a good use case for browsing in a Linux VM while blocking the host machine from doing so.

 

This article came out today courtesy WIRED.
https://arstechnica.com/information...icrosoft-0day-flaw-still-doesnt-have-a-patch/

 

I took another look at this attack and as I see it, the security researchers are missing the main issue.

Yes, the attacker came up with a "novel" way of invoking the ms-msdt UI protocol handler using a Word document as the delivery mechanism. However, the real problem is msdt.exe is a known Win trusted binary LOL attack mechanism as noted here: https://lolbas-project.github.io/lolbas/Binaries/Msdt/ . References for this go back to 2016. Also, an attacker can find other means to abuse msdt.exe as shown in the above Github reference;

"Executes the Microsoft Diagnostics Tool and executes the malicious .MSI referenced in the PCW8E57.xml file."​

This means that OSArmor really is your best defense against these known Win trusted binary LOL attacks. When I ran the example given in the Github reference via command prompt, the result was:

Date/Time: 6/3/2022 8:40:53 AM
Process: [3264]C:\Windows\System32\msdt.exe
Process Size: 421 KB (431,104 bytes)
Process MD5 Hash: 992C3F0CC8180F2F51156671E027AE75
Parent: [3676]C:\Windows\System32\cmd.exe
Parent Process Size: 283 KB (289,792 bytes)
Rule: BlockSuspiciousCmdlines
Rule Name: Block execution of suspicious command-line strings
Command Line: msdt.exe -path C:\WINDOWS\diagnostics\index\PCWDiagnostic.xml -af C:\PCW8E57.xml /skip TRUE
Signer: <NULL>
Parent Signer: <NULL>
User/Domain: xxxxxxxxxxxxx
System File: True
Parent System File: True
Integrity Level: Medium
Parent Integrity Level: Medium

 

As far as abusing Windows UI protocol handlers go, below are just a couple articles of the numerous ones that exist.

https://www.bleepingcomputer.com/news/microsoft/microsoft-disables-msix-protocol-handler-abused-in-emotet-attacks/

https://positive.security/blog/ms-officecmd-rce

-EDIT- Also, it is not just Windows UI protocol handlers that can be abused: https://parsiya.net/blog/2021-03-17-attack-surface-analysis-part-2-custom-protocol-handlers/

 

Even Defender with the corresponding ASR rule will block this, as confirmed by Andy Ful in another forum.



https://malwaretips.com/threads/new-ms-office-zero-day-evades-defender.114090/post-990899

 

This is good to know. I may switch back to Defender for now just because of this.

 

I think you are misunderstanding. Like I said, I'm sure in a corporate network it's a bit more tricky, since system processes like powershell.exe might need to connect out, but the way I have configured all of machines is to automatically block most processes from connecting out, except for the ones that really need it. You can do this with a tool like TinyWall, so no whack-a-mole stuff is needed. I mean is it really neccesary for apps like Word, Excel, Powerpoint to access the internet? And if you block them from doing so, how are they going to load the malicious payload? Do you catch my drift?

Yes, this is no surprise at all. Most of these exploits can be blocked by simply blocking suspicious child process from spawning. This has been the same since 2004 when I started using Process Guard, I really don't understand what all the fuzz is about.

 

And Andy Ful confirms this:

https://malwaretips.com/threads/new-ms-office-zero-day-evades-defender.114090/post-990812

He even mentions Powershell running in Constrained Language mode will block this threat:

https://malwaretips.com/threads/new-ms-office-zero-day-evades-defender.114090/post-990791

The man is gold

This is seen all the time in these type of articles, where they make these threats look like Doomsday events.

 

He sure is. Thanks for the link @wat0114

I am back on WD using ConfigureDefender set to High which is my normal. I am good correct? If not please let me know. I've been away for the past week and a half so I've been off the grid. Cheers and thanks!

 

You're welcome, Trooper.

I think High is more than adequate, but Andy can answer better than me, as he can also provide important details as well. Mine was set initially to Default, with additional settings enabled to put it somewhere between Default and High. I'm using OSArmor too, so that provides additional, arguably unnecessary, protection as well.

 

Understand @wat0114 I may hit him up over at MT just to see. Thanks!

 

Yes, this is a no-brainer, I see all of these MS Word exploits, but to me it's much ado about nothing. And I agree that security researchers sometimes go a bit overboard. Most of these exploits can be blocked with process execution and network monitoring. If that doesn't work, you can always block suspicious behavior like code injection, keylogging, loading of services and drivers, file access/modification and stuff like that. I'm not saying it's always this easy, but not every threat is a Doomsday event, like you said LOL.

 

Yes, sometimes these articles go a little overboard with the drama. In this case, though, there's a little smugness also because at first Microsoft blew it off, then reversed itself a month later and quickly came out with a work-around. It was a golden opportunity for some to harp on this unfortunate event, moreso when it was being actively exploited in the "wild" for some weeks already.

Schadenfreude re: Microsoft.

 

In theory, blocking child process startup from winword.exe should block this bugger. However, at this point I am far from convinced it would. Here's why.

To begin, this was a unique attack as noted below:

https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e

Note that msdt.exe is being started via cmd.exe via "Start-Process" criteria. That implies it is running as a stand-alone process; not as a child process.

Now the question is if cmd.exe is being launched as a child process from winword.exe? I have seen no sandbox analysis to date that shows such a relationship. Or for that matter, that cmd.exe was shown running at any time in the shown process execution hierarchy.

-EDIT- I just reviewed Dieder Stevens POC uTube video on this and winword.exe spawns a winword.exe child process which in turn, spawns msdt.exe. So blocking winword.exe child process startup would mitigate this attack. The question is if the WD like ASLR rule for this would block a winword.exe child process instance? I would think this would have been the first thing MS would recommend as a mitigation though ..................

-EDIT- Well, I missed the obvious on this one. This is an RCE attack. The above command code is being run remotely. That is why a second winword.exe instance is being spawned from the instance opened by the .docx file and msdt.exe spawned from it. As such, I can't see how this attack would be detected by any local monitoring of winword.exe child process startup.

 

Ok, I get your point now. That said, I agree more with the second line that was not a reply to me. Blocking child processes is a winner for stopping a lot of stuff.

 

As far as this statement goes:

Yes it is possible. It's called "Template Injection": https://attack.mitre.org/techniques/T1221/ .

 

An example of an active campaign underway:

https://thehackernews.com/2022/06/state-backed-hackers-exploit-microsoft.html

Now its fairly obvious that a .rtf file is attached to the Word e-mail. My past and current solution to .rtf file baloney is I have it disabled from opening in MS Word.

 

Well, I just found this exploit embedded a .exe malware sample: ~ Removed VirusTotal Results as per Policy ~ . Embedded within is the above posted cmd script. More detail here: https://twitter.com/StopMalvertisin/status/1533659744015368192 .

This confirms that monitoring of MS Office child process executable's is a moot point.

 

Thanks for posting all of your research on this as I do not have the time myself.