Mysterious "Follina" zero-day hole in Office

The important point to note is how this malware payload was downloaded and executed:



Bad choice here by the attacker since this payload is detected by the major AV's.

Also of note is OSArmor by default blocks all .exe's running from C:\Users\Public directory.

 

You can use SRP to block as well. I made Path rules for %PUBLIC%\*.EXE and %PUBLIC%\*\*.EXE. Not sure the first one isn't redundant but it all works as expected so I'm moving on from here.

 

I'm not saying this is not a serious exploit, because with this one you don't even need to enable macro's, however most of these exploits can be tackled by monitoring child process execution, and even by network monitoring, it would be nice if this was mentioned more often in these articles.

What firewall are you using? You should check out WFC, which is a frontend for the Windows Firewall and TinyWall, which is a standalone firewall. Both will automatically block ALL outgoing connections and you need to create exceptions for apps who need a network connection. Of course they will both make automatic rules for Windows Update, Win Defender and other Windows services. Keep in mind that both won't protect against malware that's using code injection to bypass firewalls, so you still need to cover this with behavior blocker.

https://www.binisoft.org/wfc
https://tinywall.pados.hu

 

What on earth are you talking about? It seems that you are overthinking things, it has already been confirmed that by simply blocking MS Word from the ability to create child processes you have blocked this whole attack. You see, that's exactly my point, there is so much information in all of these articles that some people get confused.

At the end of the day, all exploits work about the same, they try to download a malicious payload from remote by exploiting for example the browser or document reader. So if you block that malicious payload from running via whitelisting or process execution control, it's game over for the hacker. It gets more tricky when hackers are using in-memory payloads, but you almost never get to see this, and this can also be tackled with tools like HMPA and MBAE in certain cases.

 

Yeah ........... Refer to this: https://twitter.com/SECFORCE_LTD/status/1531987722293886978

 

I also found this very long blogcast: https://www.youtube.com/watch?v=dGCOhORNKRk that gets into details that haven't been mainstream publicly disclosed.

He does answer Proofpoint's question as to how ms-msdt UI protocol handler can be exploited to perform what is going on. Normally, use of this protocol handler within an MS Office executable would result in a password entry window being displayed; a sure sign something was amiss. Well, the original attacker definitely spent some time developing this exploit. It turns out that if the command line string is leading padded with 4096+ bytes of nonsense characters, it will invalidate the password protection mechanism built in to ms-msdt UI protocol handler. That is the vulnerability.

 

Your point is well taken, It's right. @Rasheed187 made some comparisons as well that bare fully understanding the preventions available to thwart and minimize this particular strain.

Interesting podcast @itman. We haven't heard the last of this one yet.

 

As far as blocking child process startup from winword.exe and in regards to a .rtf version of this exploit, this posting by Will Dorman on twitter on May 31 is self-explainatory:

https://twitter.com/wdormann/status/1531703613642395651

Note that mshtml is a .dll.

 

thanks for sharing.

 

Excellent. Thanks on passing that along.

 

Interesting ... 4096 = 2¹²

 

"Microsoft won’t say if it will patch critical Windows vulnerability under exploit [Follina]

Slow to act on the code execution bug from the start, company is still in no hurry.

As hacker groups working continue to hammer a former Windows zero-day that makes it unusually easy to execute malicious code on target computers, Microsoft is keeping a low profile, refusing even to say if it has plans to patch..."

https://arstechnica.com/information...critical-windows-vulnerability-under-exploit/

 

So what is your point, you still don't believe that blocking winword.exe from creating child processes will tackle this? I really believe you are overthinking things. It's very simple, if winword.exe can't load msdt.exe it's game over, I don't know why you think otherwise. This is exactly how a tool like OSArmor tries to tackle for example browser exploits. If browser processes like firefox.exe or chrome.exe can't execute the payload which is malware.exe, then it's game over.

 

In addition to that:

