From a very long time, I was thinking of writing an article where I received an email which contained an attachment having some sort of an invoice. The mail seemed legit though but however, was 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 extract the 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 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 pretty much 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 which are then able to steal address book data and perform a 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 times and is considered very dangerous to organizations due to their ever-changing behavior (polymorphic malware) and evades 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 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 highly urge you to take a snapshot of your VM once you have installed all the necessary tools for analysis. This would save you from some extra time in setting up your VM again in case of any mishap.
I decided to use Flare VM from FireEye as I don’t have to create a lab from scratch and install every single tool which is required for analysis. Plus it’s a hectic and a time-consuming task to configure each and every 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 own lab. Everything comes pre-installed apparently.
So, the sample which 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).
It’s generally a good approach to start analyzing the sample without actually opening it and try to gather as many details as possible. Since we already know that our sample is a malicious word document and is having 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.
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 now 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 macro what we saw earlier and save it in a separate file called
The next best approach towards extracting information from any sample is to always look at the metadata of the sample. 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 has hidden the large 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 accidentally enable the macro and infect your machine. In that case, simply revert back 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
debug.Print, the edited text becomes
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 certain 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
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 it to see what’s behind that encoded code.
So open up the text file where you saved the code earlier and remove the text “
If we open and check the
decoded_powershell.txt file we can see that the code is still obfuscated and is having a bunch of 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 to 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
With write-host, it does not output data to the PowerShell Object flow engine in order to execute the code but instead, it writes everything to the host as we can see the output in the image below.
Soon after passing the full code into the PowerShell and hitting enter we now have our full final decoded macro. Frankly speaking, It was really good to see the deobfuscated code. But still, we need further enhancements to do to make it more readable as it still looks gibberish.
Finally, after doing some enhancements the macro looks more readable and we can now easily figure out what’s actually happening by just looking at the code.
Here in the image above the attacker has set a variable
$wscript which will create a new instance of
WScript.Shell. The WScript.Shell class provides a number of useful utilities that greatly extend the range of tasks that can be 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 temp folder with a random name and finally it will start executing it from there.