Q&A Simple Windows Hardening

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
SWH vs. Emotet spam campaigns

I posted several examples of attacks in the wild that could be easily prevented by SWH. So, it is time to post an example that could bypass SWH alone (but not with ConfigureDefender HIGH settings, or FirewallHardening, or DocumentsAntiExploit tool).
This attack vector (via legacy XLS documents) is blocked by default with SWH ver. 1.1.1.1.

Infection chain (delivery stage in blue):
Spam email --> Excel document --> Excel 4.0 macro --> cmd[.]exe --> Mshta LOLBin downloads/executes the paylod

What was the problem for SWH?
SWH uses system-wide features to harden the system and Microsoft Office applications. Unfortunately, Microsoft adopted the system-wide policy only to disable the VBA support in MS Office (including VBA macros), but there are only non-system-wide policies to disable Excel 4.0 macros. So, in the attack via XLS legacy documents (not blocked by default prior to ver. 1.1.1.1) the Excel 4.0 macros were not disabled by SWH. If the user was fooled by the attacker to allow macros (blocked by default in MS Office) then the malicious macro could be executed.
In earlier versions of SWH (prior the ver. 1.1.1.1) this attack could be blocked only when applying the Paranoid extensions in SWH.

Why this is not a problem for ConfigureDefender, FirewallHardening, or DocumentsAntiExploit tools?
  • ConfigureDefender settings will block the child process (cmd[.]exe) via the ASR rule,
  • FirewallHardening will prevent Mshta LOLBin from downloading the payload,
  • DocumentsAntiExploit tool can harden MS Office applications via non-system-wide policies and Excel 4.0 macros will be blocked.

Post updated to reflect the changes in SWH ver. 1.1.1.1
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
SWH vs. Warzone (aka AveMaria) and AgentTesla campaigns

As a supplement to my previous post, here are examples of recent campaigns with VBA macros (blocked by SWH).


In these examples, the PowerPoint document is used instead of Excel.
Spam email --> PowerPoint document --> VBA macro --> wscript[.]exe --> PowerShell and Mshta LOLBins download/execute the paylods

PowerPoint and Word use VBA macros (cannot use directly Excel 4.0 macros).
SWH will block VBA code, so the attack can be stopped at the delivery stage - malicious code will not be executed at all.
 
Last edited:

SecureKongo

Level 28
Verified
Top poster
Well-known
Feb 25, 2017
1,702
SWH vs. Warzone (aka AveMaria) and AgentTesla campaigns

As a supplement to my previous post, here are examples of recent campaigns with VBA macros (blocked by SWH).


In these examples, the PowerPoint document is used instead of Excel.
Spam email --> PowerPoint document --> VBA macro --> wscript[.]exe --> PowerShell and Mshta LOLBins download/execute the paylods

PowerPoint and Word use VBA macros (cannot use directly Excel 4.0 macros).
SWH will block VBA code, so the malicious code will not be executed at all.
In the infection chain Windows Script Host is used by the malware. What is the main reason why you decided not to restrict it in the recommended settings?
 

Gandalf_The_Grey

Level 59
Verified
Helper
Top poster
Content Creator
Well-known
Apr 24, 2016
4,854
SWH vs. Emotet spam campaigns

I posted several examples of attacks in the wild that could be easily prevented by SWH. So, it is time to post an example that could bypass SWH alone (but not with ConfigureDefender HIGH settings, or FirewallHardening, or DocumentsAntiExploit tool).

Infection chain:
Spam email --> Excel document --> Excel 4.0 macro --> cmd[.]exe --> Mshta LOLBin downloads/executes the paylod

What is a problem for SWH?
SWH uses system-wide features to harden the system and Microsoft Office applications. Unfortunately, Microsoft adopted the system-wide policy only to disable the VBA support in MS Office (including VBA macros), but there are only non-system-wide policies to disable Excel 4.0 macros. So, Excel 4.0 macros are not blocked by SWH. If the user will be fooled by the attacker to allow macros (blocked by default in MS Office) then the malicious macro will be executed.

