The Adventures of the Elusive Malvari, Part III: Intricate VBA Scripts for Laughter and Profit
This article is part of the Fileless Malware series. All other parts of the series:
- The Adventures of the Elusive Malvari, 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 Are Here)
In the last two posts ( here and here ) we talked about file-free, but quite harmless attack methods. Now we are finally ready to take on a real fileless malware. A hybrid analysis site (hereinafter referred to as HA) is a resource that I rely on to find these malicious "creatures." As a rule, the information that HA provides for each sample: system calls, Internet traffic, etc. - enough to meet typical IT security needs. I am inexorably drawn to plunge into one of these very confusing code samples to see what is really going on there.
If you want to repeat after me, then I recommend that you do this in the sandbox, for example, in Amazon Web Services. And if you check this on your computer, be sure 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, you need Frank Baldwin's OfficeMalScanner to see the actual code .
After extracting the script, I downloaded 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 IB analytics and experience the successes and disappointments 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 a mind-blowing complex code or observing, blinking, on the variable L_JEK, which is assigned the line "77767E6C797A6F6" .
Working with this confusing VBA script, I realized that only a very small part of it does useful work. Most of the code is there just to lead you astray.
In the end, I took a screenshot of a small part of the code that does all the evil work of starting a PowerShell command line, which ultimately gets triggered by a VBA macro.
Tricky: just take the hex value and subtract 7 for real ASCII.
It is very simple. VBA code contains in several variables a record of the final command line in hexadecimal representation, and then simply converts it to a character string. The only "trick" here was that the hexadecimal values were offset by 0x07. So, for example, the first part of the 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 get hex 0x6F. Look at them in any ASCII code table and you will see that it matches the first two letters of “powershell”.
In fact, this is not the most difficult entanglement, but this is not required! All you need to do is to skip past antivirus scanners looking for specific keywords or their representations in the form of ASCII strings. That this sample 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 you open the document, this VBA script automatically starts a PowerShell session to begin the next phase of the attack. No executable files, and obfuscated scripts quietly shy away from antiviruses 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 thing as the one above.
Secret code embedded in VBA.
But then this code is a little more inventive in the way it restores the command line. There is a decoding function called “d” that filters out characters from the base string, comparing them to the second control string. This is already an idea of a high school level, and it also does an excellent job: it easily dodges scanners and tricks admins who only briefly look at the logs for unusual actions.
In my first series of publications on obfuscation, I showed that the Windows event log records a lot of details from PowerShell sessions, that is, if you enable the appropriate settings to be able to conduct in-depth analysis after the fact of hacking .
Of course, this also has a certain complexity of file-free attacks, since it is almost impossible to determine whether the PowerShell script is doing something bad by simply checking the commands there while viewing the security log events.
Why, you ask?
Because PowerShell sessions start all the time, and malicious code from a PowerShell session from a single hacker can be launched at the same time as legitimate code from a PowerShell good IT administrator. If you receive notifications every time the PS-script downloads something from the Internet, too many false-positives will be generated.
The conclusion can be drawn as follows: we see the inability of traditional perimeter defense tools to stop such attacks, phishing emails and FUD malware, and great prospects for behavioral analytics .
In short, this is a deliberately losing battle trying to stop hackers from getting inside 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 part, we will consider more advanced types of file-free attacks.