The Adventures of the Elusive Malvari, Part II: Secret VBA Scripts

Original author: Andy Green
  • Transfer


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


I am a fan of the hybrid analysis website (HA). This is a kind of malware zoo where you can safely watch wild "predators" from a safe distance without being attacked. HA launches malware in safe environments, records system calls, generated files and Internet traffic, and displays all these results for each sample you analyze. Thus, you can not waste your time and energy by yourself solving the confusing code, but immediately understand all the intentions of the hackers.

The HA examples that caught my attention use either JavaScript encoded or Visual Basic for Applications (VBA) scripts that are embedded as macros in Word or Excel documents and are attached to phishing emails. When opened, these macros start a PowerShell session on the victim's computer. Hackers typically send Base64 encoded command streams to PowerShell. This is all done to make the attack difficult to detect with web filters and antivirus software that respond to specific keywords.
Fortunately, HA automatically decodes Base64 and immediately shows everything in a readable form. Essentially, you don’t need to focus on how these scripts work, because you can see the full output of the commands for running processes in the corresponding HA section. See an example below:



Hybrid analysis intercepts Base64 encoded commands sent to PowerShell:



... and then decodes them for you. # magically

In a previous post, I created my own slightly obfuscated JavaScript container to start a PowerShell session. Then my script, like many PowerShell-based malware, downloads the following PowerShell script from a remote website. Then, as an example, I downloaded a harmless PS printing a message on the screen. But times are changing, and now I propose to complicate the scenario.

PowerShell Empire and Reverse Shell


One goal of this exercise is to show how (relatively) easily a hacker can get around classic perimeter defenses and antiviruses. If an IT blogger without programming skills like me can create a fully undetected (FUD) malware in a couple of evenings , imagine the possibilities of a young hacker interested in this!

And if you are a person providing IT security, but your manager is not aware of the possible consequences of these threats, just show him this article.

Hackers dream of gaining direct access to a laptop or victim’s server. It is very simple to do this: all the hacker needs is to get some confidential files on the CEO’s laptop.

Somehow I already wroteAbout the PowerShell Empire post-production runtime. Let's remember what it is.

In essence, it is a PowerShell-based penetration testing tool that, among many other features, makes it easy to run a reverse shell. You can learn more about it on the PSE homepage .

Let's do a little experiment. I set up a secure malware testing environment in the Amazon Web Services cloud. You can follow my example to quickly and safely show a working example of this vulnerability (and not be fired for launching viruses inside the enterprise perimeter).

If you start the PowerShell Empire console, you will see something like the following:



First, you start the listener process on your hacker computer. Enter the “listener” command, and specify the IP address of your system using “set Host”. Then start the listener process with the execute command (below). Thus, for your part, you start waiting for a network connection from the remote shell:



For the other side, you will need to generate the agent code by entering the launcher command (see below). This will generate PowerShell code for the remote agent. Note that it is encoded in Base64, and represents the second phase of the payload. In other words, my JavaScript code will now pull this agent to run PowerShell instead of harmless text output to the screen and connect to our remote PSE server to run the reverse shell.


The magic of the reverse shell. This encoded PowerShell command will connect to my listener and start the remote shell.

To show you this experiment, I took on the role of an innocent victim and opened Evil.doc, thereby launching our JavaScript. Remember the first part? PowerShell was configured so that its window does not pop up, so the victim will not notice anything unusual. However, if you open the Windows Task Manager, you will see the PowerShell background process, which will still not cause any alarm for most. Because it's regular PowerShell, isn't it?



Now, when you run Evil.doc, a hidden background process will connect to the server with PowerShell Empire. Having put on the white hat of the hacker-pentester, I returned to the PowerShell Empire console and now I see a message that my remote agent is active.



Then I entered the “interact” command to open the shell in PSE - and here I am! In short, I hacked into a Taco server, which I myself set up once.



What I just demonstrated does not require so much work from you. You can safely do all this for a lunch break for one to two hours to improve your knowledge of information security. It is also a great way to understand how hackers circumvent external security perimeter protection and covertly deploy on your systems.

IT managers who believe that they have built indestructible protection against any penetration will also probably find it informative - well, if, of course, you can convince them to sit next to you for a long time.

Back to reality


As I expected, a real hack that is not visible to the average user is just a variation of what I just described. To collect material for the next publication, I started looking for a sample on HA that works in the same way as my invented example. And I did not have to look for it for a long time - the site has many options for such an attack technique.

The malware I ended up finding on HA is the \ VBA script that was built into the Word document. That is, I don’t even need to fake the doc extension, this malware is really the most common-looking Microsoft Word document. If you're interested, then I chose this sample, called rfq.doc .

I quickly found out that often you won’t be able to directly extract malicious VBA scripts from a document. Hackers compress and hide them, and they are not visible in Word's built-in macro tools. You will need a special tool to extract it. Fortunately, I came across Frank Baldwin's OfficeMalScanner . Thank you, Frank.

Using this tool, I was able to pull out a very confusing VBA code. It looked something like this:


Obfuscation was done by professionals. I was impressed!

The attackers are really good at messing up the code, not like my efforts at creating Evil.doc. Well, ok, in the next part we will get our VBA debuggers, go a little deeper into this code and compare our analysis with the HA results.

Also popular now: