Question Simple Windows Hardening

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174
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 Excel 4.0 Macros) is blocked in SWH ver. 2.0.0.0 by applying the Recommended Settings (including the DocumentsAntiExploit tool).

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 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 the Paranoid extensions were applied 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 and later.
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174
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 30
Verified
Top poster
Well-known
Feb 25, 2017
1,903
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 63
Verified
Honorary Member
Top poster
Content Creator
Well-known
Apr 24, 2016
5,124
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 30
Verified
Top poster
Well-known
Feb 25, 2017
1,903
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

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

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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174
Post updated.

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). The infection chain can be blocked by 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.

Edit.
Unfortunately, the opening of the ISO files is managed by the Windows built-in handler that does not support SRP.
But, ISO files can be still protected by SRP when they are opened by 3rd party applications like WinISO or Deamon Tools.
 
Last edited:

Andy Ful

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

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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174
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.
In most cases, such attacks can be also neutralized by ConfigureDefender HIGH settings + WMI ASR rule, when Microsoft Defender is the main Antivirus.

* Surge in attackers using Excel add-ins (.XLL) to infect systems.
  • Some attacks via XLL add-ins could bypass SWH versions prior to 1.1.1.1. Now, such attacks are blocked by SRP settings in SWH.

* 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.
  • Some of these attacks could bypass SWH versions prior to 1.1.1.1. Now, such attacks are blocked by SRP settings in SWH or the DocumentsAntiExploit tool included in SWH.

* 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

  • Some of these attacks could bypass SWH versions prior to 1.1.1.1. Now, such attacks are blocked by SRP settings in SWH or the DocumentsAntiExploit tool included in SWH.

* 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)

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

Andy Ful

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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top poster
Developer
Well-known
Dec 23, 2014
7,174
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 VBA 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). This could partially succeed with SWH prior to ver. 1.1.1.1. SWH ver. 2.0.0.0 can block such attacks in Recommended Settings (including the DocumentsAntiExploit tool).(y)

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

Andy Ful

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