Mysterious "Follina" zero-day hole in Office

I would include these mitigations:

Code:

Block remote images - ON
Block untrusted fonts - ON
Control flow guard (CFG) - ON
Code integrity guard - ON
Hardware-enforced Stack Protection - ON
Block child process creation - OFF
Data execution prevention (DEP) - ON
Disable extension points - ON
Force randomization for images (Mandatory ASLR) - ON
Randomize memory allocations (Bottom-up ASLR) - ON
Validate exception chains (SEHOP) - ON
Validate handle usage - ON
Validate heap integrity - ON
Validate image dependency integrity - ON

 

My "go to" source of this type of information - Andy Ful - has stated PS 2.0 will fail unless an older version of .NET Framework is installed

 

Funny how this stuff almost never gets mentioned clearly in most if not all of these articles about Follina and other exploits. While mitigations are sometimes more simple than you would think. And of course a tool like OSArmor is also quite useful with these kind of attacks. Plus I'm sure that tools like HMPA and MBAE will be updated to protect against this stuff too, since they are more focused on true memory corruption exploits, which Follina clearly isn't. In fact, Malwarebytes has already added behavior based detection.

 

I have just the right .NET version tools to take care of that. Or simple command line check.
Just where does MS get off with all those years of so called .NET security updates and yet things like launching PS "clones" is so prevalent.

 

This has been one of my biggest complaints over the years.

Simple Windows Hardening, Configure Defender and Hard_Configurator are are rather powerful and underappreciated applications in their own right.

 

This article by Palo Alto: https://www.paloaltonetworks.com/bl...d-playbooks-for-msdt-zero-day-cve-2022-30190/ fully "unmasks" this attack and reveals details not publicly disclosed.

Not waiting to be exploited, they have been absused. The Palo Alto article begins with:

Next up is this current "fixation" with the original attacker deploying stealthy PowerShell sub-assembly usage. All this did was allow the attacker to set up communication to his attacker server C&C so he could remotely launch the rest of the attack.

Now for the main attack which was abusing a legit Win system PowerShell script:

Now this statement "msdt.exe’s command line which is controlled by the attacker" has me a bit concerned as to OSArmor detection. Whereas, OSA can scan local based code within the command line, can it do so remotely? Questionable. No Problem. It detects the initial msdt.exe malformed command line input to establish the remote connection.

 

Yes, very cool, right?

Over at Malwaretips, Dan from VoodooShield likewise stated that VS protects against Follina and would have done so since 2015--without adding any additional rule/s. Edit: oh I see here it is too. Very good:

https://www.wilderssecurity.com/threads/voodooshield.313706/page-751#post-3087507

It's a good thing to supplement Defender with software like that, esp. if it doesn't impact anything on the machine. I myself would never run Defender alone, even if the odds of getting infected are very remote. But there are those who insist it's fine to do so. To each his/her own.

 

Also remember a good backup system is worthwhile as well. I have had to restore my laptop twice this week for other reasons. I'm glad I had the option.

 

Oh BTW, this method will bypass all PowerShell Constrained Language mode mitigations: https://github.com/calebstewart/bypass-clm . So much for all those "mouse traps."

 

Well there goes that idea for me setting this up at work anyway. I think I need to revisit OSArmor however. Cheers.

 

If I try to launch InstallUtil.exe from the location shown in the link from above post:

Code:

Access to C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe has been restricted by your Administrator by location with policy rule {1016bbe0-a716-428b-822e-5e544b6a3125} placed on path InstallUtil.exe.

Due to SRP Blocked Sponsors rule:



I am not sure, however, if this would block the specific bypass-clm PS CL Mode Bypass. I'm just simply posting what I get when trying to launch that .NET Framework file.

 

PS CL mode is not exactly chopped liver. It will stop many of the common attacks floating around the web, just not these URI scheme exploits. It can still be a small part of a layered security approach.

 

My take is the author set it as a WDAC bypass:

If WDAC is not installed, you can use whatever to run it.

 

I disabled Defender Real time protection, downloaded the bypass and ran the command and still got the SRP InstallUtil.exe block. This is pretty heavy technically for me, so I don't know if I tested correctly.

I ran this command as a batch file, given in the Readme.md file provided:

Code:

REM find `InstallUtil`
dir \Windows\Microsoft.NET\* /s/b | findstr InstallUtil.exe$
REM Run the FLM powershell session
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U "C:\Windows\Tasks\bypass-clm.exe"

