2019-10-16 Emotet maldoc deobfuscated

This sample is from a batch of emotet emails that I found in the email filters back on Monday afternoon (2019-10-14). While all the documents had a different hash (attached to this write-up), the macro that was executed was the same. Based on the URLs found in this sample, this looks like it was from “epoch 2” of emotet as documented here. This write-up is to document how I managed to deobfuscate the macro script.

Analysis
=========
To make this easier, I decided to use OfficeMalScanner to get the files that contained the macro code. Looking at those files, there was an obvious pattern that could be seen. There is a lot of junk lines that either start with ‘Rem’ or a variable assignment of some sort. All of this was removed to help clean up the script. The following code block is the result of clearing out all the junk code and trying to “beautify” the script for ease of reading.

With this “cleaned” up version of the macro script, one should be able to eyeball what is going on. So we know that as soon as the Word document is opened and the macro is allowed, it calls the function ‘a0x1eb0cdf8e1.’ From there, this function then calls on some other functions to start building the script and removing the number ’62’ from the variable “a0x25b9289e14e520,” which proceeds to give you the statement “winmgmts:Win32_Process.” So now we know that WMI is being called to create a process. Since this is an emotet macro, we know that the MO for these use Powershell that has been base64 encoded. Also, considering that the macro has some textboxes in it, we can make the assumption that the Powershell code can be found there since there are some callouts to those textboxes. The issue is where and how to find it. This is where Didier Stevens’ oledump.py script comes in handy.

Initially I wanted to see the different streams that made up this script. I used the following command to see how the macro was laid out: ./oledump.py /attach/FA_10063455599_10142019.doc. That gave me the following output:

Since we already have the bulk of the script and just need to figure out where the Powershell code is, I start looking at the “ObjectPool” paying attention to how large they are (seen in the third column). The first one that I focus on is stream 22 (‘ObjectPool/_1632577980/contents’). So using this command: ./oledump.py -s 22 /attach/FA_10063455599_10142019.doc I can see what appears to be a large amount of base64 data. As a side note, as of late, emotet has been using a base64 encoded Powershell command that starts with ‘PAA…’ which is a great indicator of what you are dealing with. This will most likely change, but as of right now this seems to be the norm.

Based on this output, we can see there are a lot of ’62’s’ in the base64 string. Since we know that there is a function that gets called that looks for a ’62’ and replaces it with a null value (“”), we can assume that the Powershelll code is being run through this as well and that ’62’ need to be scrubbed from the base64 statement. I switched over to CyberChef to do the rest of the heavy lifting for me. The recipe for this is pretty simple: find/replace ’62’ with null, de-base64 the string, remove null bits, and then another find/replace looking for ‘;’ and replacing that with ‘\n.’ The actual recipe with the base64 string can be found here.