Mysterious "Follina" zero-day hole in Office

The latest is the Qbot ATP group has jumped on this vulnerability in earnest:

https://www.bleepingcomputer.com/ne...es-windows-msdt-zero-day-in-phishing-attacks/

 

That is my primary fix for the moment. As was referenced by both myself and itman this can be exploited by the preview pane in explorer from an RTF without even opening the document so based on that I have to conclude that something like blocking child processes in Office may counter some of it but not in that specific instance. I assume deleting the registry keys kills the functionality of these links and should be the most effective thing. Unless I am wrong. Which is also possible. In any case it would be nice if Microsoft would release a fix. Preferably one that actually works.

 

For anyone that wants to make the registry edits without going into the registry you can paste the following into a batch file and run as admin. Feel free to change the location of the backups or the names of them as desired:
reg export HKEY_CLASSES_ROOT\ms-msdt C:\msdt.reg
reg delete HKEY_CLASSES_ROOT\ms-msdt /f
reg export HKEY_CLASSES_ROOT\search-ms C:\search-ms.reg
reg delete HKEY_CLASSES_ROOT\search-ms /f

 

Found a .doc sample of Qbot deploying Follina exploit. Since I can't post VT results here, I can't post link showing behavior. So you will have to "take my word" that Qbot is using iexplore.exe to start msdt.exe via mshtml.dll I assume.

-EDIT- In a "brain cramp" moment, I forgot I can post a screen shot of the path:



Checksums are:

MD5 e7015438268464cedad98b1544d643ad
SHA-1 03ef0e06d678a07f0413d95f0deb8968190e4f6b
SHA-256 d20120cc046cef3c3f0292c6cbc406fcf2a714aa8e048c9188f1184e4bb16c93

 

but you can post the checksums ...

 

Thanks I appreciate it. I have also used ESET HIPS rules to block child processes from MS Office apps as well as msdt.exe. Hopefully that adds a bit of extra protection.

Side note, I see your batch file. We have to do something with the search key in the registry? I only did the msdt one.

 

It was recommended on a couple of sites I saw as an additional workaround. I have done it on a dozen PCs and nobody has complained of any issues.

Edit: For reference
Here is how to protect Windows PCs from Protocol vulnerabilities - gHacks Tech News

 

And don't forget Sdiagnhost and regsvr32 (kinda like Whac-A-Mole to chase things this way).

 

Yes, already mentioned previously. Looks that that reference of mine was "another shot in space ........."

 

Thanks I will check it out.

 

As far as what. Blocking child processes?

 

I know you didn't ask me but as those are executables probably blocking them altogether.

 

Would we set this up the same way with ESET HIPS rules? Would it be setup for all applications I assume?

 

They are also part of this infection chain, separately but equally involved in the downloading of the payload from various places in Europe, Korea, and Thailand (depending on the specific variant).

 

At first announced discovery for me this didn't seem to have but as some infections, a temporary run easily or at least soon enough stalled out. But after it taking on half a dozen other characteristics, makes you wonder why they last and then the scramble is really on to plug as many forks they can use to keep the spread at a minimum. Clever stuff sometimes these creations.

 

I created a HIPS rule to block startup of C:\Windows32\conhost.exe from C:\Windows32\sdiagnhost.exe. The problem with this is will also abort running of all Win 10/11 troubleshooters. You will receive a like message in the troubleshooter popup window. As such, you might as well use ghacks.net GPO change that does the same thing.

You could make the HIPS rule an ask rule. However, you have to have the "smarts" to select block action in the Eset popup window if the alert appears when not manually running a troubleshooter.

What is needed here is the capability to monitor C:\Windows32\sdiagnhost.exe -> C:\Windows32\conhost.exe -> any process startup which Eset HIPS doesn't have.

 

Thanks that is what I did, I wanted to be sure I was on the correct track.

EDIT: Disregard I found the GPO on their website. Thanks!

 

If someone at works gets exploited by this the next SRP rule is going to be a block on "*".

 

I hear you. It is getting ridiculous.

 

Add AsyncRAT and Infostealer to the list of exploiters:

https://symantec-enterprise-blogs.s...eat-intelligence/follina-msdt-exploit-malware

 

A good read. Thanks for posting. I hope the security companies are on top of this. The OS vendor does not seem to be.

 

Amen to that.

 

You also need to apply MS reg. fix for ms-search UI protocol handler abuse: https://borncity.com/win/2022/06/02...ms-uri-handler-0-day-exploit-mit-office-2019/ .

And the reality of the situation is other Windows UI protocol handlers have been abused in the past as I have previously posted.

 

Already done. Plus the post you quoted was pretty much a joke as a wildcard SRP block would stop everything from executing. Sorry if that promoted any confusion.

 

This was also reported by Avast in a June 3 2022 analysis.
It gives a step by step breakdown, screenshots, and IOCs.

Outbreak of Follina in Australia

by Threat Intelligence Team
June 3, 2022

https://decoded.avast.io/threatintel/outbreak-of-follina-in-australia/

"This threat was a complex multi-stage operation utilizing LOLBAS (Living off the
Land Binaries And Scripts), which allowed the attacker to initialize the attack
using the CVE-2022-30190 vulnerability within the Microsoft Support Diagnostic Tool.
This vulnerability enables threat actors to run malicious code without the user
downloading an executable to their machine which might be detected by endpoint detection.

Multiple stages of this malware were signed with a legitimate company certificate to
add additional legitimacy and minimize the chance of detection."

...

"Final Stage, AsyncRat"