Written by: Jake Spinney, GWAPT, GXPN
During a recent penetration test, I was approached by the company’s Information Security Officer (ISO) who asked me if I had been sending employees malicious Word documents as part of my testing. I hadn’t been sending these documents and decided to investigate the occurrence.
A quick look into this alert revealed a Word document had tried to run a PowerShell command on a user’s system. This command attempted to reach out to a web server to download and execute a Windows binary. Luckily, it was caught by the company’s antivirus software before it could do any damage.
Word documents are often overlooked as a potential gateway for cyber-criminals, but can actually be used to download and execute malicious files. I’ve taken a look at the evolving landscape of Office macro attacks, and detail steps you can take to secure your organization against these threats.
MAZE Ransomware Threat Actors
According to FireEye Threat Research, MAZE ransomware started appearing in the wild in approximately May of 2019. Unlike most ransomware strains which encrypt a single host as a result of a user running a Trojan or visiting a compromised website, MAZE is typically deployed across an entire network by operators who have an initial foothold in a network. One of the ways these operators get their foothold is by using a malicious Office document opened by an unsuspecting user.
Figure 1: Example of malicious Office document used by MAZE operators, via Hybrid Analysis
Wanting to know more about this attack vector, I inspected the samples referenced in the FireEye report through a service named Hybrid Analysis, which executes a variety of files and payloads in a controlled environment called a sandbox, and tracks how the files behave (e.g. IP addresses contacted, files modified, processes spawned, etc.). If we ignore similarities in indicators of compromise (IoCs), I found three common factors in these payloads that would help create our own malicious Office macros or modify existing ones to fit our needs. The macros, which are written in Microsoft’s Visual Basic for Applications (VBA), must have the ability to:
- Download utilities (e.g. lateral movement, privilege escalation, and persistence tools) from the internet
- Execute those utilities from the macro itself (e.g. executing command-line arguments)
- Run itself with the smallest amount of input from the user as possible
For the sake of simplicity, I won’t cover Office macros which exploit Microsoft Office applications, as it isn’t necessary to execute a payload on a target workstation.
Downloading Files
There are two primary methods to download files using VBA. The first one involves what’s known as an XML HTTP Request (XHR), which is a method of fetching website data dynamically without switching pages. While XHRs are typically reserved for (and frequently used by) websites, VBA has the ability to issue these requests. Below is an example of a VBA script to download “file.bin” to the computer and store it as an executable in the “C:\Temp\” directory.
The second method involves importing specific features from the Windows application programming interface (API). The Office documents I examined from the FireEye report used this method to download another file called “service.exe,” which is supposedly used to establish a foothold on the infected device.
Executing Programs
A Microsoft Office macro also needs to be able to run Windows commands. After all, the files we downloaded aren’t going to run themselves. Fortunately for those in the offensive security trade, VBA also has the ability to run any executable file using the “Shell()” command. Here we can execute the file we just downloaded (as was the case for the MAZE operators), or we can run any variety of executables built in to Windows that will let us download, execute, or modify data on the system.
Automatic Execution
Last but not least, we need a mechanism to actually execute this macro on its own, or with the least amount of interaction as possible. Unlike other programming languages, VBA doesn’t run itself by default, as it’s meant to be run from within an Office application at the user’s request. VBA has some pre-defined function names which can execute a macro when certain conditions are met, but the function of interest for our purposes is “AutoOpen().” Any code within the AutoOpen function is run when the user chooses to enable macros.
Office Payload Generators
Rather than have network penetration testers create all of their own Office macros from scratch, several frameworks exist that will generate malicious Office macros immediately. The most prolific payloads used by penetration testers and adversaries alike are PowerShell Empire and Cobalt Strike. Both frameworks generate Office macro payloads as a feature, but Empire has several antivirus evasion techniques built in. These same concepts in PowerShell can be used by VBA, but Cobalt Strike requires some modification to evade detection.
Figure 2: PowerShell Empire macro payload options
Figure 3: Example payload snippet generated by Cobalt Strike
Putting It All Together
Using Wolf’s command and control infrastructure, and some of the methods mentioned above, I generated an Office macro with Cobalt Strike to download and execute an agent when users enabled macros. Some additional modifications to the file were made to bypass antivirus and antimalware scan interface (AMSI) intervention—and the payload was immediately flagged as hostile. By using a link to download the malicious file (instead of sending it as an attachment), I was able to send a test phishing email to a user in our lab and get internal network access without alerting the antivirus software.
Figure 4: A custom Word document with an embedded macro payload
Figure 5: A successful connection from an infected lab machine, using the Word document above
Security Precautions: Lessons Learned
While this attack vector allowed me to sail past most perimeter defenses we see in the field, there are additional steps organizations can take to detect or prevent these kinds of attacks, such as:
- Logging and event correlation to detect when Office applications spawn unusual processes (e.g. “Why did winword.exe try to run cmd.exe?”)
- Scanning or disabling macros coming from outside sources via Group Policy Objects
- Training users to report suspicious emails
- Using an antivirus product which is compatible with the Windows Antimalware Scanning Engine
Don’t underestimate the malicious potential of a seemingly harmless Word document. Thorough penetration testing can alert your organization to these types of attacks, and proper preparation and proactive processes will help mitigate these hazards.
