Office Macros are one of the things every IT department tries to block, but will never really be able to 100% eliminate them. The reason is simple the documents with macros are sometimes produced by business apps, sent by business partners via e-mail or created by employees to improve business processes. Often, the Macros were also written a long time ago and nobody knows really what it is doing, it’s just something really important.
Table of Contents
In the past weeks I had a really good example in one of my customer projects which perfectly showed the defense in depth concept and how powerful it is. The DiD concept is an approach to cybersecurity in which a series of defensive mechanisms are layered in order to protect valuable assets and information. If one mechanism fails, another steps up immediately. So, with the DiD concept in mind we always think that an attacker can find a vulnerability in one protection, but if they are stacked together it’s getting much harder for them.
In this blog I would like to share some of the available protection mechanisms for Macros based threats in this blog because I think a some of them are not really well known by a lot of workplace engineers.
- Office 365 ATP – Safe Attachments
- Office Macro Settings / Trusted Network locations / Code Signing
- Antimalware Scan Interface (AMSI)
- Windows Defender Exploit Guard Attack Surface Reduction Rules (ASR)
Office ATP - Safe Attachments
This is one of the first check in the Attack chain because it scans documents on various arrival channels like Mail, Teams, Skype and SharePoint. It does not help for USB Sticks or other Internet downloads.
To use this feature you need to have Office Advanced Thread Protection Plan 1, which is available as an addon plan to O365 E3 or is contained in O365 E5, M365 E5 Security and M365 E5. The main protection feature against macro based threats is Safe Attachments. All messages and attachments that don’t have a known virus/malware signature are routed to a special environment (detonation box) where ATP uses a variety of machine learning and analysis techniques to detect malicious intent. On files in Teams and SharePoint the scanning only happens for files with higher risks like shared with other users or have guest activity, details can be found on docs. If suspicious activity is detected, the message or download is blocked according to your configuration.
Important is that you configure safe attachment policies if you have the ATP plan 1 because O365 will not automatically use ATP unless there is a policy defined and the subscriptions assigned to your users. The activation is nearly risk-less and requires only end-user communication regarding the delivery method you choose.
Office Macro Settings
These settings directly affect if a device can execute a Macro or not. The most important rule is to disable Macro execution if you don’t require it. So, for example most often companies required Macros in Word and Excel but not in Outlook, Access and PowerPoint. Probably you have also some shared workstations or complete departments which don’t require Macros at all. Therefore, you should deactivate Macros there. Microsoft provides the Security Policy Advisor for Office 365 ProPlus and also Desktop Analytics in ConfigMgr which helps to determine which users are using Macros and which not.
The Australian Cyber Security Center has puplished a good manual including the GPO settings for three recommended strategies, which can be chosen per office application:
- all macros are disabled
- only macros from trusted locations are enabled
- only digitally signed macros are enabled (hardened implementation).
In the following flowchart you see how the main Security Settings(red) affect the macro execution. Especially note that in normal case files from trusted publishers/location are not sent to the AMSI interface for virus scanning.
Most companies still avoid the Code sign option because it can be too disruptive for the end-users. But the main reason of my customers is that they think certificates are to complicated and the deployment can also be challenging, but today we see that most companies have their internal PKI available and could already leverage this infrastructure for internal Macros. Not to mention is how simple it is to sign the Macros! It takes only two clicks for the Macro-developer if he already has the code-signing certificate to sign the Macros.
Antimalware Scan Interface (AMSI)
More and more scripts are obfuscated or encoded and therefore it’s not simple to check them against malicious behaviors and well-known threats. Microsoft invented AMSI in Windows 10 which acts as an interface between script interpreters and anti-virus engines. It currently supports the PowerShell engine, the Windows Script Host (wscript.exe and cscript.exe) and recently support for Visual Basic for Applications (VBA) has been introduced.
As you can see in the flowchart in the Office Macro Settings section, the AMSI interface is per default only used for low trust documents. If you would like to use it also for trusted documents/locations/punlsihers, then you have to configure it with the “Macro Runtime Scan Scope” GPO setting. It is important to have a Antimalware scanner which supports this interface, luckily the Windows Defender supports the interface and if available Microsoft Defender ATP is also analyzing the data and providing deep insights in the ATP portal.
Windows Defender Exploit Guard Attack Surface Reduction Rules (ASR)
Attack surface reductions are deeply built-in the operating system and block specific high risk actions like “Creating process from psexec”. Currently there 15 rules available where 7 are just focused in Office macros.
- Block all Office applications from creating child processes
- Block execution of potentially obfuscated scripts
- Block Win32 API calls from Office macro
- Block Office applications from creating executable content
- Block Office applications from injecting code into other processes
- Block Office communication applications from creating child processes
- Block executable content from email client and webmail
These rules can be disabled, or enabled in audit or block mode. It’s highly recommended to enable them first in audit mode and observe usage in your company before enabling them in block mode. Exploit Guard writes an event log entry which can be viewed in Microsoft Defender ATP Portal with the following query:
| where ActionType contains "asr"
| extend JsonOut = parse_json(AdditionalFields)
| sort by ActionType desc
| summarize NumberOfEvents=count() by ActionType,
| project NumberOfEvents, ActionType,
The result will look like:
If you don’t have Microsoft Defender ATP, then Microsoft provides custom views for event viewer or Alex Verboon wrote a cool PowerShell script to collect the Exploit Guard event logs. As soon you had all rules active in audit mode for a representative timespan, you can start analyzing the result. If some rules were never fired, therefore you are able to just set them to block mode. For all which are audited you have to decide if the events should be blocked in future or if you would like to create an exception for the specific process or if you leave the rule in audit mode.
At a customer I had a very good example were one end-user received an Excel file with Macro logic. The Macro was not harmful, but was written a long time ago and with bad programming knowledge. The macro was triggered by a button in one worksheet and created an e-Mail including the file itself. Today this is just a button in the Office Suite and no Macro is required for that, but if you still would like to implement this in a Macro, you can do this via the VBA and an Outlook object or executing a “mailto:” in the shell. But this last method is like starting another process which is something attackers would like to do too and in my example it was the way how it was implemented.
The customer decided to continue using this Macro based Excel sheet and therefore creating exceptions. As soon he added an exception to one layer automatically the next layer protected the devices.
- Macro was blocked due to all Macros were disabled per default. –> Engineering added trusted location via GPO and moved file to this protected location.
- Macro execution started, but due to Macro Runtime Scan Scope (AMSI) was enforced for all Macros AMSI was informed about the execution –> Engineering added exclusion in virus scan
- Exploit Guard ASR detected the malicious behavior and blocked the execution
As you can see the all used layers detected the behavior and protected the device if a previous layer failed. I think this is a really great example on how it should work.
As you can see there are multiple protection mechanisms available to mitigate Office Macro-based threats and you should never only rely on one of them and in best case implement all of them in the most restrictive configuration.