Saturday, June 1, 2019

Japan Themed Emotet Utilizes WMI to Execute Obfuscated PowerShell

01 June 2019

 I recently came across an interesting sample of the Emotet trojan that departs from the tried and true tactics of Word doc > VBA code > PowerShell script.  Well, those elements are still there, but how the PowerShell script is executed is different from what I have seen other Emotet samples accomplish. 

Emotet is a well known banking trojan that has been making its way through computer networks for a number of years. Just recently, an Emotet sample was discovered with a Japanese language e-mail and malicious document.  This sample was hosted at hxxps://pomdetaro[.]com. Unfortunately we don't have the technique used to deliver the malicious document, but we can assume email was used as an initial access point.


 Upon opening the document, we are greeted with probably the most well known screenshot known to mankind... or the infosec community.

Figure 1

Where things differ with this sample, is just how the PowerShell script is executed.  The document still contains VBA macros that are enabled once the user clicks the "Enable Content" button, however there is an added step. During my analysis, I had Process Monitor ( running. After filtering/excluding junk, we can get a crude version of events since the document was opened.

Figure 2

As you can see in the above image, there is a new process associated with WINWORD.exe that is not normally related to Emotet. Once macros are enabled on the document, the VBA code calls on WMI to execute an obfuscated PowerShell script.

Figure 3

Continuing down the rabbit hole in Sysmon, we come across another event that should be of great concern.

Figure 4

 Luckily, the obfuscation method isn't anything crazy and a little Python will give us a clear picture of the script that was executed.

Figure 5
Printing the script out via the terminal may not be the best on the eyes, especially when its around 1 a.m. We can throw the obfuscated code into CyberChef, and receive a much more appealing output.

Figure 6

So far a good bit of information and possible IOC"s have been gathered. But, we are far from done. The de-obfuscated code above reaches out to a number of compromised domains, downloads and starts the actual Emotet compromise of the computer. This file (162.exe for this sample) was downloaded and dropped into C:\Users\<user>\162.exe.

Figure 7
From here, 162.exe executes and drops another executable which reaches out to an Emotet C2 in the C:\Users\<user>\AppData\Local\ folder.

Oddly enough for this Japanese website, the Emotet executable in this case was named "alaskajpn.exe". This is likely a coincidence, and nothing to get excited over, but the naming did pique my interest as to if this was intentionally done, and if future campaigns will follow along the same lines.


One quick note about sandboxes. While there are many great options for us who love to conduct our research in a safe environment, sometimes the sandbox may not be capable of showing the researcher all the vital information of the sample.

Case in point, it took executing this sample in my own home lab environment to discover a number of additional compromised domains that were not identified in the sandbox.

Special thanks to URLhaus for supplying these domains.

Thanks for reading,


JPCert's Log Analysis Training

6 Aug 2020 About a week or so ago, JPCert released their Log Analysis training slides and corresponding CSV files for each hands-on exercise...