It wouldn't surprise me if I did something wrong.

 

I could find no bypass-clm.exe on the web site.

You have to download the source code, compile it, and create an C# executable. Then run the .exe by whatever method you chose .

 

Good point, i saw that executable name in the last line of the command, but it's not included in the master.zip file. Still, it looks like the process was stopped when trying to launch installutil.exe. Just speculating.

BTW, I have no clue about how to compile source code, so hopefully somebody else with that expertise could try it and post results using a similar security setup as mine, or actually any kind of security setup utilizing SRP or HIPS-like defenses to prevent LOLBins and such from executing.

EDIT

actually would it be possible to substitute the bypass-clm.exe executable with any other harmless executable, then just change the batch file to run the substitution instead?

EDIT

I tried it, no luck. I give up.

 

I'll elaborate at bit.

First, note that the PowerShell sub-assemblies are .dlls. They cannot be directly executed from a script.

Next, Powershell Constrained Language mode is just a method to prevent the sub-assemblies from being run via a script. Refer to the 4sysops linked article I previously posted; namely the SRP method. What happens is when these .dlls are invoked via script, Powershell actually creates a PowerShell script in the %Temp% directory to run them. All PowerShell Constrained Language mode is doing is preventing PowerShell from creating and running these scripts.

However when the Powershell sub-assemblies.dll's are embedded in executable code, they can be run directly using the malware code as object code. Doing this is a bit tricky and as such is not often done. But nonetheless, it can be done which is the point of the POC.

 

Here's what Andy Ful said about Constrained Language Mode--he also stated in another post that CLM was not a universal panacea but effective for most.

https://malwaretips.com/threads/har...ening-configurator.66416/page-186#post-992428

Specifically when using Hard_Configurator:

Edit: xxJackxx-- you bet: backups are so important, esp. if you're at risk. I'm thinking on how to be pro-active with threats like this (for "funsies"--I don't run Office).

edit: corrected typo

 

Okay thanks, so there's a lot going on under the hood with this, although it looks like this exploit can be halted in the early stages, if I'm understanding correctly, if InstallUtil.exe is restricted in SRP or similar program.

From the link provided above on this PS CL bypass:

 

I am going to reverse what I and others have said about PowerShell Constrained Language mode. It won't stop this exploit.

As I have shown by the POC I posted if PowerShell sub-assemblies are bundled within a .exe, Constrained Language mode is N/A. Now to the Follina exploit specifically.

Msdt.exe has parameter input capability. The PowerShell sub-assemblies are contained within this parameter input. This is the equivalent of if the .dlls were embedded in a separate .exe.

There are plenty of Follina malware samples out there. All someone has to do is run one in a VM with PowerShell Constrained Language mode enabled. If it stops the attack, I am proven wrong.

 

Fwiw, in the last two sentences of my post #114 I mention:

Underlining added for emphasis. I agree Powershell run in CL mode won't stop the exploit. I was just basing my recent posts on the PS CL Mode Bypass linked to in post #134.

 

Since you're "obsessed" with the InstallUtil.exe aspect of the POC, let's get into that.

First and foremost it would be used by the remote attacker to run his C# .exe. Since Installutil.exe is being run remotely, local device SRP restrictions are a moot point:

https://0xsp.com/offensive/handy-techniques-to-bypass-environment-restrictions/

Alternatives to InstallUtil also given in the article.

 

BTW - how long has the Follina vulnerability existed? How about 22 months: https://securityboulevard.com/2022/06/broken-windows-follina-flaw-not-fixed-for-22-months/ .

 

It's a dirty rotten shame a user can't safely rest their mind with Windows. It always comes down to you having to add this, change that, because MS doesn't even know (or refuse to) how to adequately protect against one intrusion technique after another that keeps cropping up.

As far as PowerShell, it might be useful for the users who are well learned in using it beneficially but also is a open avenue of problems when misused by outside sources.

Maybe they should forget Windows AV- it's good enough, and rebuild their Windows FIREWALL more efficiently. Rant end.

 

The thing is, even without his confirmation, I already knew this were valid mitigations, because you need to think logically. In fact, I even saw this security company boasting about that their IPS could block it, but unless I'm missing something there's nothing advanced about it. They simply block MS Word from connecting out, see link LOL.

https://www.catonetworks.com/blog/cato-protects-against-microsoft-office-follina-exploits/