Office Macro Attacks

Why It's a Problem

As with any program allowing the execution of customizable scripts in the background, attackers can exploit Office suites to run malicious code and compromise victims. Usually the macro-malware acts as a loader in the infection chain, and will download and execute another payload before terminating.

The malware will be embedded in – you guessed it – an Office file, and implanted somewhere for the victim to access it, say a common file share or by e-mail. Once the file is opened, the malware will be executed. This is called a Spearphishing Macro Attack (MITRE T1193: Spearphishing Attachment^[1]), and it’s been prevalent for a very long time.

One memorable example of a macro-malware is the Melissa virus, which first appeared in 1999. The malware was embedded in an MS Word file and when opened, would e-mail itself to the first 50 contacts in the victim’s address book. Though it didn’t cause much damage to individual users (aside from accidentally causing several mail services to DDOS), the total worth of damages caused was estimated at 80$ million, and the attacker was sentenced to 20 months in federal prison.

But that is not to say that spearphishing macro attacks are a remnant of days past. According to data gathered by Cofense Intelligence^[2], during the month of August 2018, malicious macros embedded in MS Office files accounted for 45% of all malware delivery mechanisms analyzed. Moreover, despite the seemingly amateur nature of such attacks, the malwares were used to deliver some of the most malignant payloads in circulation – including Geodo, Chanitor, AZORult and others.

Spearphishing methodologies have also been used in complex APT attacks by various groups, including several that are believed to have links to espionage agencies^{[3], [4]}. In some more sophisticated attacks, legitimate office files were replaced with malicious, seemingly identical ones^[5].

So why would attackers worldwide, including advanced hacking groups, opt to use an attack mechanism that hasn’t changed much since the 90’s?

User Execution

In today’s ever-evolving defense landscape, spearphishing attacks rely on a unique vulnerability, and one that is very hard to mitigate completely – human error. The adversary waits for certain actions to be taken by the victim (say, opening a file) to gain execution, rather than on vulnerabilities that are dependent on the victim’s machine alone (see MITRE T1204: User Execution^[6]).

Furthermore, MS Office macro-execution is usually either enabled by default or is allowed by a single mouse click upon opening the malicious file. This creates a large margin for user error and increases the probability of a successful attack.

Relying on user execution also allows adversaries to target and lure non-technical users specifically, compromising entire enterprises through them. But mitigation is still possible, as we’ll see below, by implementing proper endpoint defense mechanisms as well as educating users.

Here is an example of a common MS Office macro lures, as gathered by Microsoft’s Threat Intelligence Center over the summer of 2016:

Figure 1: Common “Created in a Newer Version” Lure

Cross-Platform and High Spreadability

One of the main risks of macro viruses is their ability to spread quickly. Once the malware is executed, it can embed itself in other Office files on the victim’s machine or even into the Office file templates themselves, rendering every document created on the machine compromised. As the malware spreads, more and more legitimate files are compromised and the margin for user error increases.

Moreover, because macros are written in a macro-language and are executed as part of a bigger program, they are largely cross-platform compatible, making their spreading even easier.

Obfuscation

Macro-malwares are relatively easy to obfuscate. Obfuscation tools are readily available online, and malicious code snippets can be even taken out of the macro source code and hidden in other file components like text labels, Excel cells etc. to evade detection.

Living "Off the Land" (LOL)

Macro threats can be designed to live “off the land”, meaning they don’t write anything to the disk and only use common tools to run code directly in memory. This technique has risen in popularity in the past years and was explained fully in this blog post.

LOL binaries, libraries and scripts can be used exclusively to create entirely Fileless Malware, or be incorporated with traditional techniques to create hybrid attack vectors that write some files to the hard drive.

Low Entry Threshold

As with many user execution methodologies, macro attacks have a low entry-threshold to be executed successfully. Macro-malwares are rather easy to operate and require minimal tweaking to specific victims (if any), in exchange for being highly-dependent on social engineering techniques.

Demonstration

In this demonstration we’ll create a malicious MS Office file using Metasploit on a Kali Linux machine, but other note-worthy tools are Empire, Evil Clipper, LuckyStrike and Magic Unicorn.

We will use Metasploit to generate malicious macro-code that will load the reverse_https payload upon execution. Once up and running on the victim’s machine, this payload will initiate an HTTPS connection with our attacking machine (handled by a separate Metasploit terminal), allowing further exploitation.

Step 1 – Generating VBA Payload

We’ll start the Metasploit console by typing msfconsole and then switch to the reverse_https sub-console by using the command use windows/meterpreter/reverse_https.

Figure 2: “reverse_https” payload sub-console in Metasploit console

The console options can be seen by typing show options:

Figure 3: “reverse_https” sub-console options

Now we will set the host and port the payload will try and connect with when executed. We set our Linux machine’s local IP address and a random port. Also, we will set the payload to migrate to a new process when initiating a session by setting a migration script to run automatically post-execution:

Figure 4: Setting our payload’s host, port and other options

Now we will generate the payload in VBA format using generate -f vba -o <filename>

