Adventures in Fileless Malware, Part II: Sneaky VBA Scripts

I’m a fan of the Hybrid Analysis site. It’s kind of a malware zoo where you can safely observe dangerous specimens captured in the wild without getting mauled. The HA team runs the malware in safe sandboxes and records systems calls, file created, and internet traffic, displaying the results for each malware sample. So you don’t have to necessarily spend time puzzling over or even, gulp, running the heavily obfuscated code to understand the hackers’ intentions.

The HA samples I focused on use either encasing JavaScript or Visual Basic for Applications (VBA) scripts, which are the “macros” embedded in Word or Excel documents attached to phish mails. These scripts then launch a Powershell session on the victim’s computer. The hackers usually send to the PowerShell a Base64-encoded stream. It’s all very sneaky and meant to make it difficult for monitoring software to find obvious keywords to trigger on.

Mercifully, the HA teams decodes Base64 and displays the plain text. In effect, you don’t really need to focus on how these scripts work because you’ll see the command line of the spawned processes in HA’s “Process launched” section. The screenshots below illustrate this:

In the last post, I created my own mildly obfuscated JavaScript container to launch a PowerShell session.

Then my script, like a lot of PowerShell-based malware, downloads a second PowerShell script from a remote web site. To do this safely, my dudware downloads a harmless 1-line of PS to print out a message.

This being the IOS blog we never, ever do anything nice and easy. Let’s take my scenario a step further.

PowerShell Empire and Reverse Shells

One of the goals of this exercise is to show how (relatively) easy it is for a hacker to get around legacy perimeter defenses and scanning software. If a non-programming security blogger such as myself can cook up potent fully undetected or FUD malware in a couple of afternoons (with help from lots of espressos), imagine what a smart Macedonian teenager can do!

And if you’re an IT security person who needs to convince a stubborn manager – I know they don’t exist, but let’s say you have one – that the company needs to boost its secondary defenses, my fileless attack example might do the trick.

I’m not suggesting you actually phish management, though you could. If you take this route and use my scripts, the message that prints on their laptops would count as a cybersecurity “Boo!”.  It may be effective in your case.

But if your manager then challenges you by saying, “so what”, you can then follow up with what I’m about to show you.

Hackers want to gain direct access to the victim’s laptop or server. We’ve already reviewed how Remote Access Trojans (RATs) can be used to sneakily send and download files, issue commands, and hunt for valuable content.

However, you don’t have to go that far. It’s very easy to gain shell access, which for certain situations might be all a hacker requires – to get in and get out with a few sensitive files from the CEO’s laptop.

Remember the amazing PowerShell Empire post-exploitation environment that I wrote about?

It’s a, cough, pen testing tool, that among its many features lets you easily create a PowerShell-based reverse shell. You can more learn more about this on the PSE site.

Let’s take a quick walk through. I set up my malware testing environment within my AWS infrastructure so I can work safely. And you can do the same to show management a PoC (and not get fired for running grey area hacking software on the premises.)

If you bring up the main console of PowerShell Empire, you’ll see this:

First, you configure a listener on your hacking computer. Enter the commander “listener”, and follow up with “set Host” and the IP address of your system — that’s the “phone home” address for the reverse shell. Then launch the listener process with an “execute” command (below). The listener forms one end of your shell connection.

For the other, you’ll need to generate agent-side code, by entering the “launcher” command (below). This generates code for a PowerShell agent — note that it’s Base64-encoded — and will form the second stage of the payload. In other words, my JavaScript encasing code from last time will now pull down the PowerShell launcher agent, instead of the harmless code to output “Evil Malware”, and  connect to the remote agent in reverse-shell fashion.

To run this experiment, I played the part of an innocent victim and clicked on Evil.doc, which is the JavaScript I set up last time. Remember? The PowerShell was configured to not pop-up a window, so the victim won’t notice anything unusual is going on. However, if you look at the Windows Task Manager, you’ll see the background PowerShell process, which may not trigger alarms ’cause it’s just PowerShell, right?

Putting on my hacker-pentester hat, I returned to my PowerShell Empire console, and now see the message that my agent is active.

I then issued an interact command to pop up a shell in PSE. And I’m in! In short: I hacked into the Taco server that I set-up once upon a time.

What I just described is not a lot of work. If you’re doing this for kicks during a long lunch hour or two to improve your infosec knowledge, it’s a great way to see how hackers get around border security defenses and stealthily lurk in your system.

And IT managers who believe that they’ve built breach-proof defense may, fingers crossed, find this enlightening – if you can convince them to sit down long enough.

Let’s Go Live

As I’ve been suggesting, real-world fileless hacking is just variation on what I just presented. To get a little bit of a preview of the next post, I searched for Hybrid Analysis specimen that works in a similar fashion to my made-up sample. I didn’t have to search very long – there’s lots of this attack technique on their site

The malware I eventually found in Hybrid Analysis is a VBA script that was embedded in a Word doc. So instead of faking the doc extension, which I did for my JavaScript example, this fileless malware is really, truly, a Microsoft document.

If you’re playing along at home, I picked this sample, called rfq.doc.

I quickly learned you often can’t directly pull out the actual evil VBA scripts. The hackers compressed or hid them, and they won’t show up in Word’s built-in macro tools.

You’ll need a special tool to extract it. Fortunately, I stumbled upon Frank Boldewin’s OfficeMalScanner. Danke, Frank.

Using this tool, I pulled out the heavily obfuscated VBA code. It looks a little bit like this:

Attackers are really good at obfuscation, and my efforts in creating Evil.doc was clearly the work of a rank amateur.

Anyway, next time we’ll get out our Word VBA debuggers, delve into this code a little bit, and compare our analysis to what HA came up with it.