Hackers Use New Trick to Disable Macro Security Warnings in Malicious Office Files

[silversurfer]

Content source

https://thehackernews.com/2021/07/hackers-use-new-trick-to-disable-macro.html

While it's a norm for phishing campaigns that distribute weaponized Microsoft Office documents to prompt victims to enable macros in order to trigger the infection chain directly, new findings indicate attackers are using non-malicious documents to disable security warnings prior to executing macro code to infect victims' computers.

In yet another instance of malware authors continue to evolve their techniques to evade detection, researchers from McAfee Labs stumbled upon a novel tactic that "downloads and executes malicious DLLs (ZLoader) without any malicious code present in the initial spammed attachment macro."

ZLoader infections propagated using this mechanism have been primarily reported in the U.S., Canada, Spain, Japan, and Malaysia, the cybersecurity firm noted. The malware — a descendant of the infamous ZeuS banking trojan — is well known for aggressively using macro-enabled Office documents as an initial attack vector to steal credentials and personally identifiable information from users of targeted financial institutions.

In investigating the intrusions, the researchers found that the infection chain started with a phishing email containing a Microsoft Word document attachment that, when opened, downloaded a password-protected Microsoft Excel file from a remote server. However, it's worth noting that macros need to be enabled in the Word document to trigger the download itself.

"After downloading the XLS file, the Word VBA reads the cell contents from XLS and creates a new macro for the same XLS file and writes the cell contents to XLS VBA macros as functions," the researchers said. "Once the macros are written and ready, the Word document sets the policy in the registry to 'Disable Excel Macro Warning' and invokes the malicious macro function from the Excel file. The Excel file now downloads the ZLoader payload. The ZLoader payload is then executed using rundll32.exe."

Hackers Use New Trick to Disable Macro Security Warnings in Malicious Office Files

Excel Spreadsheet, Microsoft Office, Excel Macros, Cybersecurity, Hacking News

thehackernews.com

 

[ForgottenSeer 85179]

A nice example where UAC on maximum (and of course restricted account) helps

 

[Andy Ful]

The information in the article about disabling macro warning can be misunderstood by some readers:

Once the macros are written and ready, the Word document sets the policy in the registry to 'Disable Excel Macro Warning' ...

The malware does not use the Windows policy for that, because this would require high privileges. These policies cannot be changed from Microsoft Office applications (they are locked by the Administrator).
So, people who use protective Windows policies under the Registry key:
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office
are protected.

In fact, the malware can operate under a similar key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office

Under this key Microsoft Office applications store settings (policies) that can be changed by users from Microsoft Office applications. These settings (policies) do not require high privileges because Microsoft Office runs with standard privileges.

 

[wat0114]

I would think a firewall blocking outbound by default should prevent the download of the malicious Excel file from the remote server if the Word attachment is opened form the phishing email.

 

[Andy Ful]

I would think a firewall blocking outbound by default should prevent the download of the malicious Excel file from the remote server if the Word attachment is opened form the phishing email.

Nowadays, Microsoft Office uses online resources so it would be very inconvenient (if possible). Furthermore, it can use WMI and a lot of LolBins for that.

 

[wat0114]

Nowadays, Microsoft Office uses online resources so it would be very inconvenient (if possible). Furthermore, it can use WMI and a lot of LolBins for that.

I've built myself a large list of Microsoft & Akamai server IP ranges which I apply to MS-related rules in my firewall. Also, wouldn't it be the actual Word attachment that attempts to connect to the remote server, so that a default-deny firewall policy should prevent it?

 

[Andy Ful]

I've built myself a large list of Microsoft & Akamai server IP ranges which I apply to MS-related rules in my firewall. Also, wouldn't it be the actual Word attachment that attempts to connect to the remote server, so that a default-deny firewall policy should prevent it?

The IPs will change after some time. Firewall rules can help in many cases, but cannot fully prevent MS Office from downloading and executing payloads. For example, the BITS service can be used to download something from the Internet and this can be prevented (by Firewall) only by blocking connections of svchost.exe (not recommended).

 

[wat0114]

The IPs will change after some time. Firewall rules can help in many cases, but cannot fully prevent MS Office from downloading and executing payloads. For example, the BITS service can be used to download something from the Internet and this can be prevented (by Firewall) only by blocking connections of svchost.exe (not recommended).

I've been using the IP list for over six months so far with no real changes taking place. BITS is one of the services spawned by svchost.exe that I have restricted this way, at least to remote port 80.

Attached is a list of my IP ranges. These obviously are most likely region-specific, so they will not fully work for many. There might be some overlap, but they cause no issues.

 

[Andy Ful]

BITS is one of the services spawned by svchost.exe that I have restricted this way, at least to remote port 80.

I am not sure if this can prevent BITS. You can test it by running this in PowerShell console:

Import-Module bitstransfer;Start-BitsTransfer 'https://kcsoftwares.com/files/sumo_lite.exe' $home\Downloads\sumo_lite.exe;

It should download sumo_lite application to your Downloads folder.

 

[wat0114]

I am not sure if this can prevent BITS. You can test it by running this in PowerShell console:

Import-Module bitstransfer;Start-BitsTransfer 'https://kcsoftwares.com/files/sumo_lite.exe' $home\Downloads\sumo_lite.exe;

It should download sumo_lite application to your Downloads folder.

As usual Andy, you are so very clever The Powershell command you provided blew right past my firewall, and did indeed download the Sumo file to my Downloads folder. You alone make this forum worth the price of admission...wait it's free So "what the heck gives!" I ask myself. I then checked the allowed logs and svchost BITS service connects to remote IP 46.105.204.2, port 443 for the download of the Sumo file. So I check my rules, and lo and behold I see there are some svchost.exe rules that are not tied to specific services and allowed to connect to remote port 443 with no remote IP restrictions. Once I applied my IP Microsoft/Akamai IP addresses to them, the download is blocked.

