New Update Simple Windows Hardening

[czesetfan]

Will protecting WSH against this attack help?
Windows MSDT zero-day now exploited by Chinese APT hackers

 

[Andy Ful]

Will protecting WSH against this attack help?
Windows MSDT zero-day now exploited by Chinese APT hackers

Yes.

I have already explained this here:

Security Alert - New MS Office Zero Day Evades Defender

'Follina exploit' loads malware from remote servers Malware writers are exploiting a vulnerability in Microsoft Office that enables them to fetch malicious code without detection in a multi-stage attack, security researchers have found. The exploit, which researcher Kevin Beaumont named...

malwaretips.com

The 0-day could be also prevented by Defender (ConfigureDefender HIGH settings) and by FirewallHardening (added MS Office rules). In the first case, the msdt.exe could be blocked as a child process of Word. In the second case, Word had no chance to make an outbound connection to the malicious website.

 

[Andy Ful]

SWH vs. Follina exploit

The attack chain:

The attack is fully blocked by SWH default settings and can be separately blocked by the DocumentsAntiExploit tool (delivered with SWH).

## The first protection layer that will block Follina is *Admin PowerShell Scripts* = Restricted. It will block the Windows diagnostic script:
‘C:\Windows\diagnostics\system\PCW\TS_ProgramCompatibilityWizard.ps1’
which is run in the context of sdiagnhost.exe. Without this diagnostic script, the CmdLines from the HTML payload cannot be executed and the attack fails. If this script is not blocked then also another script is executed:
‘C:\Windows\diagnostics\system\PCW\RS_ProgramCompatibilityWizard.ps1’
Blocking Follina by *Admin PowerShell Scripts* = Restricted, was a surprise for me. I had never seen such a block before and it is not logged like similar blocks that happen when the user runs a script file


## If one would like to use *Admin PowerShell Scripts* = Allowed, then SWH does not block PowerShell scripts and the diagnostic script can run. But it uses advanced PowerShell functions so it is fully blocked by SRP via ConstrainedLanguage Mode.

## If one would like to disable SRP in SWH, then still Follina will be blocked by the DocumentsAntiExploit tool, which disables the option "Update automatic links at open". When the document is opened, Word does not use the link to the remote HTML payload for updating. So, the exploit is not executed. I could not test if it works also for the Explorer preview (see below).

When using the Explorer preview with installed Word 2021, the weaponized documents did not load the HTML script (both DOC and RTF) even if I disabled SWH. In Word 2019 the Explorer preview did not work at all (known issue that happened to many users). As a web server, the XAMPP was used in my tests.

 

[Andy Ful]

There is some misunderstanding about PowerShell and Follina exploit.
How PowerShell Constrained Language Mode can stop PowerShell in Follina exploit without spawning PowerSell?
The issue is imprecise language.

PowerShell is rooted in .NET Framework and most of the PowerShell functionality comes from the System.Management.Automation.dll. We have also EXE files (powershell.exe, powershell_ise.exe, sdiagnhost.exe, etc.) that can import PowerShell functions from this DLL to run PowerShell scripts (CmdLines and script files).
The Follina uses a special way to access the PowerShell:
msdt.exe --> IScriptedDiagnosticHost COM Object ---> DcomLaunch service --> sdiagnhost.exe ---> runs PowerShell scripts.

In this way, the final payload is not a child process of Word. The attackers like such indirect methods to hide their actions and break the parent-child process tree used by AVs to detect threats.

 

[Andy Ful]

From my Follina test (mentioned in the previous posts) I confirmed some interesting facts:

1. PowerShell was executed only once and only by sdiagnhost.exe . The msdt.exe did not run PowerShell code, but only passed it further to sdiagnhost.exe. I confirmed this by blocking sdiagnhost.exe and watching events ID=53504 and ID=4104 in the Event Log.
2. The fact of blocking the PowerShell scripts by the system-wide policy was not logged. Normally, it is logged as event ID=4100 when powershell.exe runs scripts. When switching ON/OFF this policy the PowerShell was blocked/allowed in the Follina attack.
3. The fact of blocking the PowerShell CmdLines by Constrained Language Mode was not logged. Normally, it is logged as event ID=4100 when powershell.exe runs PowerShell Cmdlines. When switching ON/OFF this restriction the PowerShell was blocked/allowed in the Follina attack.
4. Fortunately, the ScriptBlock is logged (ID=4104) even if sdiagnhost.exe executes PowerShell code so one can control what is happening.

The infection chain was borrowed from my earlier post in another thread:

New MS Office Zero Day Evades Defender

malwaretips.com

Edit.
The below article (mentioned on the Wilderssecurity forum) was also helpful:

Prevention, Hunting and Playbooks for MSDT Zero-Day (CVE-2022-30190) - Palo Alto Networks Blog

Understand how Cortex XDR and Cortex XSOAR Protects Organizations Against Follina Zero-Day Exploits

www.paloaltonetworks.com

 

[Andy Ful]

Here is a short video about my test:

https://github.com/AndyFul/Hard_Configurator/raw/master/Simple%20Windows%20Hardening/FollinaExploit.mp4

 

[wat0114]

Andy, hat's off to you. Thanks

 

[SeriousHoax]

Here is a short video about my test:

https://github.com/AndyFul/Hard_Configurator/raw/master/Simple%20Windows%20Hardening/FollinaExploit.mp4

Now, that's how a test should be done, unlike.....

 

[Andy Ful]