Why this is not a problem for ConfigureDefender, FirewallHardening, or DocumentsAntiExploit tools?
  • ConfigureDefender settings will block the child process (cmd[.]exe) via ASR rule,
  • FirewallHardening will prevent Mshta LOLBin from downloading the payload,
  • DocumentsAntiExploit tool can harden MS Office applications via non-system-wide policies and Excel 4.0 macros will be blocked.
Conclusion.
If one does not use Defender with ConfigureDefender settings or other tools, then it would be necessary to check if Excel is configured to block macros without notification, or be cautious with macros in Excel documents.
When one uses other tools adding the DocumentsAntiExploit tool would be sufficient to stop these attacks?
 

SecureKongo

Level 28
Verified
Top poster
Well-known
Feb 25, 2017
1,702
When one uses other tools adding the DocumentsAntiExploit tool would be sufficient to stop these attacks?
I posted several examples of attacks in the wild that could be easily prevented by SWH. So, it is time to post an example that could bypass SWH alone (but not with ConfigureDefender HIGH settings, or FirewallHardening, or DocumentsAntiExploit tool).
 

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
In the infection chain Windows Script Host is used by the malware. What is the main reason why you decided not to restrict it in the recommended settings?
Windows Script Host is restricted in SWH by default (via SRP). Simply, in those examples, the infection chain was stopped before wscript.exe could be executed.
SWH can use also a non-SRP way (via the option * Admin Windows Script Host *) that completely disables Windows Script Host (does not allow whitelisting). This option is not enabled in default settings.
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
When one uses other tools adding the DocumentsAntiExploit tool would be sufficient to stop these attacks?
Yes, it will prevent running the Excel 4.0 macros. DocumentsAntiExploit tool applies several restrictions and can be used when Defender is not configured with advanced settings or when another AV is used. The user has to use DocumentsAntiExploit on each account, because configuring the restrictions for one particular user does not have an impact to other user accounts.

In MS Office, the below settings are applied (valid up to MS Office 2019):
  • Disabled Macros in MS Office XP and MS Office 2003+ (Word, Excel, PowerPoint, Access, Publisher, Outlook).
  • Disabled Access to Visual Basic Object Model (VBOM) in MS Office 2007+ (Access, Excel, PowerPoint, and Word).
  • Disabled DDE in Word 2007+ (requires Windows Updates pushed in January 2018, see Microsoft Security Advisory ADV170021).
  • Disabled auto-update for any linked fields (including DDE and OLE) in Word 2007+, Excel 2007+, Outlook 2007+, One Note 2013+.
  • Disabled ActiveX in MS Office 2007+.
  • Disabled OLE in MS Office 2007+ (Word, Excel, PowerPoint).
  • Disabled ‘Run Programs’ option for action buttons in PowerPoint 2007+.
  • Disabled automatic download of linked images in PowerPoint 2007+.
  • Disabled TrustBar notifications in MS Office 2007+.
In Adobe Acrobat Reader XI/DC, the below settings are applied :
  • The dangerous features in Adobe Acrobat Reader DC on Windows 8.1/10 can be silently mitigated in AppContainer.
  • The dangerous features in Adobe Acrobat Reader XI/DC can be blocked with the ‘Yellow Message Bar’ (the user can allow them).
  • The restrictions apply to the current account and overwrite native settings in Adobe Acrobat Reader XI/DC.
  • The user can apply different restrictions on different accounts.
 

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
SWH vs. new sophisticated campaign delivery of AsyncRAT trojan


The intrusions commence with an email message containing an HTML attachment that's disguised as an order confirmation receipt (e.g., Receipt-<digits>.html). Opening the decoy file redirects the message recipient to a web page prompting the user to save an ISO file.

But unlike other attacks that route the victim to a phishing domain set up explicitly for downloading the next-stage malware, the latest RAT campaign cleverly uses JavaScript to locally create the ISO file from a Base64-encoded string and mimic the download process.

Morphisec also pointed out the campaign's advanced tactics, which it said allowed the malware to slip through virtually undetected by most antimalware engines despite the operation being in effect for close to five months.

Infection chain (delivery stage in blue):
email with HTML attachment ---> ISO created ---> BAT or VBS script ---> PowerShell ---> fileless payloads

