Malware Analysis: Emotet’s 2021 Resurgence
Botnets, a network of infected computers, have long been used to conduct some of the most notorious threat campaigns in the past. Emotet, likely the kingpin of the ‘botnet’ world, was finally disrupted by swift law enforcement action in late January, 2021. As defenders took up arms loaders like SquirrelWaffle, the botnet resurfaced - just ten months after its ultimate takedown.
In this article, we’ll uncover technical indicators from the most recent mal-spam campaign by Emotet along with differences in their operational tactics in late 2021.
Emotet’s Return: How Did It Unfold?
Europol’s successful dismantling of Emotet was cherished globally. At the time of disruption, Emotet was estimated to have infected over a million workstations with hundreds of servers used to host the malware. Following a malware-as-a-service (MaaS) model, it was linked to several ransomware attacks against renowned businesses wherein initial access was sold off to sophisticated threat actors.
However, the disruption didn’t last long. Luca Ebach, a security researcher, shared his findings on the resurgence of Emotet wherein the malware was being spread from a different malware botnet, TrickBot. TrickBot ultimately became the go-to malware loader for most cyber-crime families to continue their e-crime operations.
At the time of reporting by Lucas, Emotet wasn’t redistributing itself; however, that didn’t last long either. Emotet infections are now growing rapidly as each infection now begins mass-spamming emails to new recipients - forming a long chain of infections. Here’s a brief overview of the number of actively reported Emotet distribution URLs by abuse.ch:
Let’s dive into one of the Emotet infections and see what we can uncover from a quick Technical Analysis.
Technical Analysis of Emotet
Technical Analysis of Emotet is broken down into two subsections: Network Analysis and Host Analysis. Sample documents, packet captures, and emails from the recent Emotet campaigns were shared by Brad from @malware_traffic. You can acquire them from this link and follow along.
Host Analysis of Emotet
Emotet infections typically start with spam emails or stolen email chains wherein the receiver’s trust on the sender is exploited. Emails have attachments in the form of direct or zipped macro-enabled Word of Excel documents which are used to acquire stage-two DLLs. Here’s a sample email from Brad’s dataset:
Using oletools, we can quickly analyze the functionality of the Word document. Since the macro is heavily obfuscated, we can’t pull all URLs without putting in work.
Again, thanks to the wonderful InfoSec community; we have an automation script to de-obfuscate all URLs quickly. The Gist from @DissectMalware has the script which you can use to obtain the following URLs (defanged for your safety):
These URLs are used to acquire stage-two DLLs which infect the system, communicate with the C2 server, and generate more malspam from the infected machine. The DLLs were initially dropped in the C:\ProgramData\ folder with a random name and a .DLL extension. However, recent infections show the dropped DLLs have been moved to the AppData\Local directory where a new directory is created with a random name and the extension of the DLL is random as well.
Using chained infections, the botnet grows in numbers and has already achieved thousands of infections in a matter of two days. Let’s continue our analysis on the network front and see how Gigasheet can aid our analysis!
Network Analysis of Emotet
Zeek is an excellent network traffic analysis framework which we’ll be using to break down the packet capture into useful protocol-based logs. Using the following command, you can parse the PCAP file using Zeek:
zeek -r emotet-packet-capture.pcap -C
These log files can now be easily ingested into Gigasheet via the Your Files page. Simply select Upload and browse to the log files on your local disk. Gigasheet’s going to handle the rest - ingestion, pre-processing, and formatting. Though Zeek does have several utilities to format the log files into readable output, the command-line input can often be difficult to remember.
Once the processing completes, we can kick off our analysis from the http log source since we’ve already identified the URLs which will be used to acquire the stage-two DLL. Fortunately, there’s just one log in the http.log file.
Although we know this log is used to acquire a DLL from the compromised website, we can still make sure of it using the FUID field and by checking the length of the response. The response is 485376 bytes in length which does indicate a larger file must’ve been transferred. Scrolling down in the same log, we should see a FUID and Filename indicator which solidify our hypothesis on the URL’s nature.
We can correlate the FUID from the files.log file and identify more information about the transferred file. The filename indicator can also be used to hunt for the DLL file on potentially compromised systems. If you review the deobfuscated macro code, you’ll also notice how the file is dropped to C:\ProgramData. Pair it with the filename and you have a solid host-based indicator.
Using the same FUID, we can also pivot to the pe.log file. This log file presents a short summary of the PE file which might be useful during your static analysis efforts. You can even go a step further and dump the PE file using Zeek’s auto-extraction plugins.
Going back to the conn.log file, we can find traces of encrypted C2 communication. Emotet’s post-infection C2 communication used to be unencrypted before Europol’s takedown. This change in C2 communication is likely the only major difference in Emotet’s operations since the resurgence of the malware. Filter on port 443 using the Filters option in Gigasheet to acquire all IP addresses from Emotet’s C2 infrastructure. We can go a step further and group the rows together using the ID.RESP_H field to get a list of all unique IP addresses.
After the C2 communication concludes, the infected system begins to generate more Emotet mal-spam as can be seen in the figure below. Ports 25, 465, and 587 are specifically used for SMTP and are used to deliver mail to recipients (as can be seen in the smtp.log file as well). Though we’re not sure if the stolen email threads are from older compromises or acquired from infected systems on runtime, stolen threads are used to target the recipient’s trust on the sender thereby multiplying infections.
As of writing, Emotet infections generate spam emails from infected systems which helps the botnet grow in numbers. In time, access to compromised systems is likely going to be sold off on the dark-web markets to bidders - often ransomware groups looking for luscious targets to compromise. Stay safe and only open emails you’re sure are from a trusted sender, understand the email’s context, double-check email attachments, and scan them using an antivirus solution (Defender should do just fine).
If you’re an analyst looking to quickly analyze the latest mal-spam campaign of Emotet, give Gigasheet a try. Click here to sign up, add the network traffic capture to your account, and get started with identifying the C2 URLs now!