Mysterious "Follina" zero-day hole in Office

Zero-day vuln in Microsoft Office: 'Follina' will work even when macros are disabled

https://www.theregister.com/2022/05/30/follina_microsoft_office_vulnerability/

Mysterious "Follina" zero-day hole in Office - here's what to do!

https://nakedsecurity.sophos.com/2022/05/31/mysterious-follina-zero-day-hole-in-office-what-to-do/

 

Microsoft Office zero-day “Follina”—it’s not a bug, it’s a feature! (It’s a bug)

 

Which is it then? A feature that unwillingly became a bug? Or a bug in the feature? Dizzying stuff

 

"Chinese Hackers Begin Exploiting Latest Microsoft Office Zero-Day Vulnerability

An advanced persistent threat (APT) actor aligned with Chinese state interests has been observed weaponizing the new zero-day flaw in Microsoft Office to achieve code execution on affected systems.

'TA413 CN APT spotted [in-the-wild] exploiting the Follina zero-day using URLs to deliver ZIP archives which contain Word Documents that use the technique,' enterprise security firm Proofpoint said in a tweet..."

https://thehackernews.com/2022/05/chinese-hackers-begin-exploiting-latest.html

 

Would any of the applications that get regularly discussed over in the "other anti-malware software" sub-forum, be able to stop/prevent this attack?

 

Yes, according to this post:
NoVirusThanks OSArmor: An Additional Layer of Defense

 

I just made a batch file out of the commands for the workaround and ran it on each of the PCs. Just remember that where it says "filename" in the export command to specify an actual path and filename.

 

Thanks for the useful safety tip @xxJackxx

 

0Patch how providing free mitigation:

https://www.bleepingcomputer.com/ne...day-vulnerability-gets-free-unofficial-patch/https://www.bleepingcomputer.com/ne...day-vulnerability-gets-free-unofficial-patch/

 

Great, thanks for the info!

 

Hackers having a "field day" with this vulnerability. So far have seen .html, .rar, and a very interesting sample with no file extension which turns out to be a PowerShell script. My guess here is the attacker drops the unnamed file, renames it to a .ps1. Then points to the script in the msdt.exe command line input. Wonder if this could bypass OSArmor since it is scanning for malformed command line input to msdt.exe?

 

Dunno @itman but a very good question for them and the product. Probably an easy fix but as you say Hackers are having a "field day" and something tells me we're just picking at "scraps" right now. Those that suddenly only recently discovered.

 

The dev says the "basic protection profile" of OS Armor will block the Follina attack. One article claims this exploit has been used in the wild for the past "7 weeks." Microsoft reportedly was told of the vuln in April but closed the report, stating it was not a security-related issue.

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

 

Another exploit capability discovered: https://www.bleepingcomputer.com/ne...ro-day-added-to-microsoft-protocol-nightmare/

 

Another day, another batch file to roll out the workaround. That said, I'd rather do that than install unofficial patches that will probably have to be uninstalled again when an official patch comes out. Assuming one does.

 

BTW folks, the vulnerabilities in MS Office protocol handlers are far worse than currently disclosed. Here's an illuminating article on that: https://blog.syss.com/posts/abusing-ms-office-protos/ . At the minimum, the recommendations given in the Conclusion section at the end of the article should be applied.

I am strongly leaning toward just blocking via HIPS any child process startup from a MS Office executable.

 

I am considering the same. Any shortcomings of doing so that you can think of?

 

I am not a "heavy" MS Office user; occasional Word usage and that's about it. So I am not really qualified to comment on impact on let's say, the Enterprise environment.

The only way to determine impact would be to do so on a test device with a good mix of MS Office different files. Then open at least one file of each type. Overall though, I would say its not normal for a MS Office executable to be spawning child processes.

 

An example of how these current exploits would bypass EDR solutions is given here by existing Elastic's HIPS rule for monitoring MS Office executable child process startup: https://www.elastic.co/guide/en/security/current/suspicious-ms-office-child-process.html .

Hell, you might as well just block everything ........................

 

No surprise that OSArmor will block it, since it monitors for suspicious process execution. But what about simply blocking MS Office from making outbound connections, would that also be enough to tackle most MS Office exploits? Weird that nobody mentions this, or perhaps security researchers feel like it's too easy to bypass firewalls, who knows.

 

Wow, nice observation. It got me thinking about H_C, specifically the FirewallHardening module. There is a rule for the iterations of powershell, but not sure if this would be enough. The developer does say the exploit would be foiled if powershell was to run in constrained language mode.

But this is all after the fact, admittedly. The comments from Andy Ful are in the Malwaretips thread above. Very interesting.

 

That would thoroughly break Outlook and would likely do nothing to stop something that got in some other way.

 

What I find interesting is how PowerShell was used in this ms-msdt exploit.

You can clearly see PowerShell being used via the Invoke-Expression use at the beginning of the script code:

However, no where do you directly see any PowerShell.exe direct reference. Further, this anyrun.com analysis: https://app.any.run/tasks/713f05d2-fe78-4b9d-a744-f7c133e3fafb/ doesn't show PowerShell.exe every being executed. It appears only PowerShell sub-assemblies are only being invoked. In any case, firewall rules blocking outbound PowerShell.exe networking traffic would be ineffective against this exploit.