Q&A Simple Windows Hardening

[wat0114]

SWH vs. TA551 phishing campaigns

TA551 - 2021 Threat Detection Report - Red Canary

TA551, also known as Shathak, is a threat group that uses large-scale phishing campaigns to deliver additional malware payloads.

redcanary.com

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?

 

[Andy Ful]

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

View attachment 266833

Yes. The last one.

 

[Andy Ful]

SWH vs. Yellow Cockatoo (SolarMarker)

Yellow Cockatoo - Threat Detection Report - Red Canary

Yellow Cockatoo is an activity cluster involving a remote access trojan (RAT) that filelessly delivers various other malware modules.

redcanary.com

New SolarMarker (Jupyter) Campaign Demonstrates the Malware’s Changing Attack Patterns

A new version of SolarMarker malware appears to upgrade evasion abilities and demonstrates that the infostealer and backdoor continues to evolve.

unit42.paloaltonetworks.com

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]

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.

How to detect Yellow Cockatoo remote access trojan

Red Canary Intel detected a cluster of malicious activity executing a .NET RAT across multiple industries. Here’s how you can too.

redcanary.com

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.

 

[Andy Ful]

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.

How to detect Yellow Cockatoo remote access trojan

Red Canary Intel detected a cluster of malicious activity executing a .NET RAT across multiple industries. Here’s how you can too.

redcanary.com

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

https://www.morphisec.com/hubfs/eBooks_and_Whitepapers/Jupyter%20Infostealer%20WEB.pdf

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.

 

[wat0114]

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.

 

[L0ckJaw]

Thanks @Andy Ful for the new version

 

[Andy Ful]

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]

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.

 

[Andy Ful]

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.

https://malwaretips.com/threads/simple-windows-hardening.102265/post-989494

Let me know if this help included in SWH is sufficient.

 

[Gandalf_The_Grey]

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.

 

[SecureKongo]

Seems like I am just blind. Thanks guys!

 

[Andy Ful]

RunBySmartscreen vs. GuLoader

Spoofed Saudi Purchase Order Drops GuLoader: Part 1 | FortiGuard Labs

FortiGuard Labs recently discovered a social engineering email lure with a message delivered to a company in Ukraine. In part I of our blog, we will analyze the phishing email and provide an analys…

www.fortinet.com

New Chaos Ransomware Builder Variant "Yashma" Discovered in the Wild

Cybersecurity researchers have disclosed details of the latest version of the Chaos ransomware line, dubbed Yashma. "Though Chaos ransomware builder has only been in the wild for a year, Yashma claims to be the sixth version (v6.0) of this malware," BlackBerry research and intelligence team said...

malwaretips.com

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:

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:

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

 

[Digmor Crusher]

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.

 

[Andy Ful]

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:

Mark-of-the-Web from a red team’s perspective

Mark-of-the-Web from a red team’s perspective Stan Hegt | March 30, 2020 Zone Identifier Alternate Data Stream information, commonly referred to as Mark-of-the-Web (abbreviated MOTW), can be a significant hurdle for red teamers and penetration testers, especially when attempting to gain an...

malwaretips.com

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.

 

[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:

Security Alert - 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