The lowly MS Office macro is still a threat. How to mitigate via GPOs.
TL;DR description of updating Group Policy Administrative Templates in the Central Store, blocking macros via GPOs, and testing it all with a sample macro.
Overview:
This example covers centrally managing macros in Microsoft Office by adding the template, configuring the GPOs, pushing the update to clients, and testing it with a sample macro. Macros, aren’t those something from the 90s? Attackers have realized that they can do quite a bit of damage using macros and PowerShell, and often evade application whitelisting. The threat of the phishing email with a malicious macro attachment remains alive and well. An infamous recent example is Emotet.
Hence Microsoft offers solutions to simply disable or restrict the types and sources of macros that are allowed. Various government standards encourage using these solutions to restrict macros. The Essential Eight from the Australian Signals Directorate for example recommends restricting macros. They list this mitigation right up there with application whitelisting, patching, and hardening applications such as web browsers. The UK’s National Cyber Security Centre also recommends restricting macros and transitioning business processes away from them wherever possible.
Group Policy makes it possible to easily centrally manage domain workstations, but of course as applications are added to the baseline or the Windows OS is updated to new versions the available GPOs in Group Policy Management can become inadequate.
The Central Store is a Microsoft defined location to store Group Policy Administrative Templates. These admx files are provided by Microsoft for their products such as Office and are available to help centrally manage other applications from their respective vendor or sites such as https://admx.help/. In theory at least a system administrator could centrally manage almost any application or setting in Windows by manually configuring registry updates in Group Policy and pushing them out to workstations. However this would be much more time consuming and error prone compared to simply using the pre-built templates from Microsoft.
This lab involves the use of a Windows Server 2019 Domain Controller (DC) and a Windows 10 Professional client running Microsoft Office 2013. The domain is test.local. The steps for newer versions of Office are very similar, as they mostly just involve using their respective admx file. Of course Microsoft has gotten better at helping users protect themselves from themselves as well with newer versions.
The default behavior in Microsoft Office 2013 simply warns the user that macros are disabled and helpfully provides a button to ‘Enable Content’. This relies on the user to know that the document is from a trustworthy source and only hit that button if this is true. Relying on that mitigation alone can be risky.
Naturally a system administrator would prefer to help protect users from themselves and prohibit most Visual Basic for Applications (VBA) macros. Office 2013 will open the document in Protected View, but the user can and probably will blow right past that.
The sample macro:
I put a quick and dirty sample macro together to test with. It displays some messages, but more importantly uses VBA to execute a PowerShell command. Office displays two low key warnings before opening the document containing the sample macro:
Office 2013 will then inform the user that macros are disabled, but does not warn the user of the dangers of macros and why they are disabled. It also does not put the warning in big red colors or font. Many users will probably blow right past that also.
In this case if the macro is allowed to run the user will be presented with a message box.
If they select ‘No’ they will see another message box and then the document will load.
If they select ‘Yes’ then they will be presented with a quick and dirty demonstration of the potential impact of allowing macros.
Of course the initial message box was generated by the macro itself. It could simply run PowerShell commands without any further user interaction. The hobbled together sample macro:
Updating the Central Store:
The first step towards mitigating the macro threat is to download the Group Policy Administrative Template from Microsoft for the version of Microsoft Office that is in use on domain workstations. The administrator will then execute the *.exe. This will unpack the admx and adml files into the C:\Windows\PolicyDefinitions\admx folder by default on the administrator’s workstation.
Microsoft suggests that if administrators are performing this task for multiple templates they simply rename the admx folder to describe what application it is for, as an example “admx (MS Office 2013)”.
The templates are placed in the Central Store on DCs. All DCs automatically replicate this folder. The share path is
\\test.local\SYSVOL\test.local\Policies\PolicyDefinitions
And the local path on each DC is
C:\Windows\SYSVOL\sysvol\test.local\Policies\PolicyDefinitions
This folder does not exist by default, so an administrator can simply create it by:
New-Item \\test.local\SYSVOL\test.local\policies\PolicyDefinitions -itemtype directory
Next simply copy the contents of C:\Windows\PolicyDefinitions\admx to \\test.local\SYSVOL\test.local\Policies\PolicyDefinitions. It is not necessary to copy all the adml files, simply copy the folder ‘en-us’ if your domain is in English.
Once this is complete run the Group Policy Management Console (GPMC), create & link a GPO to the desired OU, and then edit the GPO. The Group Policy Management Editor should show “Policy definitions (ADMX files) retrieved from the central store.” next to Administrative Templates under both Computer & User Configuration.
Setting the GPOs:
The GPOs to manage macros for MS Office 2013 are now found under their respective application; Word, Excel, etc. The sample macros are for Word and Excel, so we will be working in:
User Configuration\Administrative Templates\Microsoft Word 2013\Word Options\Security\Trust Center
User Configuration\Administrative Templates\Microsoft Excel 2013\Excel Options\Security\Trust Center
Set ‘Block macros from running in Office files from the Internet’ to Enabled for both Word and Excel. Additionally Word and Excel can be set to only allow VBA in digitally signed macros. This helps stop malware from executing PowerShell commands from a macro as the sample macro does.
Additionally Excel 2013 can be configured via GPO to block all macro enabled files, both *.xlsm and *.xltm. This will block both macro enabled spreadsheets and macro templates.
Verifying the GPOs:
The GPO can be verified by checking regedit, as the Group Policy Template works by modifying registry settings on the domain clients it is applied to. Check:
HKCU\Software\Policies\Microsoft\Office\16.0\excel\security & word\security. Both should include a value ‘blockcontentexecutionfrominternet’ with REG_DWORD = 1.
Of course if the user goes into the Options menu in Word or Excel -> Trust Center -> Trust Center Settings -> Macro Settings they should see the configuration set via GPO, which is grayed out.
Testing the GPOs with the sample macro:
Attempting to open a *.xlsm macro enabled Excel spreadsheet is completely blocked once the GPOs are set and pushed out to the clients.
If the user follows the instructions specified above they will see that the relevant settings were configured via GPO and are grayed out:
In Word, or in Excel if the file type is not completely blocked, the user can open the *.docm or *.xlsm file, however the VBA macro will not run.
Additionally, to Google’s credit gmail blocked the *.dotm and would not allow it to be sent as an email attachment. Gmail sent the *.docm and *.xlsm files, but marked them as viruses in the receiver’s inbox and would not allow them to be opened.
Google Drive will allow the *.docm and *.xlsm to be uploaded and downloaded but it does warn very explicitly that the file is suspicious and considered infected with malware.
These warnings are much more unambiguous and noticeable than the warnings given by Microsoft Office 2013 itself, so I definitely credit Google there.
Windows Defender flagged and deleted the sample *.dotm file but not the *.docm or *.xlsm files, even though all three contained the same dubious VBA code.
Interestingly 19/65 antimalware engines on VirusTotal flagged the sample macro contained in macro.docm. More than likely it was the Shell(“PowerShell -ExecutionPolicy Bypass -Command “<command>””) contained in Private Sub Document_Open() that caused it to pop hot. It is rather suspicious for a macro to run a PowerShell command upon opening an Office document (https://www.virustotal.com/gui/file/a60ccc00ee002f5c3664bc4f362eebea8a53835a3de715bcc822322cb4702a7a/detection).
Conclusion:
GPOs make centrally managing client baselines and security settings much easier for busy system administrators. Admittedly I had not touched Visual Basic code since highschool, so it took me considerably longer to put the sample macro together and get it working then it did to setup the Central Store, push the GPO, and verify it using the macro.
References:
https://www.malwarebytes.com/emotet/
https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/macro-malware
https://threatpost.com/malicious-attachments-remain-a-cybercriminal-threat-vector-favorite/158631/
https://www.cyber.gov.au/acsc/view-all-content/publications/microsoft-office-macro-security
https://www.ncsc.gov.uk/guidance/macro-security-for-microsoft-office
https://www.encomputers.com/2018/05/disable-macros-in-microsoft-office-using-group-policy/
https://www.stigviewer.com/stig/microsoft_excel_2016/2017-09-19/finding/V-71039
