Tool-Less Extraction of IOCs from an Emotet Maldoc
This blog post covers how to examine and extract the underlying payload from a recent Emotet delivery campaign. We will cover how to use basic dynamic analysis to quickly step over VBA obfuscation.
For the purpose of this blog we will be working through a recent (22 Jan 2021) Emotet maldoc which was uploaded to any.run:
As seen in the any.run execution playback, upon opening the document the user is presented with a fairly standard message which encourages the user to enable macro's which will allow the document payload to execute.
Although we could use tools like OLETools or ViperMonkey to extract the underlying macro from the document and analyse it, Emotet payloads tend to be heavily obfuscated to hinder analysis, and also commonly reference document elements which makes them challenging to analyse outside of the source document.
For the purpose of this blog post we will take a manual approach to analysis, this has the benefit of covering techniques which will be applicable to a wider variety of samples.
Examining the Macro Code
Regardless of the obfuscation technique that's used, we can typically rely on Word's inbuilt VBA editor to step through the macro code and set breakpoints on interesting lines. Upon opening the maldoc in word (in our malware analysis environment) we are met with Words compatibility view and limited actions until we enable Macro's:
A useful tip to view the macro without enabling them first is to press Alt + F11to jump to the VBA editor window:
Now that we can view the VBA code we can see that it's not only obfuscated but also quite lengthy (443 lines). This length is typically due to malware authors adding additional unneeded code to make analysis more challenging and time consuming.
Although the code is obfuscated, there are typically VBA function calls which are important to maldoc execution that can't be easily obfuscated. Example of such function calls are .shell , .execute and .create. We can use these strings as jump off points to look for interesting areas in the code:
At line 215 we can see a reference to .Create on the Vu_11x18hez object. To progress our analysis we need to view the contents of the three arguments that are passed to this call: nnjasd, Rl1ti2fji75p and T3vin8nf9s1bh9qa1s.
Instead of manually working out the values of these variables, we can use breakpoints to pause execution at line 215 and print out the contents of the three variables just before. We can do this by right clicking on line 215 and choosing Toggle->Breakpoint, and also adding three instances of Print.Debug() above this line to show the contents of the interesting variables:
The last step is run the macro (the green play button at the top) and hope that we hit the breakpoint on .Create before the maldoc fully executes:
it looks like we forgot one step before executing the macro. As we used the Alt+F11 trick to view the VBA code without enabling macro's for the document, we now can't execute the the macro. To get around this issue we can remove the trigger that the macro uses to auto execute when the document opens.
Selecting the document in the Project browser on the left side of the editor allow us to spot the Document_open() function which will execute the Fwevp6c2ys9d136g function as soon as the document is opened and macro's are enabled:
As we want to control when the macro is run (after we've added our breakpoint and Debug.Print() commands) we can simply remove this section of code, save the document and then enable macros.
After saving your changes to the document and enabling macros, you will need to re-add the breakpoint on line 215
All going well the macro should not execute until we click the play button, at which point we should see our breakpoint line highlighted in yellow to show that execution has paused:
Our Debug.Print() statements will hopefully have output the contents of the nnjasd, Rl1ti2fji75p and T3vin8nf9s1bh9qa1s variables to the immediate windows in the editor. We can view the contents of this window by pressing Ctrl + G:
Success! Can we see the underlying CMD and Powershell commands that the maldoc executes. Although there may be additional functionality stored in the VBA code of the maldoc, we can move onto analysing the powershell script as it likely contains the bulk of the maldoc payload.
The first part of the command is a simple cmd statement which displays a message box on the screen and informs the user that Word experienced an error trying to open the file , this serves as a method to deter the user from wondering why nothing happened after enabling macros.
The powershell command executed after the cmd statement is what we're really interested in, we can see that it executes a base64 argument string so the next step is to decode the arguments:
The decoded arguments reveal a slightly obfuscated powershell script which is difficult to fully understand in its current format. However, we can see a few string references which gives us an idea of what the script does:
crEATedIRECtoRY - create a directory on the local filesystem
sYSTEM.neT.weBCLIEnt.DOWNLoaDFiLE - download a file
rund+ll3+2 - execute rundll32 to execute a DLL
To improve the readability of the script we can clean it up a little. For a script of this size we can do it manually by breaking the script down into chunks and using a powershell console to get the de-obfuscated output after execution. After cleaning up the script and adding a little bit of formatting we get the final code below:
The code above is an estimated structure of the original obfuscated code. It may not run correctly in its current form.
Examining the final decoded powershell script we can clearly see the payload of the maldoc. When executed the powershell script will create the directory structure \r_qc9st\sp71w9e under the current users home directory. It will then contact a series of hardcoded domains and attempt to download a DLL which it will store in the previously created directory under the name r49d.dll. Finally the script will attempt to execute the DLL using rundll32. This will launch the second stage of the emotet payload which will be covered in a future blog post.
