Obfuscation at all stages — An interesting case of Emotet infection

I heard a lot of buzz about the recent Emotet infrastructure take down by Europol and few other crime agencies around the globe. Interestingly, at the same time, I was analyzing a WORD document with a malicious macro embedded. At the end of the analysis, I figured out that the macro code was eventually leading to the Emotet infection on the victim.

Findings at a glance!

I picked a WORD document uploaded on MalwareBazaar and analyzed the embedded macro code. The analysis ended up to a packed Emotet trojan downloaded from one of the 7 URL IOCs.

Word document’s SHA256: ec889256894e0feb6ed386ae5c414149c62b29f3c4a2e2a1a3411c0a982984e0

Here is a summary of several stages of infection which leads to Emotet getting downloaded and ran on the victim machine:

1Microsoft Word document contains a highly obfuscated malicious macro code.

2Macro code runs a highly obfuscated PowerShell script.

3Two-layered obfuscated PowerShell script contacts 7 URLs to download a malicious DLL.

4Downloaded DLL is a packed Emotet.

5This DLL gets executed using rundll32.exe.

Technical details

Macro code debugging

By using the default WORD Macro debugging feature, I looked at the macro code and immediately found it suspicious based on its high obfuscation. This macro gets executed when the document is opened.

Document_open() runs a function B4grokrgjv2ifyzq

There are tons of GOTO jumps and strings were created using Replace commands. Take a look at how the macro code looks like:

Highly Obfuscated Macro code

I added several variables to the Watch window to see how their value changes as macro gets executed. I also added breakpoints to important lines of code. Here is a quick glance of all the variables and its values when the macro code hits an interim breakpoint:

Macro Code variables value

Just by looking at the variable ‘Br7ox619ois74tv’, it looks like the macro is going to open cmd.exe and display a textbox to the victim mentioning that Word faced a problem opening a file and in the background it runs an encrypted PowerShell script in a hidden window.

Macro shows a textbox to victim and executes PowerShell script as hidden

The macro code also uses win32_process method which will be used later to execute the downloaded Emotet sample.

Contents of variable ‘C97hfjxrastoql’

Unpowering the PowerShell command

The next stage of analysis is to look at the encrypted PowerShell script and reverse it to see what actions it performs. I pulled the PowerShell script from the ProcessHacker tool and it looks like this:

Highly Obfuscated PowerShell script

Using PowerShell debugging feature Script Block Logging, I looked at the contents of event ID 4104 from Windows Event Viewer. What I found was another layer of obfuscation used to slow down the analyst. The content of this version looks like this:

Contents of Event ID 4104

Going further, I used PowerShell ISE to debug this version since it will be tedious and time consuming to run through the whole script manually. First, I removed some obvious noise from the scripts like dots, commas, etc. Once this noise was removed, I placed several breakpoints using PowerShell ISE:

Script in PowerShell ISE

Extracting the IOCs

Once the script is loaded in PowerShell ISE, I placed breakpoints at each and every line and started to observe the values of the variables. This is the point where I was one step closer to the IOCs. Take a look at the variable named ‘$U5tym2l’.

Indicators of Compromise (IOCs)

If you look at the foreach() function used in the script. It tries to contact all the above URLs to download a file. I checked all of them on VirusTotal and few came up as a known malicious domains. Others we not!









Let’s do a SYN!

I contacted each of these IOCs using a genuine looking browser request. Most of them were not reachable. However, when I visited hxxp://xunhong(.)net/sys-cache/D0/

I was able to download a DLL file with name dfx.dll. This is indeed the packed Emotet trojan which gets delivered to the victim.

SHA256: 01e14d7d7d88ef53d4f9443170bff682dc9c72f13451c18c9032a5e440975e98

I was observing the execution of the PowerShell script on WireShark as well and it did confirm the communication to the above URLs:

WireShark capture for malicious PowerShell script

Analysing the DLL

The DLL which was downloaded is the packed version of the Emotet trojan. This means there are still actors out there using Emotet for their campaigns. Once this DLL is downloaded, it is ran using the rundll32.exe file since DLLs cannot run by itself. Take a look at the PowerShell script calling rundll32.exe to execute the Emotet sample downloaded using DownloadFile function.

Rundll32.exe called to execute downloaded DLL

Using PEStudio, I looked at the static values of the DLL header. The compilation time shows it was compiled on 20th Jan 2021 which is very recent:

Compilation time of Emotet

The Sections and the list of imports of this DLL indicates it is a packed sample. Use of libraries like LoadLibraryA and existence of text7 and text6 sections with 0 entropy probably indicates it is going to unpack itself in these areas.

Sections of malicious DLL
Imports of malicious DLL


The efforts to analyze a macro code from a Word document lead to several stages of infection which ultimately executes a Emotet trojan on a victim machine. Regardless of the takedown of the Emotet infrastructure, the attackers are still using it for their campaigns. One of 7 URL IOCs is actively hosting the malware.

I hope you liked this piece of analysis and feel free to provide feedback and suggestions! Thank you!