Spear phishing is still one of the most prevalent initial access tactics used by attackers to trick victims into running code on a machine to gain access. For years, Excel 4.0 (XLM) based macros delivered via phishing campaigns have been a popular choice in delivering payloads. One of the reasons why Excel 4.0 macros gained in popularity is its 30 years of reliable code execution that “just works” in many versions of Office. Excel 4.0 macros have the ability to call into many of the Win32 API calls needed for defense evasion, code dropping, and code injection.
Unfortunately, attackers quickly caught on that security vendors struggled to keep up with the various ways to evade static Excel 4.0 signatures and analysis by using string manipulation and variable substitution natively within the infected documents. This puts many organizations in a difficult position to manage their security posture with Office documents.
In this post, we will detail why the evasion techniques are difficult to detect with traditional static scanning, highlight an approach that leverages new technology that gives defenders the upper hand when it comes to detecting malicious Excel 4.0 macros, and show how VMware helps defenders stop these techniques before they have a chance to do any damage.
Last year, the VMware Lastline Research Group released an insightful blog post on Excel 4.0 weaponization, analysis, and evolution of defense evasion inside of the macro code. The conclusion of that analysis was there are several distinct clusters of evasion techniques used by attackers. These evasion techniques continued to evolve as security vendors made best efforts to isolate and target the various techniques that are employed by these attackers over time.
In September 2020, Microsoft announced they would be extending their Antimalware Scanning Interface (AMSI) to support Excel 4.0 (XLM) macros as a callback telemetry source. In February 2021, Office was updated to officially add support for Excel 4.0 content scanning via AMSI. Adding Excel 4.0 macro execution telemetry to AMSI is a game-changer for defenders. Due to the way the hooks are implemented, AV vendors can now see all Excel 4 macro executions both inside of the Excel process, as well as from external “invocation” methods like Excel’s COM interface ExecuteExcel4Macro. This AMSI telemetry source means that AV vendors no longer need to inject harmful third-party dynamic-link libraries (DLLs) into a process just to hook interesting function calls.
XLM macros are scanned at runtime via AMSI, except in the following scenarios:
- Files opened while macro security settings are set to “Enable all macros”
- Files opened from a trusted location
- Files that are trusted documents
Let’s examine what types of telemetry we get from this new AMSI telemetry source and how it maps to the analysis that the VMware Lastline Research Group performed last year.
This analysis revolved around evasion techniques malware authors utilized in order to avoid detection from static analysis and sandboxing. With AMSI data available from Excel 4.0 macros, security vendors no longer need to depend on static analysis and sandboxing to identify malicious excel 4.0 embedded macros.
The list of potential evasion/obfuscation techniques is very broad. With AMSI telemetry these techniques no longer have to hinder security products’ ability to detect malicious samples. Security vendors now can dynamically identify malicious content as it’s being executed.
Example 1 – Utilizing MID/CHAR/CODE for Defense Evasion
The following test samples utilize several evasion or obfuscation techniques which include, but are not limited to, dynamically building additional formulas embedded throughout the spreadsheet and the use of functions like MID, CHAR, and CODE for additional obfuscation.
The first stage of execution dynamically builds the second stage of de-obfuscation with nested loops combining data that is stored throughout the spreadsheet. The second stage doesn’t contain any malicious functions but is utilized to build the obfuscated payload.
When the second stage (below) of the Excel 4.0 macro runs, it utilizes the CODE, MID, and CHAR functions to decode the payload for final execution. After execution is complete, the de-obfuscated functions are visible.
The final stage of de-obfuscated functions (below) shows the malicious intent of the Excel document. The data, which contains several functions, is creating a JavaScript file in C:\Users\Public\Documents. This JavaScript file will reach out to the specified URL creating a control panel file (CPL). Once the CPL file is created, it will execute it with Explorer.
With static/dynamic analysis, this data is not available due to obfuscation and sandboxing detection techniques within the document. With AMSI telemetry, however, security vendors are able to see the de-obfuscated data as it’s being executed.
When executing this sample with VMware Carbon Black Endpoint Standard, the Excel 4.0 macros are evaluated as they execute. If the macro contains malicious content during this evaluation, you’ll be prompted from both Microsoft Excel and VMware Carbon Black Endpoint Standard that malicious content was discovered.
With AMSI telemetry, security vendors can analyze the de-obfuscated content in real time, The raw AMSI data below shows that this macro was attempting to write a JS file to c:\users\public\documents. It then utilized the EXEC function to execute the file written to disk.
All of this information is provided to the user within the VMware console and is shown without digging through obfuscation. From the dashboard and within the events, an analyst will be alerted to the scriptload events related to the Excel 4.0 macro payload.
The user also has the ability to dig into the contents of the Excel 4.0 macro by viewing the scriptload event data. The scriptload event streams will show the entire AMSI buffer related to the macro execution.
Example 2 – EXCELntDonut Payload Generation Tool
Another common technique that TAU tends to see in Red Team engagements is the use of open-source payload generation toolkits. In this example, we will run through a popular tool called EXCELntDonut. This tool is unique as it combines several well-known payload smuggling techniques such as:
- Donut/CLRvoyance to convert a .NET assembly into position independent shellcode that is parsed and inserted as characters into the spreadsheet.
- Native Win32 API calls to inject the shellcode into the Excel process to gain code execution.
- Avoids “static” strings that would typically flag signatures looking for known suspect API calls (EXEC(), URLMON, VirtualAlloc)
To build a malicious Excel document with EXCELntDonut, review the excellent writeup by FortyNorthSecurity at the link above.
Without using the obfuscation arguments when creating the XML Excel 4.0 macro, EXCELntDonut utilizes CHAR functions to obfuscate the payload and REGISTER functions to write to memory and execute the supplied payload.
With the additional obfuscation arguments, EXCELntDonut is still using the CHAR functions for obfuscation, however the REGISTER functions are no longer visible, and the contents of the spreadsheet no longer start at A1.
The execution below begins at EH1. It utilizes the FORMULA function to dynamically build additional formulas by grabbing characters from column ET. These formulas are placed in column EV and executed.
When executing the obfuscated sample, even though the function names are not visible until execution, Carbon Black Enterprise EDR analyzes the AMSI contents in real time to detect malicious activity and block the behavior.
Excel 4.0 Macro Techniques:
While there are numerous functions available within Excel 4.0 macros, the following macros are highly suspicious and if discovered within an environment should warrant immediate investigation.
Example 3 – PowerShell DCOM Execution
Excel 4.0 macros also have the ability to be executed with PowerShell via DCOM by creating an Excel.Application object and utilizing the ExecuteExecl4Macro method.
This method requires a string value of the Excel 4.0 macro without the equals sign. In the example below, we’ll execute calc.exe via cmd.exe. The first sample is without AMSI protection. As shown, calc.exe is executed and runs. Once we apply the AMSI policy, this activity is detected and blocked.
There are numerous frameworks that utilize Excel 4.0 macros to accomplish lateral movement, like the following GIST Invoke-Excel4DCOM64.ps1. This technique utilizes the CALL function to manipulate memory on a remote system. This script is blocked as malicious content is discovered during execution.
Testing Your Endpoint Products Against Excel4 Macro Attacker Techniques
If you are interested in testing your endpoint security solution against the Excel 4.0 macro techniques outlined in this post, we created a set of standalone test documents for you to download and execute. These initial samples have no sandboxing detection techniques included.
https://github.com/carbonblack/excel4-tests
We encourage you to run these on test systems to see if you are able to:
- Identify the attacker obfuscation techniques being utilized with your current endpoint security solution.
- Understand the code execution techniques leveraged by the sample without having to pivot to a third-party tool to assist in the payload de-obfuscation.
- Successfully block these samples when your endpoint security solution is put into a blocking mode.
