hamburger

BitDam Blog

Too old to be detected
Roy Rashti
Roy Rashti
3 minutes & 12 seconds read · October 18, 2018

Too old to be detected

Back in 1992, when Personal Computer were not yet a common property, Microsoft attempted to base their stance as pioneers in the new emerging industry of office tools for PCs as they released Excel 4.0.

As part of their offering in that version, XLM was the default macro language used in Excel 4.0. XLM provided the users with a broad functionality to analyze and edit workbooks.

XLM provides a toolset relatively similar to the VBA (Visual Basic for Applications) that is vastly used these days. Among others, it lets the user load DLLs into the applications, run external software and so on.

Macros are a known attack vector

Due to the capabilities of the macros, using it to attack is a path most traveled by attackers these days. It’s very common to see a VBA code that automatically executes being used as a first-level attack surface.

The XLM is embedded in the workbook while the VBA is an external ole stream which makes it easier to analyze and extract.

As a result, solutions that aim to protect end users from such threats have learnt to deal with VBA-embedded attacks.

How many protection systems would detect such attack?

To demonstrate how this may work, I’ve created a simple ‘doc’ file with a malicious VBA code.

That code runs on startup launches a CMD that starts a Powershell process. That Powershell tries to download and execute an executable file. It briefly looks as shown in Figure 1

Figure 1

I used the VirusTotal platform to check if existing solutions would detect it. Although this might not be the ultimate way to benchmark, it’s quite reliable and can provide us with a significant feel about the detection rate of a file.

When I uploaded this file to VirusTotal, it showed about 40% detection (shown in Figure2).

Less than we’d expect, but it feels safe to say that substantial amount of solutions were able to notice the maliciousness present in this file.

Figure 2

 

Next: challenging detection engines with malicious XLM

Following that result, I was intrigued to see how the engines in VirusTotal will handle an XLM attack similar to the VBA one.

XLM macro is based on formula commands. One can use loops, call external DLL’s functions and a variety of commands supported by the engine executing the macro.

I created the following XLM macro in a macro enabled sheet, shown in Figure 3.

Figure 3

The “Name Manager” that you can see in Figure 4 allow us to control aliases given to registered functions in the module. I registered the top left cell as the entry point for the predefined ‘Auto_Open’ function that runs automatically when the file is being loaded.

Figure 4

The Powershell command executed here is exactly the same as the one before.

Testing this file in VirusTotal resulted the concerning result shown in Figure 5; zero detection!

Figure 5

 

Old attacks may be more dangerous than you’d think

Just imagine how easy it could be to attack someone using this simple mechanism that although old, still works. But you know what – I wasn’t so surprised. The inability to handle such attacks is originated in the fact that those kinds of attacks were not seen before by these cybersecurity vendors.

Most current solutions base their detection mechanism on attack structures that they have seen in the wild. Therefore, if an attack was not seen in the past years, it might not be detected.

XLM might be very old technology but it is still supported and can still be used to get a stranger inside your computer.

The horrifying part of it: an attack that was created back when I was born can still cause harm.

BitDam’s unique engine is completely agnostic to the structure of the attack and thus is able to detect attacks, whether it’s known or unknown, new or super-old, from the very first day it’s deployed.