New Update Simple Windows Hardening

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
Yes.

1654119047720.png


I have already explained this here:

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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
SWH vs. Follina exploit

The attack chain:

1654967497861.png


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.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
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.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
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:

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

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
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:

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.
 
Last edited:

Digmor Crusher

Level 23
Verified
Top Poster
Well-known
Jan 27, 2018
1,236
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
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.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
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.
 
Last edited:

Digmor Crusher

Level 23
Verified
Top Poster
Well-known
Jan 27, 2018
1,236
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.
 
F

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.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top