Mysterious "Follina" zero-day hole in Office

Although I personally am not interested in this zero-day, Andy Full, posted an interesting infection pattern:

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

MBAE has been shown to protect against exploit if sdiagnhost.exe is inserted into the processes to be protected (MS Office):

https://blog.malwarebytes.com/exploits-and-vulnerabilities/2022/06/faq-mitigating-microsoft-offices-follina-zero-day/

then add sdiagnhost.exe in MS Defender Anti-Exploit list you will get identical protection.

 

Well, this posting: https://malwaretips.com/threads/new-ms-office-zero-day-evades-defender.114090/page-3#post-992315 has a diagram courtesy of Cybereason finally "demystifies" this attack.

It is actually Powershell running via COM;i.e. sub-assemblies, that is running sdiagnhost.exe. And as posted above, it really is an exploit of sdiagnhost.exe. Since the Cybereason posting is in Japanese? I can't view the detailed explanation.

I does make me wonder if MS Security Center adding of sdiagnhost.exe to the Exploit apps list would help? And if so, what additional mitigation options would have to be enabled to stop it?

Also for those using a HIPS, would a rule preventing process modification of sdiagnhost.exe stop it? Testing would be needed here.

And as has been previously noted when this attack stated, Powershell Constrained Language mode also stops this attack by preventing the sub-assemblies deployed from running.

 

Well, it certainly seems to be quite a bit more complicated in its delivery chain than was initially supposed.

Not to be haranguing but this was initially posted on May 31st. Almost two weeks now. On top of that, I noted that this exploit has been used by actors for the past 7 (now going on 9) weeks.

Microsoft posted a workaround somewhat after finally whispering that "yes, it IS a security issue." After all these Windows 11 security requirements, news of active exploitation in the wild and millions upon millions of Office users: where's the fix?

Yet Edge browser gets all kinds of new stuff every week, it seems.

 

I took Andy Ful's advice and blocked msdt.exe in SRP rules.

 

Andy Ful is a Windows zero day's worst enemy.

 

I hold him in the highest regard for his expertise on computer security and the way he can explain it so it makes sense. And of course because he'll go out of his way to help people too.

 

so will there be a new beta addressing this issue or should we manually add this in h_c?

 

Was wondering that myself. For now I have done the workarounds and at work, used ESET to prevent office from spawning child processes.

 

In the current beta of H_C I just added it manually:



He also recommended the following in H_C:

 

I only use ConfigureDefender myself. I am sure something can be done with a GPO for this I would assume.

He also mentioned setting PS to Constrained Language mode should help as well.

 

Thanks useful tip. Downloaded the beta of Andy Ful's Hard Configurator and those settings should help just-in-case.

Dango Powershell was in FULL- It's now changed- my screenshot of switching manually. That's one section which was wide open here Thanks @Trooper



But an article I read mentions constrained language mode is easy to circumvent because it is session specific. If an attacker wants to avoid constrained language mode, they can simply launch a new PowerShell session??

 

thanks for the info.

 

@EASTER and @imdb

you are both welcome. Easter, I'm not sure how it does it, but Constrained language mode is forced on Powershell via SRP in Hard_Configurator. If Powershell is launched as Administrator, then it will (or can) run in Full Language mode, so an exploit would have to elevate Powershell to run in the latter, more dangerous mode.

EDIT

maybe it's because SRP blocks several of the Full Language type Powersell cmdlets as shown:



I think PSD1 is also a PS cmdlet

Of course please note that as Andy mentioned, this exploit will launch Powersell cmdlets without having to spawn Powershell. That said, Powershell run in Constrained language mode will mitigate a great number of threats.

 

@EASTER you are welcome. I believe that what @wat0114 has mentioned with regards to this.

 

No.

You're referring to the case when you open up a PowerShell session via the desktop, then setting it to Constrained Language mode. When the PowerShell GUI is closed, Language Mode reverts to its default setting; i.e. Full Language Mode.

Refer to this article for all the ways PowerShell can be permanently set to Constrained Language mode: https://4sysops.com/archives/mitigating-powershell-risks-with-constrained-language-mode/ .

Finally, disabling PowerShell v2 via Win Features removal is not enough. The attacker can simply download it again. It is imperative that .Net 2.0 and 3.5 not be installed since PowerShell 2.0 cannot run w/o it. Or, simply use OSArmor which has a mitigation to block it.

Also, last time I checked there were at least 20 malware PowerShell "clones" in existence. Most of these can be "thwarted" by again, not installing .Net 2.0 and 3.5 and keeping UAC at max. level.

 

Thank you for this link. It's better than any of the ones I was able to muster up. So it is done in SRP the way I thought.

 

Unfortunately, it, like the environmental parameter hack via reg. modification, can be bypassed as noted in the linked article. However, for the non-corp. user, it should be sufficient.

-EDIT- Tip! If you use a HIPS, you can prevent above hacking by monitoring for any changes to this reg. key and its sub-keys/parameters, HKEY_LOCAL_MACHINE\SYSTEM\*\Control\Session Manager\Environment\*.

 

Nice article. I just found this one last night myself. Cheers @itman

 

Disabled PS 2.0 in Group Policy on Win10 Pro.

 

Just found a very interesting Follina .doc malware sample.

This one deployed it via Word macro. Since Eset, at least, scans macro code, what the macro created was a file named, "word\_rels\document.xml.rels." Note that Follina code is contained within the .xml file.

 

Follina seems to be just the beginning. Andy Ful has suggested there are many uri schemes waiting to be exploited.

 

He seems to be confirming everything that I also mentioned. Namely, you can tackle this exploit by blocking explorer.exe and winword.exe from making outbound connections. And by blocking winword.exe from launching child processes. And of course disabling the preview option in Win Explorer also helps, so no need to complicate things, that was my whole point.

 

Yes, that's why you never get to see powershell.exe launched as a child process.

 

Agreed 100%.