Depending on SWH settings, the infection chain can be stopped at the delivery stage by blocking the ISO file (non-default setting), or via blocking BAT or VBS scripts (blocked by default). So, despite the advanced tactics, the attack is fully neutralized. After running PowerShell, the malware would also try to use UAC bypass, add exclusions to Defender, and disable action center notifications.
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
Would Configure Defender on Max setting also have stopped the attack?

It is possible that this particular attack could finish the STAGE 2 of infection (but would be stopped by Defender at STAGE 3):

STAGE 2: REFLECTIVE .NET INJECTION​

The PowerShell file code that's executed is responsible for:
  • Creating persistancy through Schedule Task
  • Executing a dropped .vbs file, usually at %ProgramData%
  • Unpacking an Base64 encoded and deflate compressed .NET module
  • Injecting the .NET module payload in-memory(dropper)

But the decisive infection starts at STAGE 3 via the script Net.vbs which is obfuscated. This could be blocked by the ASR rule.

STAGE 3:

1643317933006.png


The full infection chain is very complicated to avoid detection. It is possible that some parts of the attack could be mitigated by the ASR rule "Use advanced protection against ransomware". Furthermore, the complicated infection chain could be detected by the very aggressive cloud protection level used in MAX settings.
I am not sure how this malware neutralization would be counted on Malware Hub. The system was compromised because the malware could connect to a malicious URL, download STAGE 1 payload, get persistence, and execute a few processes after reboot. But, it could not do anything truly malicious when ASR rules were enabled. The final payload (AsyncRAT) would not be injected, UAC would not be bypassed and Defender's settings would not be tampered, too.
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
Configure Defender set at MAX does seem to offer very strong protection -

Unfortunately, this nice "demonstration test" is inconclusive. The testing methodology is not designed to show the differences in the protection between AVs. Furthermore, only EXE files were tested.
Anyway, Defender with advanced settings is well tested by MRG Effitas and AV-Comparatives. These tests show that the protection is comparable to the top AVs (business versions). This was also confirmed in many tests on Malware Hub (Defender on MAX settings failed on a few malicious scripts).

Edit.
Some business AVs (like Kaspersky) can be highly tweaked to get even stronger protection, compared to Defender MAX settings.
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
THREAT INSIGHTS REPORT Q4 - 2021 (HP WOLF SECURITY)


In Q4 2021, HP Wolf Security detected a near sixfold increase (588%) in malware campaigns using malicious Microsoft Excel add-in (XLL) files to infect systems compared to Q3. This technique is tracked in MITRE ATT&CK as T1137.006.2 The purpose of add-ins is that they contain high-performance functions called from an Excel worksheet via an application programming interface (API). This feature enables users to extend the functionality of Excel beyond other scripting interfaces like Visual Basic for Applications (VBA) because it supports more capabilities, such as multithreading. Attackers taking advantage of legitimate APIs and scripting features is not new, but the growing popularity of this technique illustrates how threat actors are continually looking for ways to abuse legitimate features in software to achieve their goals.

It is an interesting lecture to see how modern attacks can impact the SWH settings when MS Office Excel is installed in the system.

WARNING
When using Excel for viewing documents (not recommended), the default SWH settings should be extended by using "Paranoid Extensions" and blocking macros without notifications in Excel (Excel can use both VBA and non-VBA macros).

In most cases, such attacks can be also neutralized by ConfigureDefender HIGH settings + WMI ASR rule, when Microsoft Defender is the main Antivirus. Also using FirewallHardening and DocumentsAntiExploit tool can significantly enhance the protection of Microsoft Defender.

Surge in attackers using Excel add-ins (.XLL) to infect systems.
  • The attack via XLL Excel ad-dins can sometimes bypass SWH defaults. Many attacks can additionally use scripts at the later infection stage, which can be stopped by SWH defaults.
  • The XLL file is a PE file (kind of DLL) and the user can be infected by clicking on it from the Explorer. This attack and similar (possible) attack vectors can be prevented by using SWH with "Paranoid Extensions" (Settings >> Protected SRP Extensions).

