By now most people would be aware of the great work of the Australian Cyber Security Centre (ACSC) in the development of prioritised mitigation strategies to help organisations mitigate cyber security incidents caused by various cyber threats - wow, that's a mouthful.

The most effective of these prioritised strategies are known as the Essential Eight, not to be confused with The Hateful Eight a Tarantino film about a bounty hunter - what is not to love?

Anyways, I highly recommend reading through the Essential Eight Explained to get the broad strokes of what it is, why you need it, and how to go about implementing them.

Specifically one of these key mitigation strategies focuses on reducing the attack surface to users from Microsoft Office files with Macros, as these Visual Basic macros when they are working as intended, can be used to deliver and execute malicious code on systems.

You can Read about the Essential Eight Maturity Model over on ACSC's website.

For a bit of additional context, according to the continual awesome work by Paolo Passeri over at Hackmageddon, 36.4% of cyber attack techniques involved using Malware (June 2020), I’m not sure what percentage of this involved office macros, but I’d say it would be up there.

Maturity Levels

The first step in controlling macros is ensuring that settings that are applied to endpoints are effective and cannot be changed out of band.

So, it is logical that ACSC's main strategy for all maturity levels is looking to ensure that users can't change these settings:

1. Microsoft Office macro security settings cannot be changed by users.

Great, now that we have that out of the way, what do we need to raise the maturity further?

Maturity Level One

So, what else do we need to be Partly aligned with the intent of the mitigation strategy?

Quite simply stopping just any macro from running as soon as an office file is launched without user-interaction or intervention, by implementing:

1. Microsoft Office macro security settings cannot be changed by users.
2. Microsoft Office macros are allowed to execute, but only after prompting users for approval.

To quote one key piece of guidance from ACSC's here:

Relying on users to make correct security decisions one hundred percent of the time is not a realistic expectation considering the sophistication of many spear phishing attempts. As such, allowing users to decide which macros to enable on a case-by-case basis presents a significant risk and should not be implemented.

Maturity Level Two

So, we can quickly see level one has gaps, it's a start but we can do better! ACSC recommend stopping running anything originating from the Internet and requiring all macros to be signed before they are allowed to run.

This can help you stop that pesky Emotet/TrickBot laden TPS Report from popping you, so we implement the following:

1. Microsoft Office macro security settings cannot be changed by users.
2. Microsoft Office macros in documents originating from the internet are blocked.
3. Only signed Microsoft Office macros are allowed to execute.

To quote another key piece of guidance from ACSC:

...only macros digitally signed by trusted publishers can be allowed to execute. However, only specific Microsoft Office applications for which there is a business requirement for macro use should be allowed to execute digitally signed macros. All other Microsoft Office applications should have support for macros disabled.

Maturity Level Three

So where to now? To really raise the maturity of protecting your endpoints, we need to lock things down further by training and retaining staff that can inspect and approve the contents of Macros, such as the following:

1. Microsoft Office macro security settings cannot be changed by users.
2. Microsoft Office macros in documents originating from the internet are blocked.
3. Microsoft Office macros are only allowed to execute in documents from Trusted Locations where write access is limited to personnel whose role is to vet and approve macros.

More Information

For a full rundown on this guidance including what Group Policy Settings you need to set in order to acheive the above strategies, check out ACSC's publication on Microsoft Office Macro Secuirty.

The Maturity Rub

I completely agree with the intention of the above maturity levels, however the way they are written and presented is confusing and can be easily misinterpreted.

When reading the above maturity level strategy literally, Trusted Locations reads as being more secure than Digital Signing. Therefore, and I believe this is the intent, that this guidance is to be interpreted to be cumulative, implementing the intended goals of the previous levels.

Whilst it is not specifically explained in the guidance from ACSC, please do consider that reading this strategy literally can cause problems, for example:

Electronic Document Records Management Systems (EDRMS)

