Q&A Simple Windows Hardening

wat0114

Level 7
Verified
Well-known
Apr 5, 2021
305
SWH vs. TA551 phishing campaigns



But, the macro in the attack can be modified by accessing the WMI service via WinMgmts moniker to bypass the parent-child monitoring. So, one has to additionally restrict WMI (can be done in Microsoft Defender via ASR rules).

So I guess these protections, at least the first two, in OSA would would mitigate this avenue of attack as well?

OSA WMIC.png
 

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
SWH vs. Yellow Cockatoo (SolarMarker)

In one of my previous posts, I mentioned that EXE/MSI threats are beyond the scope of SWH - such threats are not fileless malware. But in the case of the recent Yellow Cockatoo attacks, the situation is more complex. It uses EXE/MSI file to execute a benign application (PDF Merge) and malicious Powershell script. SWH blocks PowerShell scripts by default so the attack can be blocked. A similar attack was analyzed in the SWH thread here:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-973934

On the contrary, the older less advanced Yellow Cockatoo (SolarMarker) attacks did not use fileless methods, so they were beyond the scope of SWH.
 

wat0114

Level 7
Verified
Well-known
Apr 5, 2021
305
On the contrary, the older less advanced Yellow Cockatoo (SolarMarker) attacks did not use fileless methods, so they were beyond the scope of SWH.

In this writeup of Yellow-cockatoo RAT, it mentions powershell being used (Detection opportunity 3) to create .lnk files in the startup directory and eventually launches a command-line script to install a malicious dll.


Wouldn't SWH stop this malicious use of powershell, or is it too late already because the executable is already installed?

EDIT

I guess RunBySmartscreen could be used in H_C to check the initial executable when launching it.
 
Last edited:

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
In this writeup of Yellow-cockatoo RAT, it mentions powershell being used (Detection opportunity 3) to create .lnk files in the startup directory and eventually launches a command-line script to install a malicious dll.


Wouldn't SWH stop this malicious use of powershell, or is it too late already because the executable is already installed?

EDIT

I guess RunBySmartscreen could be used in H_C to check the initial executable when launching it.

This example is fileless, too. It will be blocked by SWH settings.
The malware that could not be fully blocked was the Jupyter infostealer (mentioned in the RedCanary article).

Upon execution of the installer, a .NET C2 client (Jupyter Loader) is injected into a memory. This client has a well defined communication protocol, versioning matrix, and has recently included persistence modules. The client then downloads the next stage, a PowerShell command that executes the in-memory Jupyter .NET module

In the Jupyter example (precursor of Yellow Cockatoo), the first part of the attack installed the malware into the memory and could get the persistence. The PowerShell was used in the next stage after the machine had been already compromised. I am not sure how dangerous could the first part of the attack, but in the current versions of Yellow Cockatoo this part is skipped and the installation is fully done via PowerShell.
 
Last edited:

wat0114

Level 7
Verified
Well-known
Apr 5, 2021
305
This example is fileless, too. It will be blocked by SWH settings.
The malware that could not be fully blocked was the Jupyter infostealer (mentioned in the RedCanary article).

Okay, so I guess there are different versions, some more advanced than others, of Yellow Cockatoo. Thanks.
 
  • Like
Reactions: Andy Ful

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
Okay, so I guess there are different versions, some more advanced than others, of Yellow Cockatoo. Thanks.
I would say, that there are different versions with the tendency to be more fileless. It is hard to say if the more fileless versions are also more advanced. Simply, the AVs are better and better at detecting non-fileless malware, so the malc0ders try to adapt.
 

SecureKongo

Level 29
Verified
Top poster
Well-known
Feb 25, 2017
1,828
Hey, as the new SWH version requires the standalone Documents Anti-Exploit tool to work similar as before I need to know what the different settings do. What's ON1, ON2, Partial etc? Didn't find any explanation anywhere. Hope somebody can help. :)
 
  • Like
Reactions: Gandalf_The_Grey

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006

Gandalf_The_Grey

Level 61
Verified
Helper
Top poster
Content Creator
Well-known
Apr 24, 2016
5,048
Hey, as the new SWH version requires the standalone Documents Anti-Exploit tool to work similar as before I need to know what the different settings do. What's ON1, ON2, Partial etc? Didn't find any explanation anywhere. Hope somebody can help. :)
Click the green buttons (Adobe Acrobat Reader, MS Office) for more info
Also post 493 and 496 of this thread give some info.
 

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
RunBySmartscreen vs. GuLoader

GuLoader is delivered via EXE (NSIS) installer embedded in the ISO file, so it is a good example to show how RunBySmartscreen can help. This delivery method is pretty popular.

Infection chain:
Email with phishing URL ----> ISO file downloaded via URL ----> User opens ISO image ----> User opens the file which is EXE malware instead expected PDF document.


## Using RunBySmartscreen tool.

Even if the ISO file is downloaded via Edge web browser, the SmartScreen will ignore it.
After the ISO (optical disc image) file is downloaded the user opens it from the web browser and can see this:

1653421481446.png


At this moment (File Explorer opened) the RunBySmartscreen should be used. One has to use the mouse to right-click on the file to open the Explorer context menu and choose the "Run By SmartScreen" option (the user does not have to know what kind of file it is). This forces checking the EXE, MSI, COM, and SCR files by SmartScreen reputation - the safe executables are automatically executed. For other files, the info is displayed. The music files, photos, videos, etc. are automatically opened.

In the case of the malicious EXE file (like in this example) the home user will see the well known SmartScreen alert:

1653422670178.png


Without RunBySmartscreen, the file embedded in the ISO file will be opened without SmartScreen check.

See also another example of using RunBySmartscreen:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-980775
 
Last edited:

Digmor Crusher

Level 14
Verified
Top poster
Well-known
Jan 27, 2018
694
Is there a difference between scanning a file with Defender as opposed to running it with RunBySmartscreen? Would one be more secure then the other? As an example lets use an EXE file for a program you have just downloaded. Thanks.
 
  • Like
Reactions: Andy Ful

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
Is there a difference between scanning a file with Defender as opposed to running it with RunBySmartscreen?
RunBySmartscreen does not scan anything. In the case of EXE, COM, MSI, and SCR files it adds the MOTW to the file and lets it open by Windows. More about the importance of MOTW:

After adding the MOTW, Windows thinks that the file has been downloaded from the Internet and the file is checked by SmartScreen for Explorer (file reputation lookup in the Microsoft cloud). Like any top file reputation, it is much safer than any AV detection. Of course, the files are also scanned/detected as usual by the AV.

RunBySmartscreen would not be needed if Windows could add MOTW to the files embedded in archives, disk images, files stored on FAT32 USB drives, and Memory cards. Even if such files have been downloaded from the Internet, Windows cannot recognize this, and SmartScreen for Explorer is not triggered.
 
Last edited:

Andy Ful

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
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

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
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

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
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

Level 81
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,006
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: