Automation of repetitive manual processes is something just about every Security Operations (SecOps) team is striving for - largely driven by a lack of practitioners in the field but also a by need to reduce ticket response times along with operational expenditure. Security testing and signing of Microsoft Office Macros is a prime automation use-case, especially when an Enterprise may have upwards of 100,000 macro-enabled documents.

Manually vetting each document isn't feasible. Some macros contain upwards of 1000+ lines of code, some don't contain code at all but are using a macro-enabled file extension, others may be entirely malicious but have obfuscated the code so well that it's extremely difficult to distinguish with the naked eye - the common theme being that security practitioners require a capability to efficiently filter out the noise.

What is a Microsoft Office Macro?

A Microsoft Office Macro is an Office Document (e.g. Excel, Word, PowerPoint, etc.) that contains Visual Basic for Applications (VBA) code embedded within it. This code is commonly used for legitimate purposes but can also be abused for malicious intent.

Under normal circumstances, it'd be fair to assume the VBA framework (which itself is designed for automation) would be fairly harmless. Unfortunately this is far from the truth, it contains a variety of powerful functions which can be used to run arbitrary commands or third-party programs outside the context of an office document. Further from this, malicious macro-enabled documents can use in-built functions to automatically execute its code when the document is opened.

The below snippet displays an innocuous word macro that runs a msgbox on-open. Malicious actors can weaponise this macro by replacing the MsgBox function with malicious code.

You're probably wondering why Microsoft would include something so powerful within seemingly innocuous Office Applications. To understand this you need to remember that VBA macros were included in the Office Suite in the 90s, a time when the Internet was still in its infancy and Macro Security was hardly on the radar.

Why should you care?

"Exploitation from malicious macros is one of the top ways that organisations around the world are compromised today." - UK's National Cyber Security Centre

Delivery of Macro-enabled Microsoft Office Documents as part of phishing campaigns has progressively become one of the most dominant malware delivery vectors. Looking at MITRE ATT&CK's adversarial analysis shows that nearly every single active Advanced Persistent Threat (APT) or Financially-Motivated (FIN) Threat Group have used Microsoft Office documents as part of their kill-chain.

The simple answer to preventing these types of attacks is to enable Office Macro security protections - such as configuring Microsoft Office to disable all macros by default and only allow macros to run if they've been vetted and signed as trustworthy (an ACSC Essential Eight requirement here in Australia).

On the surface this sounds simple, but many Organisations quickly realise that applying this locked down configuration can cripple business functions if they have to wait days before the SecOps team has capacity to manually vet and sign a macro. When you couple this with the fact that there's an industry shortage of security practitioners and the sheer number of historic macro-enabled documents that may exist in an Organisation (or new ones being introduced daily) you understand that this control requires a complementary solution to enable it.

How does an automation solution look?

For end-to-end automation we need to decide on and programmatically couple four distinct processes:

1. On-boarding: what method(s) will be used to identify documents for testing and signing? (e.g. periodic network share scans, monitored mailbox, ticketing system upload, manually specified location etc.)
2. Security testing: what's the security posture of your organisation? is static code analysis sufficient or would dynamic analysis (i.e. sand-boxing) be preferred? Does your team have capacity to support open-source tooling or is a commercial off-the-shell (COTS) product preferred?
3. Signing: Microsoft quietly released a mechanism to programmatically sign Microsoft Office documents in early 2019 - the tool itself is available as part of the Windows 10 SDK. With usage guidance available here.
4. Off-loading: how will signed documents be off-loaded back to users? (e.g. emailed back, placed in a shared repository or in a manually specified directory)

Steps 1 & 4 are user-driven requirements and are fairly trivial to implement, step 3 is set in stone but what typically stumps security practitioners is deciding on a tool for step 2 - I'll deep-dive into this a bit more.

Security testing of Macro-enabled Office Documents

As mentioned earlier, security testing can be done with either open-source or COTS tooling. Each have their own strengths and weaknesses so I'll break these down and touch on my personal recommendation based off past experiences.

Open-source tooling

In terms of tooling in this space, there's a clear front-runner - the oletools suite. Maintained by Philippe Lagadec, a globally recognised Security Researcher and specialist in VBA Macro Attack & Defence. The suite contains multiple command line tools which can be chained together providing functionality including macro type detection, malicious code detection (static analysis), execution emulation, malicious code extraction and reporting.

The below snippet displays the output from olevba after scanning an APT28 malware sample that utilises an excel macro.

Strength: Free open-sourced library with full transparency on how malicious documents are detected, meaning you can actively contribute to the project or fork the repository to make your own improvements where needed.

Weaknesses:

1. No commitment for ongoing maintenance, the project owner could one day decide to no longer support the project leaving all those who rely on it in a difficult situation.
2. No commitment on bug fix timelines or feature requests. I've been burned previously by this as I spotted a particular bug in the olevba library that would falsely flag documents as containing high-risk code when in actuality there was no issue. As of writing this article the bug fix is still being tracked as an open issue on GitHub (6 months later).
3. High manpower cost to integrate with an automation pipeline. Individual tools provide differing functionality (e.g. olevba performs static code analysis and ViperMonkey performs execution emulation). Integration of these toolsets need to be performed manually with minimal in the way of a standardised API or report extraction utility.

Commercial off-the-shelf tooling

Again there's a clear front-runner - the Advanced Threat Defence (ATD) product provided by McAfee. Available in cloud-hosted, virtual and physical appliances, ATD is an industry leading product for not only detection of malicious MS Office Suite files, but malicious files in general (i.e. PE files, Adobe files, Image files, Archives, Java, Android Application Package, URLs).

ATD detects malicious documents through a variety of methods including utilisation of McAfee's Anti-Malware Engine, Gateway Anti-Malware (emulation engine), Global Threat Intelligence (GTI) reputation checking (file/URL/IP hash validation), dynamic analysis (sandboxing), in-depth code analysis, custom YARA rules and machine learning.

The below snippet displays the GUI output from ATD after positively identifying a malware sample.

Strengths:

1. Commercially maintained product with an agreed commitment from McAfee for ongoing support and maintenance so long as its license is maintained. Ensuring any bug fixes, security issues or feature requests are actively addressed by a dedicated engineering team.
2. Broad solution integrations, including integration with existing McAfee solutions, third-party email gateways and other products supporting open standards. ATD has also been designed to enable automation through exposure of APIs and exportable reporting functionality - including threat mapping to the MITRE ATT&CK matrix.
3. Powerful analysis capabilities, including in-depth static code analysis, dynamic analysis, and machine learning for more accurate detection with unparalleled analysis data.
4. The ability to reduce costs through a centralised deployment that supports multiple protocols and flexible deployment options supporting all types of networks.

Weakness: Commercially licensed (upfront cost) with a closed source library

My Recommendation

I have been fortunate in that I've experienced both the open-source and COTS pathways (I spent months building my own open-source integration into the oletools suite to enable an automation use-case, named olescan). When considering my past experiences, hands-down the least expensive (factoring in manpower costs), most maintainable and strategic option for an Enterprise is to move forward with COTS tooling (i.e. McAfee's ATD product).

Going down the Open-source journey may seem like an appealing approach (due to a lack of upfront costing) but it's tactical at-best and you'll quickly run into functionality restrictions with a never-ending pile of issues and stop-gap fixes.

Wrapping things up

The end-to-end automation for security testing and signing of Office Macro documents is an essential step in ensuring the long-term security of an Enterprise environment. My aim with this article is to arm you with the knowledge of what technologies are available and how they can enable you to mitigate risks related to execution of malicious Office Macros.