Figure 5: Generating the payload code in VBA format and outputting to file

Step 2 – Setting-Up a Connection Handler

On a separate terminal, we will set-up a handler to listen for HTTPS requests from the victim’s machine. Once established, we will have a CNC interface with the victim. As before, a host, port and payload to listen to will be set:

Figure 6: Setting-up a handler on a separate Metasploit terminal

And now the handler can be run:

Figure 7: The handler is running and listening for HTTPS requests for 192.168.1.29

Step 3 – Embedding VBA Payload

On a Windows machine, we will open our MS Office application of choice. We opted for MS Word. First, we will open the Macros window by clicking View -> Macros:

Figure 8: MS Office toolbar on Windows 10 machine, showing the “Macros” button to the right

In the Macro Window, we will click Create and paste the contents of payload.vba in the VBA editor that will open:

Figure 9: Naming and creating a new macro

Figure 10: Inserting our malicious code in the VBA editor

Now everything is set up (aside from tailoring the document to lure a specific victim). Once the file is opened, either the macro will execute automatically or the victim will be prompted to enable macros with the “Enable Content” Button:

Figure 11: When opening our malicious file, the victim is prompted to enable macros

Detection & Mitigation

Policing Macro Execution

Spearphishing attempts rely on user execution and human error to pan out. Because of this, one of the most efficient strategies to mitigate risk is limiting the use of macros across an organization.

If an organization doesn’t use macros, they might as well be disabled altogether. But that isn’t always the case. When macro use is essential, policy should be set to minimize exposure to attacks (on Windows this may be accomplished through the Group Policy Editor). This can be done in two complementary forms:

• App Policy – macros should only be enabled in apps where they are actually being used – be it Excel, Word, PowerPoint etc. Furthermore, organizations can choose to only enable macros from trusted location, macros that are digitally signed and more.
• User Policy – in an enterprise environment, macros should only be enabled for users that actually make use of that feature.

Reducing Attack Surface

An attack surface is the total number of ways or places in which an adversary may compromise a device or network. In the context of macro-malware, the capabilities, resources and COM objects VBA macros have access to can be altered in order to reduce the attack surface.

Cynet actively reduces endpoints’ attack surface by restricting access to resources that are essential for malware to operate. Of these rules and restrictions, here are some that specifically target Office macro attacks:

• Block Office applications from creating executable code
• Block Win32 calls from Office macros
• Block Office applications from creating child processes (remember the process migration script we set to auto-run in the demonstration?)
• Block Office applications from injecting code to other processes

Detection

As with other file-based malware, malicious macros (which are essentially code-files embedded in an Office file) can be detected and signed by Cynet’s products. For example, a macro may be deemed malicious if it:

• Uses networking capabilities to download files from remote servers
• Executes scripts in PowerShell, VBA etc.
• Embeds itself in other Office files or Office template files
• Creates processes

However, as threats are growing ever more obfuscated and complex, a need for more sophisticated detection techniques has risen. Starting from Windows 10, Microsoft added a new component called Anti-Malware Scan Interface (AMSI) to address this concern. Microsoft’s AMSI acts as an interface between script interpreters and anti-virus engines, allowing them more control over macro execution than ever before.

Among various detection mechanisms, Cynet also uses Windows’s AMSI to scan Office applications’ memory buffer and other data at runtime, and thus enhances its ability to detect malicious macros and behaviors significantly. Finally, if the macro’s behavior is assessed malicious, its execution will be halted, the application session will be shut down, and the user will be prompted with a notice.

Diligently utilizing AMSI’s capabilities, Cynet can detect and prevent obfuscated attack vectors in numerous runtime environments, including Powershell, Windows Script Host, JavaScript, VBScript and VBA.

(To learn more about how Cynet can protect from spearphishing attempts, click here)

Footnotes:

1. https://attack.mitre.org/techniques/T1193/
2. https://cofense.com/microsoft-office-macros-still-leader-malware-delivery/
3. https://unit42.paloaltonetworks.com/unit42-sofacy-attacks-multiple-government-entities/
4. https://www.fireeye.com/blog/threat-research/2017/06/phished-at-the-request-of-counsel.html
5. https://www.fireeye.com/blog/threat-research/2014/09/darwins-favorite-apt-group-2.html
6. https://attack.mitre.org/techniques/T1204/

Further Reading

1. https://attack.mitre.org/beta/techniques/T1204/002/
2. https://www.politoinc.com/post/the-simplicity-of-vba-malware-part-1-of-2

Macro Security Guidelines

1. https://www.ncsc.gov.uk/guidance/macro-security-for-microsoft-office
2. https://home.sophos.com/en-us/security-news/2019/macro-viruses.aspx
3. https://docs.microsoft.com/en-us/deployoffice/overview-of-security-policy-advisor
4. https://www.cyber.gov.au/publications/microsoft-office-macro-security

AMSI

1. https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
2. https://www.microsoft.com/security/blog/2018/09/12/office-vba-amsi-parting-the-veil-on-malicious-macros/