So on a note of: "take a deep breath, and take a step back with a calm, cool reflective mindset", is this of real concern? Would a malicious player actually use remote port 443 for a download? And wouldn't OSArmor not alert me to Powershell attempting to be invoked to spawn the download? Just my casual, free-flowing thoughts on the matter.

Thank you for the Powershell command test.

 

[Andy Ful]

Would a malicious player actually use remote port 443 for a download?

If you block port 80 then BITS automatically does a job over port 443 as you have seen when using BitsTransfer in PowerShell.
Blocking BITS will also block some system processes from making updates (Windows Update, Microsoft Update, Microsoft Defender, etc.). BITS supports transfers over SMB, HTTP and HTTPS that is why ports 80 and 443 are used. Some applications and games (like Civilization V) use BITS.
Blocking BITS via a Firewall would be practically the same as disabling BITS service (not recommended).

And wouldn't OSArmor not alert me to Powershell attempting to be invoked to spawn the download?
...

That would depend on OSA settings. OSA can probably block most BITS attempts made via LOLBins.
Anyway, BITS can be used programmatically, and in this case, OSA will be silent in any settings.
There is no way to make Windows 10 totally safe and useful. One can only reduce the attack surface by using security layers and safe "user behavior".

 

[Andy Ful]

...
Andy is right, there is no solution to this problem. You should read my other post on why firewall rules make zero sense on desktop ...

Yes. This is probably true in many cases, when the machine is already infected. But, Firewall rules can help to prevent LOLBins from downloading malicious files (pre-infection stage). Of course, I would not say that it is the most important prevention (and it is not always required). That is not much, but it can reduce the attack surface and support other security layers.

 

[Andy Ful]

@wat0114,

You and @anupritaisno1 use highly restricted systems. If I correctly recall, @anupritaisno1 uses SRP settings that are even more restrictive than yours (H_C 's no elevation on SUA + Paranoid file extensions + Blocked sponsors, anti-exploit mitigations, etc.). Furthermore, he uses very restrictive WDAC policies similar to Windows 10 in S mode which are also far more restrictive than any OSA setup. So, his security standards are beyond the standards of Home users and most Enterprise users.

 

[Andy Ful]

Actually what I have is far more restrictive than even S mode. Assuming a very complex attack, an attacker can technically subvert S mode as the policy itself isn't made read-only in the kernel. This is how you can just press a button in the windows store to turn off S mode. I remove the option that makes the policy writable and force it to become read-only. WDAC also sets rules for HVCI and with HVCI in place you'd need another exploit chain before you could even subvert a read-only WDAC policy. I also enforce EV signers and dynamic code security which S mode doesn't yet

You will be probably safe in the next 10 lives.

 

[wat0114]

@wat0114,

You and @anupritaisno1 use highly restricted systems. If I correctly recall, @anupritaisno1 uses SRP settings that are even more restrictive than yours (H_C 's no elevation on SUA + Paranoid file extensions + Blocked sponsors, anti-exploit mitigations, etc.). Furthermore, he uses very restrictive WDAC policies similar to Windows 10 in S mode which are also far more restrictive than any OSA setup. So, his security standards are beyond the standards of Home users and most Enterprise users.

Yeah I don't even know what S mode is for starters. When I read up on malware analysis reports, there is always a chain of events that take place for the infection to take hold completely on the target device, so my security setup is built *hopefully* to prevent the initial attack vector, or if failing that, then maybe the second step in the attack chain. Te firewall is just one component of many to do that.

 

[wat0114]

BTW, here is the log where the BITS download attempt is blocked

7/10/2021 7:45:01 AM | 11480 | Background Intelligent Transfer Service | C:\windows\system32\svchost.exe | Block | Out | 192.168.1.68 | 61564 | 46.105.204.2 | 443 | 6 | BITS

Also a screenshot of te powershell command to download Sumo...

 

[wat0114]

When you install windows the OS itself ships with a signed WDAC policy and then on the first boot the signer (microsoft production CA) is locked into the uefi secure boot variables. So everyone has WDAC deployed without even knowing it. This WDAC policy only allows code signed by Microsoft to run

But then, how do users exactly run non microsoft signed code? Well, the answer is that this policy has a directive/rule specified in it called "conditional windows lockdown policy". Unless you also set the lockdown flag in efivars this policy isn't activated (but is validated at boot). You can make windows set this flag in the motherboard configuration during an installation and that causes this policy to actually be enforced. Then, any new windows installation will always be in lockdown mode until one of the installations get an exit token from the windows store

Windows lockdown mode is basically what Microsoft rebranded to S mode

Windows 10 and Windows 11 in S mode FAQ - Microsoft Support

Get answers to common questions about Windows 11 and Windows 10 in S mode.

support.microsoft.com

Wow that is heavy duty security. Analogous to Fort Knox encased within ADX Florence supermax

 

[wat0114]

And yet it doesn't exactly come close to what I have set up on my machine. Look at the limitations of S mode I described above

I guess I actually meant your setup specifically, because earlier you did mention what you have is more secure than S mode.

 

[wat0114]

BTW,

I just wanted to add that Windows 10 firewall does not reliably apply an svchost.exe process to a specific service. I tried tying all svchost rules to specific services with remote port and IP address restrictions, but I was getting alerts from, for example: wuauserv.exe and Microsoft account sign-in service to connect to remote IP addresses already included in the rules. I've had to apply one svchost rule to all Programs and Services to prevent connections from being blocked.