
This article is part of the Fileless Malware series. All other parts of the series:
I am a fan of the
hybrid analysis site (hybrid analysis, hereinafter HA). This is a kind of zoo malware, where you can safely watch the wild "predators" from a safe distance without being attacked. HA runs malware in safe environments, records system calls, files created and Internet traffic, and displays all these results for each sample analyzed. Thus, you can not waste your time and energy, independently solving the entangled code, and immediately understand all the intentions of hackers.
The HA examples that caught my attention use either encoded 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 usually send Base64 encoded commands to PowerShell. This is all done in order to make the attack difficult to detect by web filters and antivirus software that react to certain keywords.
Fortunately, HA automatically decodes Base64 and immediately shows everything in a readable form. In fact, you do not need to focus on how these scripts work, because you can see the full output of commands for the processes being started in the corresponding HA section. See 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 a lot of 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 of the goals of this exercise is to show how a (relatively) easy hacker can bypass classic perimeter defenses and antiviruses. If an IT blogger with no programming skills like me can
create an undetectable malware (fully undetected, FUD) in a couple of evenings, imagine the possibilities of a young hacker interested in this!
And if you are a person who provides IT security, but your manager doesn’t realize the possible consequences of these threats, just show him this article.
Hackers dream of getting direct access to the victim’s laptop or server. It’s very simple to do: all a hacker needs is to get some confidential files on the CEO’s laptop.
I once
wrote about the PowerShell Empire post-operational runtime environment. Let's remember what it is.
In fact, 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 environment for testing malware 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 dismissed for launching viruses inside the enterprise perimeter).
If you run PowerShell Empire, you’ll see something like this:

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). So, for your part, start waiting for the network connection from the remote shell:

For the other hand, you will need to generate the agent code by entering the “launcher” command (see below). This will generate a 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 out this agent to run PowerShell instead of innocuously outputting text 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 the role of an innocent victim and opened Evil.doc, thereby launching our JavaScript. Remember the first part? PowerShell has been 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 the majority will not cause any alarms. Because it is an ordinary PowerShell, isn't it?

Now, when you start Evil.doc, the hidden background process will connect to the server with PowerShell Empire. When I 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 the Taco server, which I myself once set up.

What I have just demonstrated does not require so much work from you. You can safely do all this at lunchtime for one to two hours to improve your information security knowledge. It is also a great way to understand how hackers bypass external security perimeter protection and are hidden in your systems.
IT managers who believe that they have built indestructible protection against any penetration will probably also find it informative - well, if you can, of course, convince them to sit next to you long enough.
Back to reality
As I expected, a real invisible to the average user hacking is just a variation of what I just described. To collect material for the next publication, I began to look for a sample on HA, which works in the same way as my example. And I did not have to search for him for a long time - there are many variants of such an attack technique on the site.
The malicious program that I eventually found on HA is a VBA script that was embedded in a Word document. That is, I do not even need to fake the doc extension, this malware is indeed the most common Microsoft Word document. If you're interested, then I chose this sample, called
rfq.doc .
I quickly learned that often you can’t directly pull malicious VBA scripts out of 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 stumbled upon Frank Baldwin's
OfficeMalScanner scanner. Thank you, Frank.
Using this tool, I was able to pull out the highly confusing VBA code. He looked something like this:
Obfuscation was done by professionals. I was impressed!The attackers are really good at obfuscating the code, not so much as my efforts in creating Evil.doc. Well, okay, in the next part we will get our VBA debuggers, dive deeper into this code and compare our analysis with the results of HA.