Logically, whichever tool you use to provide EDRMS needs to store files from the EDRMS on local disk to view, check-out or edit.

Since this application need to do this to natively open the Office application, it is typically running under the context of the local user, by extension the local user also has access to write files to this location.

It then follows that:

• if 3. Trusted Locations supersedes 3. Signed Office macros then immediately you see there is a security loophole here where a malicious Office Macro enabled file just needs to be saved to this uncontrolled location in order to run - defeating the intention of this strategy.

• if 3. Trusted Locations is used in conjunction with 3. Signed Office macros, then operationally EDRMS can now function as intended as you would not need to "trust" the local folder for the user to use a trusted macro. The whole organisation is also protected against inadvertant checking-in of mallicious macros.

In Short: the wording of the Essential Eight Maturity Model levels contradicts itself a bit; so just go with the flow and combine everything :-)

Signing Office Macro Files

Everyone would probably agree with me that the process of Digitally Signing of Office Macros is laborious and clunky. So, I wanted to find a way to programmatically if possible sign office files, and I was sure there must be a way.

Windows SDK :: SignTool

So, after a bit of sleuthing about on stack overflow and reddit of all places, I finally came across the Windows SDK SignTool

SignTool is available as part of the Windows SDK and is:

...a command-line tool that digitally signs files, verifies signatures in files, or time stamps files.

Sounds great!

However, this joy is short lived, as it does not natively know how to open, and sign the VB Script within an Office file.

The Microsoft Office - Subject Interface Package

So, after returning to Google, Reddit, Stack Overflow, and my now cold cups of coffee; I came across the answer by using Subject Interface Packages, or SIPs.

Namely the one for Microsoft Office Subject Interface Packages which is used to Digitally Signing VBA Projects.

Almost-Eureka!

Here is a great breakdown of what these are from Microsoft MVP Kevin Jones in his blog posts Part 1 and Part 2.

TL/DR - Environment Prerequisites

Just for reference, lets imagine you are working in this path: C:\MacroSigning The basic steps you need to get going are as follows:

1. Download the Windows SDK, and install the Code Signing component.

2. Once installed go to the install path, on my local workstation it was here: C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86

3. Copy the x86 version of SignTool.exe to your working path: C:\MacroSigning\SignTool.exe

4. Download and run the Microsoft Office Subject Interface Package, during the installer it will ask for an installation path, choose a path like: C:\MacroSigning\SIP Refer to the readme.txt for additional instructions if required in "HOW TO USE THESE COMPONENTS"

5. Register the corresponding MSO SIP dll for the format you are working with. For VBA projects contained in legacy Office file formats use:C:\MacroSigning\SIP>regsvr32.exe msosip.dll For VBA projects contained in OOXML Office file formats use:C:\MacroSigning\SIP>regsvr32.exe msosipx.dll

Now you should be ready to sign Macro Enabled Microsoft Office files!

Signing Commands

While hopefully your results don't vary from mine, the below command should enable you to sign a Macro Enabled Excel Workbook with a nifty one-liner: C:\MacroSigning>signtool.exe sign /f certificate.pfx /fd SHA256 Workbook.xlsm

Im my own experience, I wanted to supply a certificate passphrase and define the digest algorithm like so: C:\MacroSigning>signtool.exe sign /q /f certificate.pfx /p "Passphrase" /fd "SHA256" /td "SHA256" SHA256 Workbook.xlsm

You can refer to the SignTool tool documentation for switches and parameters.

PowerShell Module

To make this process a little easier for me to handle the commands used to sign files and the Windows Forms PowerShell GUI wrapper, I wrote a quick and dirty PowerShell module to defangle the Adding and Verifying a Signing Certificates.

Get a copy here: github.com/Joflixen/signtool

• This work is not sponsored, endorsed, or approved by ASD, ACSC or the Australian Government.
• Use at your own risk, I accept no liability implied or otherwise.

-J