The Adventures of the Elusive Malvar, Part III: Intricate VBA Scripts for Laughter and Gain

This article is part of the Fileless Malware series. All other parts of the series:

• The Adventures of the Elusive Malvar, Part I
• The Adventures of the Elusive Malvari, Part II: Secretive VBA Scripts
• The Adventures of the Elusive Malvari, Part III: Intricate VBA Scripts for Laughter and Profit (We're Here)

In the last two posts ( here and here ) we talked about fileless, but quite harmless methods of attack. Now we are finally ready to take on real fileless hardware. The hybrid analysis site (hereinafter referred to as HA) is the resource I rely on to find these malicious "creatures." Typically, the information that HA provides for each sample: system calls, Internet traffic, etc. - enough to satisfy typical IT security requirements. I am inexorably drawn to plunge into one of these highly entangled code samples to see what is actually happening there.

If you want to repeat after me, then I recommend that you do this in a sandbox, for example, in Amazon Web Services. And if you check it on your computer, do not forget to comment out the system calls that launch PowerShell.
')

Inside the confusing VBA code

The malware I eventually found on the hybrid analysis site is a VBA script that was embedded in a Word document. As I mentioned last time, in order to see the actual code, you will need Frank Baldwin's OfficeMalScanner .
After extracting the script, I loaded the code into the MS Word macro library, and then launched its step-by-step debugging using the built-in debugger. My goal was to better understand what was hidden behind obfuscation: to play in the information security analyst and to experience the successes and frustrations associated with this work.

If you, like me, first decided to do this in the debugger, then most likely you will drink more than one cup of tea (or coffee), making your way through the breathtakingly complex code or watching the variable L_JEK, which is assigned the string "77767E6C797A6F6" .
Working with this confusing VBA script, I realized that only a very small part of it does a good job. Most of the code is there only to lead you astray.
In the end, I took a screenshot of a small piece of code that does all the evil work of starting the PowerShell command line, which eventually runs on the VBA macro.

Slyly: just take the hex value and subtract 7 for real ASCII.

It is very simple. VBA code contains a summary of the command line in hexadecimal representation in several variables, and then simply converts it to a character string. The only snag here was that the hexadecimal values ​​were shifted to 0x07. So, for example, the first part of a hexadecimal string is obtained from L_JEK, which was assigned the value "77767E6C797A6F6". If you take 0x77 and subtract 0x07, you get hex 0x70. Do the same for 0x76 and you will get hex 0x6F. Look at them in any ASCII code table, and you will see that it corresponds to the first two letters of “powershell”.

In fact, this is not the most difficult confusing, but this is not required! All you need to do is skip past antivirus scanners looking for specific keywords or their representations in the form of ASCII strings. That this pattern is good enough and does. Finally, after the script recreates the command line, it runs it through the CreateProcess function (see below):

Comment out system calls or set a breakpoint in front of them.

Think about it for a second. A Word document was sent to an employee in a phishing email. When opening a document, this VBA script automatically starts a PowerShell session to start the next stage of the attack. No executable files, and obfuscated scripts quietly shy away from antivirus and other scanners.

Here it is Evil!

For the sake of curiosity, I downloaded another macro from the HA site (below) to see what else happens. This second code does roughly the same as the one above.

Secret code embedded in VBA.

But this code is a bit more inventive in how it restores the command line. There is a decoding function, called “d,” which filters out characters from the base line, comparing them with the second control line. This is already the idea of ​​a high school level, and it also does its job perfectly: it easily evades from scanners and deceives admins who only glance at the logs for unusual actions.

Next stop

In my series of first publications on obfuscation, I showed that the Windows event log records quite a lot of details from PowerShell sessions, that is, if you enable the appropriate settings to be able to perform in-depth analysis after the fact of hacking .

Of course, this also has a certain complexity of fileless attacks, since it is almost impossible to determine if a PowerShell script does something bad by simply checking the commands there while viewing security log events.

Why, you ask?

Because PowerShell sessions run all the time, and the evil code from a PowerShell session of a single hacker can be run at the same time as the legitimate code from a respectable IT administrator from PowerShell. If notifications come to you every time the PS script downloads something from the Internet, too many false positive positives will be generated.

The conclusion can be drawn as follows: we see the inability of traditional perimeter defenses to stop such attacks, phishing scams and FUD malware, and great promise for behavioral analytics tools .

In short, this is a losing battle to try to stop hackers from entering the perimeter. The best strategy is to identify unusual and suspicious access to files and launch applications, and then respond to them by deactivating accounts or taking another measure in response to a violation.

In the next section, we will look at more advanced types of fileless attacks.