DeObfuscating Emotet’s Malicious VBA Macro Like a Pro!!

For a very long time, I was thinking of writing an article when I received an email that contained an attachment having some sort of an invoice.

The mail seemed legit, though suspicious, and I decided that it would be a good time to write up an article on how we can analyze the malicious attachment and deobfuscate malicious VBA macros from it to have a better understanding of what an attacker was trying to achieve.

I believe this attachment is related to an Emotet malware as per the VirusTotal results and a few similar attachments, which I have seen earlier where the same techniques were being used to infect a victim’s machine.

So, What’s an Emotet?

If you are a security professional who always tries to keep himself/herself updated, then I am sure that you would have definitely heard or read somewhere about the emotet malware. But if not, then worry not, as I’ll try to give you a brief overview of the emotet malware and how dangerous it is.

As per Wikipedia:- “Emotet is a banking Trojan malware program which obtains financial information by injecting computer code into the networking stack of an infected Microsoft Windows computer, allowing sensitive data to be stolen via transmission. Emotet malware also inserts itself into software modules that are then able to steal address book data and perform denial of service attacks on other systems. It also functions as a downloader or dropper of other banking Trojans.”

Emotet is one of the most prominent malware of all time and is considered very dangerous to organizations due to its ever-changing behavior (polymorphic malware) and evading security mechanisms. Current emotet malware has also the capability to detect whether they are being run in a sandbox machine and can thwart the analysis.

My Machine Setup for Analysis!!

• FLARE VM (One can install it by navigating to the link here)
• Windows 10 x64-bit, where Flare VM will be installed.
• Microsoft Office 64-bit
• An extra tool exiftool is required.

I decided to use Flare VM from FireEye as I don’t have to create a lab from scratch and install every tool required for analysis. Plus, it’s a hectic and time-consuming task to configure each tool as per your need.

Flare VM is an all-in-one virtual machine for your analysis. And you don’t have to waste your time setting up your lab. Everything comes pre-installed.

Technical Analysis of Malicious VBA Macro

So, the sample I’ll be using today is quite an old one, and the technique would be outdated for malware like emotet as they keep on evolving themselves.

But the main motive of this write-up is to show you how you can go ahead and analyze and extract macros from any malicious document (if you encounter any).

SHA256 hash: 5a8b91fac4cdd9220dae03dc4160d8d77fb509482d14370da38227b5de7ee639

It’s generally a good approach to start analyzing the sample without actually opening it and gathering as many details as possible. Since we already know that our sample is a malicious word document and has macros, we can straight away extract the macros by using a tool called olevba, a part of a python-oletools package of which you don’t have to worry about going to the Internet and grabbing a tool. It comes pre-installed with FLARE VM.

Here in the image above, a subroutine OpwUzGpsi is created and some code is written inside to it which will do some crazy stuff at the back-end when the same function is called.

From the code itself, we can guess that ActiveDocument.BuiltInDocumentProperties("Comments") will carve out some code from the Comments section of the document and will be stored in the desired variable.

The below image is a continuation of the above section. Once the meaningful code has been extracted from the Comments section, the function will then execute the malicious macros into our system. Some key things to notice here are VBA.Shell$ which will execute whatever is set in the variable RzUZw. Next, we can see the subroutine AutoOpen which will auto-execute the malicious macro once you open up the word document (provided you have clicked on the Enable Content macro security warning).

Now, since we got an overall idea of how the document will pull out other data from the Comments section to make it work together, we have to focus on finding that section so that finally, it can form a complete macro. But how we are going to find that Comments section? Worry not. I got you covered.

Before we do that, let’s just extract the emotet macro that we saw earlier and save it in a separate file called macros.txt.

The next best approach to extracting information from any sample is to always look at the sample’s metadata. Metadata can provide you with tons of information related to a particular file, and attackers mostly hide their payload in the metadata as it is not visible to the user when he/she views the document or any file. You have to use some sort of tool to view the metadata part.

Doing an ExifTool on our malicious sample presented us with the details about the document. This information can be beneficial as it can help you connect the dots. But it doesn’t always have to be true. Some attackers purposefully change the information just to throw you off your analysis.

In my case, I was lucky enough to see that the attacker had hidden the giant blob of obfuscated code in the metadata of a file in the Comments section.

This is where the main macro will be pulling out a few other data from the comments section. Let’s save the metadata to a text file doc_comments.txt and we will remove everything that is not a code. Refer to the image below:

It is time where we play with the macro a little bit but take caution as you don’t want to enable the macro and infect your machine accidentally. In that case, simply revert your machine to the last saved snapshot.

Now let’s open up our malicious document file, and we will edit the macros. Navigate to the VIEW tab -> Macros -> View Macros and edit the AutoOpen macro. This will open up a Visual Basic window showing the contents of a macro.

On this window, after opening up an Immediate window and overwriting the VBA.Shell$ with debug.Print, the edited text becomes debug.Print (RzUZw).

Debug.Print tells the VBA to print that information in the Immediate window. This can be useful when we want to see the value of a variable in a particular line of our code without having to store the variable somewhere in the workbook or show it in a message box. It is especially useful when you are writing or debugging code.

After saving the macro and enabling the content, I was presented with the obfuscated code in the Immediate window. Copy the whole code and save it as encoded_powershell.txt.

We are almost there to fully decode the obfuscated macro. From the image above, we can see that it is trying to launch Powershell and doing something. But we don’t know what it is trying to achieve as the code is still obfuscated. But what we know is that code is Base64 encoded which we will have to decode to see what’s behind that encoded code.

So open up the text file where you saved the code earlier and remove the text “powershell -e” from the code and also remove any whitespaces and save the file. We can decode this Base64 code either by going online in our host machine and using an online tool, or we can use an inbuilt tool called “Certutil” in Windows.

If we open and check the decoded_powershell.txt file we can see that the code is still obfuscated and has many numbers from where the data will be pulled out and finally joined as a string to make up a whole new string.

For de-obfuscating this part of the code, what we can do is follow a little trick. We have to identify a first open bracket by highlighting the last closing bracket, and once identified, remove everything before the first bracket and type write-host.

With write-host, it does not output data to the PowerShell Object flow engine to execute the code instead, it writes everything to the host as we can see the output in the image below.

Soon after passing the entire code into the PowerShell and hitting enter, we now have our complete decoded macro. Frankly speaking, It was really good to see the deobfuscated code. But still, we need further enhancements to make it more readable as it still looks gibberish.

Finally, after doing some enhancements, the macro looks more readable and we can now quickly figure out what’s happening by just looking at the code.

Here in the image above, the attacker has set a variable $wscript that will create a new instance of WScript.Shell. The WScript.Shell class provides several valuable utilities that greatly extend the range of tasks performed using Windows PowerShell and COM, such as running applications, sending keystrokes to running applications, changing the current working directory, and displaying popup message dialogs.

Next, the new instance of System.Net.WebClient class is set in a $webclient variable which provides common methods for sending data to and receiving data from a resource identified by a URI. And the attacker has set three different URLs from where the additional binaries would be downloaded and saved in the temp folder with a random name, and finally it will start executing it from there.