From a theoretical point of view, it is interesting that SWH settings do not need to block the malicious PowerShell CmdLines used in the exploit. So, this malicious PowerShell code can be of any kind. SWH blocks the troubleshooting pack for Program Compatibility Wizard, which executes some diagnostic PowerShell scripts required to further execute the malicious code embedded in the exploit. Some useful info can be found in the article:

Prevention, Hunting and Playbooks for MSDT Zero-Day (CVE-2022-30190) - Palo Alto Networks Blog

Understand how Cortex XDR and Cortex XSOAR Protects Organizations Against Follina Zero-Day Exploits

www.paloaltonetworks.com

The SWH blocks are applied via * Admin PowerShell Scripts * = Restricted. This is a system-wide Windows Policy, that does not allow whitelisting. The PS1 script files will be blocked in any location, even from the Windows folder.

In the Follina exploit the system scripts are copied and run from the UserSpace folder:
%UserProfile%\Appdata\Local\Temp
In such a case they can be blocked also by ConstrainedLanguage Mode when SRP is applied.
If these system scripts were run from the original location in the Windows folder (whitelisted in SRP), then PowerShell would use FullLanguage for them and the scripts could not be blocked. In such a case the Constrained Language Mode would apply only for malicious CmdLines used in the exploit.
Anyway, blocking the troubleshooting pack for Program Compatibility Wizard may be useful for other possible exploits.

 

[Digmor Crusher]

Hi Andy, every 2 weeks or so I get one of these blocks, I assume its nothing but could you enlighten me please. I apologize if I asked this before, I don't remember.

Event[0]:
Event Id = 866
Local Time: 2022/06/15 13:37:03
EventRecordID = 33903
ActivityID = '{0314c0cb-d11f-44bc-96dd-acd0fce91e71}'
Execution ProcessID = '796' ThreadID='3728'
Computer = DESKTOP-L1SV63C
UserID='S-1-5-21-1777632603-4013640730-1325600334-1001'
Attempted Path = C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.10941.0_x64__8wekyb3d8bbwe\WindowsPackageManagerServer.exe
SRP Rule GUID = {1016bbe0-a716-428b-822e-5e544b6a3300}
Description: File blocked via SRP Rule GUID for Disallowed rule C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller*

 

[Andy Ful]

Hi Andy, every 2 weeks or so I get one of these blocks, I assume its nothing but could you enlighten me please. I apologize if I asked this before, I don't remember.

Event[0]:
Event Id = 866
Local Time: 2022/06/15 13:37:03
EventRecordID = 33903
ActivityID = '{0314c0cb-d11f-44bc-96dd-acd0fce91e71}'
Execution ProcessID = '796' ThreadID='3728'
Computer = DESKTOP-L1SV63C
UserID='S-1-5-21-1777632603-4013640730-1325600334-1001'
Attempted Path = C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.10941.0_x64__8wekyb3d8bbwe\WindowsPackageManagerServer.exe
SRP Rule GUID = {1016bbe0-a716-428b-822e-5e544b6a3300}
Description: File blocked via SRP Rule GUID for Disallowed rule C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller*

This event could happen when:

1. You tried to install a Universal Windows Platform (UWP) app from outside of the Microsoft Store.
2. You tried to install a desktop application (non-UWP) from Microsoft Store.

Some applications in Microsoft Store are normal desktop applications that install as any application downloaded from the Internet. They do not update via Microsoft Store, unlike UWP apps. Unfortunately, it is not evident in Microsoft Store which application is the UWP app and which is a normal desktop app.
The setting that applies such blocks is: * Appinstaller * = Restricted.

 

[Digmor Crusher]

Thank you. I guess this happens when I go to the Microsoft store and update my apps.

 

[Andy Ful]

Thank you. I guess this happens when I go to the Microsoft store and update my apps.

I do not think so. You cannot update the desktop application by using Microsoft Store (so far).
The desktop applications are absent in your Microsoft Store library, even when they were installed via Microsoft Store. This is how it works on my computer. Please let me know if it works differently for you.

 

[Digmor Crusher]

Ok, I see where you coming from now...however... I have 2 blocks from this morning, coincidently I opened the MS store twice this morning to check for updates (there were none.) Also, I very rarely try to install programs from the MS store. I am going to open store again and see if I get a block, will let you know.

Edit: Yup, another block after opening the MS store.

 

[ForgottenSeer 95367]

Ok, I see where you coming from now...however... I have 2 blocks from this morning, coincidently I opened the MS store twice this morning to check for updates (there were none.) Also, I very rarely try to install programs from the MS store. I am going to open store again and see if I get a block, will let you know.

Edit: Yup, another block after opening the MS store.

There has to be a rule configured manually via H_C (not default H_C; not sure how it got in there) that contains the * wildcard for the WindowsApps\MicrosoftDesktopAppInstaller folder that looks like :

C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller*

Remove this rule and the block will stop.

Recommend inspecting the SRP wildcard rules that are configured. I can't comment on how they got in there. I do know that is not a default H_C rule.

 

[Digmor Crusher]

Don't use HC.

 

[Andy Ful]

Edit: Yup, another block after opening the MS store.

Interesting. Is the block present if you open Microsoft Store and do nothing?
Please, wait - I have noticed the same now on my computer. I will try to investigate what it means.

 

[Digmor Crusher]

Interesting. Is the block present if you open Microsoft Store and do nothing?

Yes.

 

[Back3]

I just have to click on the Microsoft Store icon to get this message...in SWH.

 

[Digmor Crusher]

I just have to click on the Microsoft Store icon to get this message...in SWH.

View attachment 267522

A ha, another one, proves I'm not going insane.