Why worry about making a new malware trick when you can tweak an old Excel spreadsheet to do the job for you?
Hackers are now doing just that: They are using new techniques to leverage their attacks based on a feature over 25 years old called Excel 4.0 (XLM macros). Despite the age, this feature is probably still compatible with the more modern Excel variant on your computer.
It’s a minority approach as most malicious documents are based on VBA macros. But, the Excel 4.0 approach has the advantage that it is not detected by most antivirus vendors. This technique is used in fileless attacks where there is actually no payload to detect. Instead, it uses a powershell command to download the malicious payload into memory and subsequently execute it.
Microsoft is Mr. Nice Guy (and that’s a problem)
It’s a problem with Microsoft taking a soft approach to backwards compatibility. Microsoft stated in “Working with Excel 4.0 macros” that “Although Microsoft Excel still supports Excel 4.0 (XLM) macros, we encourage you to migrate them to the latest version of Microsoft Visual Basic for Applications (VBA)”. They also mention that they still support backward compatibility for this feature: “If you decide you’re not ready to migrate, you can still run Excel 4.0 macros.” They just don’t mention the increasing adoption of this feature for malicious purposes. Like all security concerns, backwards compatibly is a luxury that always comes back to haunt you.
Excel 4.0 was released in 1992 and just a year later VBA which took over the automation hype of the time. While long forgotten, Excel 4.0 is now resurfacing with powerful capabilities — the ability to circumvent modern antivirus software and use access to Win 32 APIs which allows it to produce sophisticated attacks.
There are at least two ways they can do it
In this blog post we will talk about two ways this is being done: One sample has the most recent format of the xml-based ZIP container “.xlsm” and the other leverages the Compound Binary Format in which data is stored in OLE streams under containers (97-2003 office document format) “.xls”.
The first uses the old “Auto_open cell” functionality which is similar to the “Sub AutoOpen()” function in VBA to automatically run macros. The Auto_open functionality will still run even if it is hidden.
The second is a proof of concept showing how Excel 4.0 macros can be leveraged to create a process which can then hit Win32 APIs and run a malicious powershell script undetected. Yes, something as innocent as the Calculator can be spawned out from the Excel process and misused. Not a good thing for the device or the legitimate user.
Sometimes we have to be digital archaeologists
As a security specialist, it’s not enough to look forward to the latest and greatest trick. Sometimes you have to understand the structure of past, outdated technologies such as Excel 4.0 macros to create adequate detection techniques.
Let’s dive into the code
Document 1:
“sha256: aa26c20f3bf4c86b435f6cc98e36f99c6257562341d0662600cc82fe0f25e79b”
The first sample was analyzed with the popular set of open source tools to find the nature of this file. We first used ViperMonkey, an open source VBA emulator, to analyse the file, but no VBA macros were found.
We then used OfficeMalScanner, an open source tool that is used to scan office documents for embedded OLE objects and embedded shellcode, but again, no malicious traces found so far.
At first glance when you open the file, you can see it clearly showing the “EXEC” function in the first cell calling “powershell.exe” connecting to URL, which is one of the common TTPs of leveraging powershell for post-exploitation.
After running the enabling the macro content we can clearly see that the powershell process is spawned from the Excel process.
It is important to raise certain caveats here:
- The first cell is an Auto_open cell which is the similar to the “Sub AutoOpen()” function in VBA which is used to run your macro automatically.
- The macro worksheet “Macro1” can be simply hidden by right clicking on it and selecting “Hide”. The Auto_open functionality will still run even if it is hidden.
The second round
Document 2:
“sha256: 32bff873b6d5529c99bbd6811d43f9114d068516032a86c7d18d682d7ab2dd37”
This sample was also analyzed with the same set of open source tools.
ViperMonkey:
OfficeMalScanner:
Upon opening the file, it appears as follows:
You can see the “Security Warning” that Macros are present in the document and that you have to enable content for it to work. Just like in the sample above, we could also hide the “Macro1” workbook and set it to AutoOpen as well and it will still run even if it is hidden. The following sample just spawns a Calculator process by the function EXEC(“calc”).
As you can observe, the Calculator has been spawned as a child process from the Excel process. This was done just as a PoC for leveraging Excel 4.0 macros to create a process. Nevertheless, leveraging Win32 APIs is as easy as spawning a process which can mean catastrophic implications. It could also be used, just as in the previous sample, to run a malicious powershell script undetected.
Conclusion:
The key takeaway from the above examples is that the power of Excel 4.0 macros is that it does not leverage the same technology as VBA macros, therefore bypassing most antivirus engines. The following comparison of both the .xlsm and .xls version of a macro containing file will show the difference between both structures.
For .xslm files the file structure of a XLM file is as follows when inflated with OfficeMalScanner:
As we can notice the path XL/MACROSHEETS/SHEET1.XML is the path where the Excel 4.0 macro. If we take a look at the XML file, we can clearly see the EXEC powershell function of the macro.
The structure of a .xlsm VBA macro file is as follows:
(Sha256: 8c1f3364966aa126039e0502068d1339523626c3b99b671bbe4b8b8934a08faf)
We can see that the file path of the VBA project is XL/VBAPROJECT.BIN, this difference in structure allows this EXCEL 4.0 structure to bypass several antivirus vendors’ detection.
As for XLS files, in order to display the structure of these files we use oledump, an open source tool, to analyze OLE files (Compound File Binary Format).
For the first XLM file, the structure is as follows:
As you can see there is no reference to the Excel 4.0 macro, the Excel 4.0 macros are embedded in the workbook OLE stream, contrary to XLS files that do contain VBA macros as follows:
(Sha256: e0b5722b5c31d12998f4d970aa2bb054de6f483895dcaa02576089587ce20d00)
Here we can see the VBA projects when dumping the ole streams as they are present in separate containers.
Once again, the lesson here is that to adequately detect Excel 4.0 macros, we need to understand the structure of this long-forgotten technology in order to incorporate adequate detection techniques.
