{"id":93008,"date":"2021-03-03T09:00:54","date_gmt":"2021-03-03T17:00:54","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/\/?p=93008"},"modified":"2023-08-10T14:14:15","modified_gmt":"2023-08-10T21:14:15","slug":"xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2021\/03\/03\/xlm-amsi-new-runtime-defense-against-excel-4-0-macro-malware\/","title":{"rendered":"XLM + AMSI: New runtime defense against Excel 4.0 macro malware"},"content":{"rendered":"
We have recently expanded the integration of Antimalware Scan Interface (AMSI<\/a>) with Office 365 to include the runtime scanning of Excel 4.0 (XLM<\/a>) macros, to help antivirus solutions tackle the increase in attacks that use malicious XLM macros. This integration, an example of the many security features released for Microsoft 365 Apps on a regular basis, reflects our commitment to continuously increase protection for Microsoft 365 customers against the latest threats.<\/p>\n Microsoft Defender Antivirus is using this integration to detect and block XLM-based malware, and we encourage other antivirus products to use this open interface<\/a> to gain better visibility and improve protections against these threats.<\/p>\n XLM macros is a legacy macro language that was made available to Microsoft Excel in 1992, prior to the introduction of Visual Basic for Applications (VBA<\/a>) in 1993. While more rudimentary than VBA, XLM is powerful enough to provide interoperability with the operating system, and many organizations and users continue to use its functionality for legitimate purposes. Cybercriminals know this, and they have been abusing XLM macros, increasingly more frequently, to call Win32 APIs and run shell commands.<\/p>\n The AMSI instrumentation for VBA<\/a> has been providing deep visibility into the runtime behavior of VBA macros. Its release in 2018 effectively removed the armor that macro-obfuscation equipped malware with, exposing malicious code to improved levels of scrutiny. Naturally, threat actors like those behind Trickbot, Zloader, and Ursnif have looked elsewhere for features to abuse and operate under the radar of security solutions, and they found a suitable alternative in XLM.<\/p>\n Like VBA and many other scripting languages abused by malware, XLM code can be obfuscated relatively easily to conceal the real intent of the macro. For example, attackers can hide URLs or file names of executable files from static inspection through simple strings manipulations. Attackers also take advantage of the way macro code persists within the Excel document\u2014while VBA macros are stored in a dedicated OLE stream (and hence can be easily located and extracted), XLM macros do not exist as a separate, well-defined entity. Rather, each XLM macro statement is a formula within a cell. Extracting a whole XLM macro can become a cumbersome task, requiring a cell-by-cell inspection of the whole document.<\/p>\n <\/p>\n Figure 1. Sample malicious XLM macro<\/em><\/p>\n In addition, while formulas are typically executed downwards starting from the top, with XLM the macro content can be quite spread out, thanks to control flow statements like RUN<\/em>, CALL<\/em>, or GOTO<\/em>, which allow the switching of execution flow from one column to another. This feature, together with obfuscation, has been abused by attackers to craft documents that could evade static analysis.<\/p>\n AMSI is an open interface that allows any application to request the scanning of any data at any time. In a nutshell, this technology provides applications the capability to interface with the installed antivirus solution in order to inspect and scan potentially dangerous data (e.g., a file downloaded from a remote location, or data generated dynamically by an application). Microsoft already utilizes this technology in various applications to detect malicious macros, script-based malware, and other threats:<\/p>\n The data provided by AMSI is leveraged extensively by Microsoft Defender for Endpoint<\/a>. It provides important data for machine learning models<\/a> that process billions of signals every day to identify and block malicious behaviors. The XLM instrumentation is similar to the implementation in VBA and other scripting engines that integrate with AMSI:<\/p>\n <\/p>\n Figure 2. AMSI instrumentation for XLM<\/em><\/p>\n The XLM language allows a user to write programs that call native runtime functions, as well as external Win32 APIs. In both cases, the interfaces that dispatch the calls to these functions are intercepted and directed to an internal logger. The logger component stores the intercepted functions in text format within a circular buffer. When certain dangerous functions are called, for example the runtime function EXEC<\/em> or the Win32 API ShellExecute<\/em>, XLM halts the macro execution and invokes AMSI to request a synchronous scan of the circular buffer containing the functions logged up to that point. Such dangerous functions are called \u201ctrigger functions\u201d. If the antivirus identifies the macro as malware, the execution of the macro is aborted and Excel is safely terminated, blocking the attack and preventing the malicious macro from doing any damage. Otherwise, the user experience continues seamlessly.<\/p>\n It\u2019s important to observe that the interception of XLM function calls happens at runtime. This means that the logger component always registers the true behavior of all functions and associated parameters, which may contain URLs, file names, and other important IOCs, regardless of the obfuscation used by the malware.<\/p>\n The following is an example of an XLM macro found in a malicious document:<\/p>\n <\/p>\n Figure 3. Sample XLM macro <\/em><\/p>\n This malicious macro consists of a series of commands (e.g., RUN<\/em>, REGISTER<\/em>, IF<\/em>, etc.) with related parameters specified by references to other cells. For example, the token $CA$1889<\/em> passed to the first function RUN<\/em> indicates that the string provided as parameter for this function is in the cell at column CA and row 1889.<\/p>\n This is only one of the many ways that XLM-based malware can obfuscate code. Detecting this macro is challenging because it doesn\u2019t expose any suspicious strings or behavior. This is where the power of AMSI comes into play: the instrumentation allows XLM to inspect functions when they are invoked, so that all their parameters have already been de-obfuscated. As a result, the above macro produces a log that looks like the following:<\/p>\n <\/p>\n Figure 4. Sample log<\/em><\/p>\n The XLM engine determines that the dangerous function ShellExecuteA<\/em> is being invoked, and subsequently places the macro execution on hold and passes the macro behavioral log to AMSI for scanning. The antivirus now has visibility into a behavioral log that completely exposes all of the data including, API names, URLs, and file names. The log makes it easy to conclude that this macro is trying to download and execute a DLL payload via the tool Rundll32<\/em>.<\/p>\n ZLoader is a malware family that has been actively perpetrating financial theft for several years. Like many of its peers, ZLoader operates via aggressive campaigns that rely on social engineering and the abuse of Office documents spread via email.<\/p>\n We have been monitoring the activity of this threat and observed that in the last year the attackers shifted to XLM as their infection vector of choice. The Excel documents have a typical lure message to trick the user into clicking \u201cEnable Content\u201d to allow the macro code to run.<\/p>\n <\/p>\n Figure 5. Malicious Excel file used in Zloader campaign<\/em><\/p>\n A closer look at the document reveals an Excel sheet with an obscure-looking name. That sheet embeds XLM macro formulas, which are stored several rows down to make the sheet look empty. Furthermore, the macro formulas are spread out and obfuscated, hindering static analysis and raising more challenges for identifying intent.<\/p>\n <\/p>\n Figure 6. Malicious XLM macro used in ZLoader campaign<\/em><\/p>\n Executing and debugging the macro with Excel is not very straightforward either. The macro has long loops that are used to decode and run further obfuscated macro formulas, and the Excel\u2019s debugger doesn\u2019t have the ability to control the execution in a granular way in order to skip loops and break on specific formulas.<\/p>\n However, when this macro runs with the AMSI instrumentation enabled, it produces up to three different logs that are passed to AMSI. The first two look like the following:<\/p>\n <\/p>\n Figure 7. Log produced when ZLoader\u2019s XLM macro is run<\/em><\/p>\n The image only shows the final part of the log where the interesting activity shows up. We can see that the macro is issuing a new EXEC<\/em> statement to run a .vbs file via explorer.exe<\/em>. This EXEC<\/em> statement causes the execution of the VBScript named EW2H.vbs<\/em>, which has been decoded and saved to disk by the macro prior to the EXEC<\/em> line. The VBScript then tries to download and run a binary payload. The macro attempts to do this twice, hence this log (with minor variations) is passed to AMSI twice.<\/p>\n If the above steps fail, the macro resorts to downloading the payload directly, producing the following log for AMSI:<\/p>\n <\/p>\n Figure 8. Log produced when ZLoader\u2019s XLM macro is run<\/em><\/p>\n The macro defines two URLs, then downloads their content with the API URLDownloadToFileA<\/em>, and finally invokes the API ShellExecuteA<\/em> to launch the downloaded payload (the file jxi09.txt<\/em>) via rundll32.exe<\/em>. We can infer from this line that the payload is a DLL.<\/p>\n All three logs offer plenty of opportunities to detect malicious behavior and also allow the easy extraction of relevant IOCs like URLs, file names, etc. The initial XLM code in the Excel document is completely obfuscated and contains no usable information, making it tricky to issue static detections that are both effective and durable. With the dynamic nature of AMSI, the runtime behavior can be observed in cleartext, even with obfuscation. Detections based on the logs passed to AMSI also have the advantage of being more robust and generic in nature.<\/p>\n Runtime inspection of XLM macros is now available in Microsoft Excel and can be used by antivirus solutions like Microsoft Defender Antivirus that are registered as an AMSI provider on the device. This feature is included as an addition to the existing AMSI integration with Office. It\u2019s enabled by default on the February Current Channel and Monthly Enterprise Channel for Microsoft 365 subscription users.<\/p>\n In its default configuration, XLM macros are scanned at runtime via AMSI, except in the following scenarios:<\/p>\n Administrators can now use the existing Microsoft 365 applications policy control to configure when both XLM and VBA macros are scanned at runtime via AMSI. Get the latest group policy template files<\/a>.<\/p>\n <\/p>\nAMSI instrumentation for Excel 4.0 (XLM) macros<\/h2>\n
\n
Case study: ZLoader campaign<\/h2>\n
Availability<\/h2>\n
\n