Full article here (hopefully someone else hasn't already posted it):
Zero-Day 'Follina' Bug Lays Microsoft Office Open to Attack | Threatpost

 

I am again going to refer to my previous posting here: https://www.wilderssecurity.com/thr...day-hole-in-office.445491/page-2#post-3086251 that noted that msdt.exe can be abused withstanding this current Follina vulnerability.

Here's an example of this: https://twitter.com/j00sean/status/1533879688141086720 . The attack is summarized as:

At the end of the attack process, he uses msdt.exe to run his malware .exe via command line input.

Again, the Follina vulnerability for msdt.exe is not deployed in this attack.

Bottom line - the only way this type of msdt.exe abuse can be detected is by using a security product that has the ability to scan command line input to msdt.exe such as OSArmor.

 

Yes exactly, but when it comes to protecting winword.exe, it should also be enough to simply block child process execution, see link. And again, if you block winword.exe and explorer.exe from connecting out, then how is this docx document going to connect to the attacker's server, which will download and run the malicious payload? Can you explain this? I don't know about you, but every word processor no matter if it's from WPS Office, Libre Office or MS Office, is blocked from making outbound connections on my machines.

https://twitter.com/buffaloverflow/status/1530887036550500352

 

Review the malware sample feeds for how the Follina exploit is being deployed. I already posted a .exe sample I have found. Also in existence are .ps1, etc. samples. Delivery via a Winword file is only one of many ways msdt.exe can be abused.

 

Yes, but we're now talking about the ''Follina'' Winword exploit, this guys seems to claim he has found another similar exploit, which can also most likely be blocked with a tool like OSArmor. And the discussion is about whether it's enough to block MS Office from creating child processes when it comes to tackling this Follina exploit, and you seem to imply it's not for some reason. I believe you are wrong about this.

 

Also to clarify overall what the Follina exploit does is allow the attacker to perform a remote connection and download via msdt.exe.

A local abuse of msdt.exe requires that the malware payload already exists on the local device.

 

I have to admit that this stuff can get confusing. Because I have also read that some guy claims that simply blocking msdt.exe from making outbound connections isn't enough. So I can understand why certain people think this exploit is a bit more dangerous than thought and not that easy to mitigate.

But I'm not sure about this, because as usual you need to monitor LOLBins for suspicious behavior and you need to block exploitable apps from the ability to create child processes and if possible the ability to make outbound connections. And on corporate networks this is probably a bit more tricky than on home user machines, but this has always been the case.

 

So if I follow @itman and yours @Rasheed187 point correctly on this particular exploit(s), OSArmor as well as additional fallback methods/programs additionally or redundantly protecting PowerShell can mitigate it effectively.

What I always find intriguing when such as these crops up and researchers blow the bugle to every outlet salivating to hold the top story on it, is that security preventions for MS Office and LOLBins seem should already been sealed via MS own in-house research security teams by now. Oh of course some minor vulnerability will always turn up. That's a given and the very nature in which Windows is coded.

The question always arises for me though why more tight restraints without affecting productivity can't seem to be arrived at natively. But then that statement is naïve given MS track record on patching after-the-fact or in this case proving elusive for them so far?

 

As far as child process blocking goes, first note that normal msdt.exe start up spawns sdiagnhost.exe as a child process.

As far this Follina exploit goes, it performs:

https://twitter.com/GossiTheDog/status/1531598227115745280?ref_src=twsrc^tfw

Ditto as far as I am aware of in other msdt.exe abuse cases.

Therefore, one can experiment using a HIPS, blocking child process startup from sdiagnhost.exe. This is also recommended here: https://twitter.com/KyleHanslovan/status/1531114931973767168 and here: https://www.pondurance.com/blog/follina-cve-2022-30190/ . I also suspect the key child process to be monitoring for is conhost.exe.

Also as I keep posting, we don't have to use an MS Office executable to deploy this exploit:

https://community.netwitness.com/t5...ecting-follina-cve-2022-30190-rce/ba-p/683866

BTW - are you blocking wget.exe outbound network traffic? I have seen it used in other malware attacks. I was blocking it until I had the OSArmor developer add it to OSA mitigations. Oh....., there's a signed version of wget that can be downloaded from the Internet.

 

I have not been following this exploit as closely as I should. I have done the recommended mitigation from MS with regards to the registry key. So is this not enough now? I guess something has changed? To date, that is all that they recommend. Can someone clue me in please? Thanks.

 

Add FoxIt PDF Reader to the list of exploitable apps: https://twitter.com/j00sean/status/1534115332830507008.

At least here you will get a popup about the remote connection but average user blindly mouse clicks through those.

 

Smackers- Thanks for the READ on it @itman. Wonder if someone can test SUMATRA too.

FOUND ON SAME ARTICLE-