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.
Emotet is commonly delivered in phishing campaigns via a macro-enabled Word documents, and I recently saw one of these newer Emotet maldocs come across my desk. Since I haven’t done a post on these malware campaigns in a little while, I thought it would be worthwhile to take a quick look at how these maldocs are designed to execute the obfuscated PowerShell script, which then fetches the next stage payload (the Emotet loader). Here, I will simply take a quick at the code obfuscation and provide a few details about this new campaign, with an added double bonus for a both a method to crack the password-protected ZIP archives and also a handy new CyberChef recipe so that analysts and responders can decode the embedded PowerShell Scripts, in order to quickly extract the network-based indicators of Compromise (IOCs).
The Campaign
The best way to stay current on developments is to follow the Cryptolaemus Team for the most up to date developments. Emotet campaigns are generally spread across three distinct botnets or “Epochs” that have independent infrastructure, but do have some operational overlap in many cases. Recent campaigns have involved either Word document attachments or embeded URLs that lead to the download of a weaponized word Document.
The document I analyzed for this post was likely delivered on Epoch 1 as this was a Word doc that was delivered via an attachment as a password protected ZIP archive. The password for these types of campaigns are provided within the body of the email, and this tactic has been increasingly leveraged by a variety of threat actors in recent months. In particular, I have seen this associated with BokBot (IcedID) campaigns, but also Dridex and Ursnif campaigns have utilized this to a lesser extent.
I had access to the ZIP archive in this case, but not the email with the password. This wasn’t a problem as I was able to crack the archive with a python script I wrote called zip-crack.py. More details on the script and its usage can be found here on my github. With my program you can choose between a regex method or a dictionary attack against the archive. I would highly recommend utilizing the regex method in these campaigns as OSINT suggests the passwords are random, 3 or 4 digit numeric strings, which can easily be modified in the script to crack these quickly.
Figure 1. speed difference
This is just a quick example of the speed improvement on using the regex method vs the dictionary method. There are certainly some ways increase speed by modifying the structure of the dictionary in the passwords.txt file for these campaigns, as it was primarily designed for BokBot, but that will need to be a task in the backlog for another time.
The Document
Anyways, using the cracked password “9186” I had access to the Word doc. The overall infection chain in this case remains pretty much the same: a malicious Word document that is weaponized with macros is opened, which launches a WMI process via the “winmgmt” service. The winmgmt call is heavily obfuscated in one of the macro streams of the document. There are several variable assignments that correspond to strings that then require “]e1r[S” to be replaced with an empty string. This is the first of three such replacements where this particular character grouping is utilized in the document, albeit in different obfuscation schemes.
Figure 2. Macro obfuscation for WMI
This technique is interesting as it appears to leverage the wmiprvse.exe process that is already running, which then creates an instance of CMD to spawn the PowerShell process. This is noteworthy as in a sense, it de-couples the process tree from the typical parent/child relationships of Outlook > Word > WMI > CMD > PowerShell that may be common in many environments. Nevertheless, this should still be detected via the encoded PowerShell, but it does create a somewhat weird look for the process tree. For example:
Figure 3. process tree
That script attempts to download the core binary from 7 hardcoded URL resources (These IOCs provided below). This document was related to the spam runs from 12/29/20.
- filename: Info_3012.zip
- SHA256: 8B216E03269C13A51BF31C7279EA815A8A4BDFBD0A88905C195D4DCC44363C21
I pulled the document down from VirusTotal. These campaigns appear to be using the “Red Dawn” template in order to induce the victim into enabling macros. Much more about related campaigns is available thanks to the incredible work of researchers with the the Cryptolaemus team and Brad Duncan over at Malware Traffic Analysis.
Figure 4. Emotet doc downloader template
The PowerShell script that is executed when macros are enabled is base64 encoded per usual. The PowerShell blob is actually just hidden in plain sight in the document as shown as a grey-shaded area in Figure 3. This can be just be copied out to a text editor to reveal the first layer of obfuscation:
Figure 5. Hidden text extracted from the document
Stripping the formatting of the hidden text reveals a nearly 5 page long string that appears to have several repeating characters. You could probably guess that it would be a good idea to do a string replace on that character set. We can see confirmation of this from some of the macro code in the VBA project. This is the second of three usages of “]e1r[S” :
Figure 6. Macro code snippet.
This indicates the string “]e1r[s” will need to be replaced. Performing that operation gives us the following decoded CMD that includes an error message pop-up and the obfuscated PowerShell script:
Figure 7. Obfuscated script and error message
The URLs that are hosting the next stage payload, which is the Emotet loader are obfuscated with base64 encoding and several string replacement operation. This is slightly more complex that in the recent techniques, but still leverages an empty string replacement for, while a character replacement is used to swap ‘qqs2’ for the slash ‘/’ ‘qqs2’ for the slash ‘/’character and the same string we saw earlier (“]e1r[S” for the third and final time) is swapped for “http”. At that point, an analyst would just need to split the the string at the “@” delimeter, use a regular expression to isolate URL patterns, and then defang for sharing.
Here is the code for the recipe in Chef format, which I also have on my GitHub:
From_Base64('A-Za-z0-9+/=',true)
Remove_null_bytes()
Find_/_Replace({'option':'Simple string','string':'\'+\''},'',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'\')+\''},'',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'\')+(\''},'',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'\'+(\''},'',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'\')'},'',true,false,true,false)
Find_/_Replace({'option':'Extended (\\n, \\t, \\x...)','string':'+'},'',true,false,true,false)
Find_/_Replace({'option':'Extended (\\n, \\t, \\x...)','string':')'},'',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'('},'',true,false,true,false)
Find_/_Replace({'option':'Regex','string':'\''},'',true,false,true,false)
Find_/_Replace({'option':'Extended (\\n, \\t, \\x...)','string':'@'},'\\n',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':'qqs2'},'/',true,false,true,false)
Find_/_Replace({'option':'Simple string','string':']e1r[S'},'http',true,false,true,false)
Regular_expression('URL','([A-Za-z]+://)([-\\w]+(?:\\.\\w[-\\w]*)+)(:\\d+)?(/[^.!,?"<>\\[\\]{}\\s\\x7F-\\xFF]*(?:[.!,?]+[^.!,?"<>\\[\\]{}\\s\\x7F-\\xFF]+)*)?',true,true,false,false,false,false,'List matches')
Defang_URL(true,true,true,'Valid domains and full URLs')
This Direct Link has the recipe already preloaded in CyberChef.
Summary
So that’s it. Just a quick look at some new PowerShell obfuscation used by Mummy Spider in recent campaigns. These campaigns came as a bit of a surprise as their operational cadence often decreases around the holidays. But, threat actors are constantly tweaking their tactics in a constant cat and mouse to avoid detection, and Mummy Spider is no different. In this post we examined not only the updated obfuscation schemes but some tooling with Python and CyberChef that defenders can leverage to increase their velocity in support of an incident response investigation.
References
https://malpedia.caad.fkie.fraunhofer.de/details/win.emotet
https://www.us-cert.gov/ncas/alerts/TA18-201A
https://www.crowdstrike.com/blog/meet-crowdstrikes-adversary-of-the-month-for-february-mummy-spider/
https://gchq.github.io/CyberChef/
https://github.com/Sec-Soup/Python-ToolBox/tree/master/zip-crack
https://docs.microsoft.com/en-us/windows/win32/wmisdk/winmgmt
https://www.virustotal.com/gui/file/8b216e03269c13a51bf31c7279ea815a8a4bdfbd0a88905c195d4dcc44363c21/detection
https://www.malware-traffic-analysis.net/2020/12/28/index.html
https://github.com/Sec-Soup/CyberChef-Recipes/blob/master/Emotet-Recipe_20201229IOCs
hxxp[://]haciaelsup[.]com/wp-includes/fhPe00/
hxxp[://]gudafu[.]com/k/x/
hxxps[://]raymodul[.]com/wp-admin/kZPis7j/
hxxps[://]telelogical[.]com/user/SP0HX/
hxxps[://]thinkily[.]com/css/N/
hxxps[://]theloveiskindnetwork[.]com/wp-includes/Z/
hxxps[://]iotachina[.]com/wp-content/jYKbuKG/Article Link: https://security-soup.net/quick-post-mummy-spider-delivers-emotet-maldocs-for-the-holidays/