SWH vs. Emotet spam campaigns
Social engineering campaigns involving the deployment of the Emotet malware botnet have been observed using "unconventional" IP address formats for the first time in a bid to sidestep detection by security solutions. This involves the use of hexadecimal and octal representations of the IP...
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).
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.
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.