Excel 4, Yes Excel 4, Can Haunt Your Cloud Security

If you think Windows software security is bad today, then you missed the “good old days” of Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), and Office macros security holes. While DDE and OLE are now nothing but the source of nightmares for gray-haired Windows developers, Windows software macros security holes live on.

Seriously? Seriously.

Giovanni Vigna, VMware‘s Senior Director of Threat Intelligence at its Networking and Security Business Unit (NSBU), pointed out this sad fact at Black Hat 2021 in a presentation showing how Excel 4 macros live on to cause havoc today.

This isn’t just a theoretical attack. The Ukraine recently accused Russian spies of uploading documents with malicious macros to a Ukrainian government document-sharing site. And in 2020, Microsoft warned of phishing emails carrying Excel 4 files with malicious macros.

How could a spreadsheet program dating from 1992 possibly cause havoc in 2021? Easy. While Microsoft has stopped Visual Basic for Applications (VBA) macro malware on its Azure cloud by invoking its Antimalware Scan Interface (AMSI) with Office 365 until recently it wasn’t doing anything about attacks written in Excel’s antique XLM macro language.

Technical debt has all kinds of fun ways of coming back to kick you in the security rump.

While chances are you haven’t heard of XLM, since VBA superseded it in 1993, some users still use it and so it’s still supported in contemporary versions of Excel.

So it is, as Microsoft explained, “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.” You’ll find it used for attacks today in programs such as Gozi, Trickbot, Ursnif, and Zloader.

You see what Microsoft didn’t initially say, when XLM was first used in attacks, is that XLM is actually far more dangerous than VBA macros. The latter can only influence what goes on within the spreadsheet. XLM, however, written in a more naive day, has full access to the operating system. And, once it’s reached a Windows virtual machine or container, havoc can be wreaked over the operating system instances and, conceivably, the cloud hosting them. As Vigna said, “They can start programs, they can execute commands using PowerShell, they have access to the Windows API.”

Or, as they might have said if this were an episode of the 60s science-fiction/horror show, The Outer Limits, “We will control the horizontal. We will control the vertical.”

Scary? Sure, but still, how hard can it be to spot a macro attack? It’s harder than you might think. Vigna explained XLM makes it easy to create dangerous but obfuscated code.

It started with trivial obfuscation methods. For example, the code was written hither and yon on and written using a white font on a white background. Kid’s stuff. But, later versions started using more sophisticated methods such as hiding by using the VeryHidden flag instead of Hidden. Users can’t unhide a VeryHidden flag from Excel. You must uncover VeryHidden data with a VBA script or even resort to a hex editor. How many Excel users will even know what a hex editor is, never mind use it?

Adding insult to injury, Excel 4 doesn’t differentiate between code and data. So, yes what looks like data may be executed as code. It gets worse. Vigna added “Attackers may build the true payload one character at a time. They may add a time dependence, making the current day a decryption key for the code. On a wrong day, you’ll just see gibberish.” As VMware security researcher Stefano Ortolani added, Excel 4.0 macros are “easy to use but also easy to complicate.”

You think?

So, so much for hunting for these holes with traditional static scanning methods. To battle hackers using these security vulnerabilities, VMware now offers Carbon Black Cloud support of AMSI Excel 4.0 macro prevention. This lets you test your Excel protection against typical Excel 4.0 macro techniques.

However, that’s not enough. So VMware is enabling us to use Symbolic Execution to detect Excel 4 macros. Symbolic Execution is a program analysis technique in which abstract, aka symbolic input values, are fed to a program. Rather than running the XLS file, it parses it and interprets all the instructions, and then executes all the various paths taken by Excel as a set of constraints on the inputs’ values. This makes it possible to automatically derive the inputs necessary to reach a specific point. In other words, it de-obfuscates the data and functions within a suspect Excel file.

Fortunately, it’s easier done than explained using Symbexcel. This is VMware’s Symbolic Executor for Excel 4 macros. This Python program, which is still a work in progress, can show what’s behind highly obfuscated and evasive code.

It will not, however, be a silver bullet. As VMware explained, Excel 4 macros are an ongoing and evolving threat, which remains difficult to analyze and detect accurately While Symbexcel allows VMware to analyze samples that would otherwise be impossible to de-obfuscate concretely, there’s still much to be done.

So, what can you do? Well, talk to your security people to improve their phishing training for your staffers. No matter how harmless an Excel file may be unless you know precisely who sent it, why they sent it, and what it does, treat all such files as if they were laced with Anthrax.