Aggah targets South Korean organizations with malicious PowerPoint add-ins (.PPA)
  • This attack uses VBA macros, so it would be prevented by SWH defaults.

TA505’s links to MirrorBlast
  • These attacks were performed via Windows Script Host, HTML pages containing malicious Javascript, or MS Office documents with malicious macros.
  • Most of these attacks could be prevented by SWH on defaults, except for some attacks based on Excel4 macros.

QakBot gives attackers access to infected systems to deliver ransomware
Ongoing courier spam delivers Ursnif malware to Italian-speaking organizations
The return of Emotet and its reversal of roles

  • Many such attacks were performed via Excel4 macros. Some of them could bypass SWH defaults.

Fake Discord website serves RedLine malware posing as installer
  • The initial infection vector used Windows Script Host, so it would be prevented by SWH defaults

Conclusion
The presented attack vectors via MS Office can be dangerous for casual users.
Generally, it is better to avoid using MS Office (desktop versions) for viewing documents.
The best compatibility with MS Office formats can have Word mobile, Excel mobile, and PowerPoint mobile (free versions). Also "PDF Reader by Xodo" is highly compatible and secure - it converts on-the-fly office documents into PDF files. The mobile office applications and Xodo application run in AppContainer. Furthermore, all these applications are from Microsoft Store, so the strong Exploit Protection mitigation can be used (Code Integrity Guard).
Anyway, such attacks are not especially dangerous for cautious users because MS Office applications block by default macros and Add-ins with clear notification that enabling these features is not safe.(y)
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
This was the first thing I noticed. His tests are clickbait, like so many others: pretty useless.

Yes. Any similar test is like an advertisement. Even if the conclusion is true, it does not result from a reliable basis.
In the case of this particular test, the author had a problem with believing in his own advertisement.:)
 

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
SWH vs. EXE --> Scripts

Normally, SWH depends on SmartScreen and AV to fight EXE files. But, malc0ders can use EXE files also as script droppers to avoid AV detection. Here are some in-the-wild examples used by the Russia-linked Shuckworm group (aka Gamaredon, Armageddon) in cyber-espionage attacks against targets in Ukraine.
https://symantec-enterprise-blogs.s...ligence/shuckworm-gamaredon-espionage-ukraine

The EXE malware used in attacks would drop/execute the following files that could download the secondary payloads:
  1. VBScript scripts with several (spoofed) extensions like .ppt, .dat, .rar, .nls, etc.
  2. .cmd scripts
The infection chain (delivery stage in blue):
EXE ---> Scripts (primary paylods) ----> secondary payload execution (EXE payloads and scripts)

The above infection chain is used to fool Administrators and AVs. All such attacks would be stopped by SWH in default settings (SRP blocks) at the delivery stage.

Another infection vector was performed via weaponized Word documents. The article does not inform about details, but it was probably a document with macro (SWH would block it by default). Of course, the attackers could use something else (like a legacy Excel document with Excel 4.0 macro) to bypass default SWH settings. This could partially succeed with SWH prior to ver. 1.1.1.1. Let's suppose that the user did not disable macros without notification in Excel. In such a case the malware was able to drop/execute the .lnk file (spoofed VBScript file). Still, the script execution would be blocked by SWH default settings (via SRP restrictions). Starting with SWH ver. 1.1.1.1 the legacy Excel documents with macros (like XLS documents) are blocked by default.(y)

Post updated to reflect the changes in SWH ver. 1.1.1.1
 
Last edited:

Andy Ful

Level 78
Thread author
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
6,796
SWH vs. MuddyWater campaign in Turkey

Two variants of the infection chain (delivery stage in blue):
PDF document with URL ---> downloaded maldoc (VBA macro) ---> intermediate scripts ---> final payload execution
or
PDF document with URL ---> downloaded EXE (script dropper) ---> intermediate scripts ---> final payload execution

The user has to manually open the maldoc (malicious document) or EXE dropper.
SWH on default settings will stop the infection chain on the delivery stage by blocking VBA or intermediate scripts (STAGE 2 or 3).

The attackers use Excel spreadsheet files, but did not adopt Excel 4.0 macros in the attack.

Post edited.
 
Last edited: