Hello there, today I’ll be analyzing Emotet C2 traffic using Wireshark. In this article we’ll go into stuff like Emotet’s infection chain, the C2 traffic and what it looks like and how Emotet drops it’s initial binary after infection.
Emotet, initially identified in 2014 as a banking malware, has undergone a whole lot of development over time. This led to the addition of extra capabilities including a dropper, which facilitates the dissemination of various malware families such as Gootkit, IcedID, Qakbot, and Trickbot.
The Chain of infection
The initial delivery for infecting an user might often come with a Microsoft Word document attached, or a ZIP file that has the Word document inside. Lately, I’ve noticed some of these ZIP files being protected with passwords. Some Emotet emails don’t include any files but provide a link to download the Word document.
Upon downloading & opening the document, users are prompted to enable macros. Enabling macros help with quickly completing tasks and minimize the time spent on keystrokes. Such tasks can be formatting data, creating predefined programs. But it also allows the functionality of executing vba code embedded inside the doc. Once these macros are enabled, initial payload is downloaded which infects the system subsequently leading to the introduction of additional malicious files onto it. Below diagram shows Emotet’s infection flow.
In terms of network activity, the progression from an Emotet Word document to an Emotet infection involves the following stages:
- Web traffic is generated to fetch the initial binary.
- Encoded or encrypted command and control (C2) traffic occurs over HTTP.
- Further traffic for infection emerges if subsequent Emotet drops introduce additional malware.
- If Emotet employs the compromised host as a spambot, SMTP traffic may also be observed.
It has been observed that in the past 2–3 years Emotet’s initial binary hasa changed to a .DLL (Dynamic Link Library) file from a .exe back then when it started.
Emotet’s C2 traffic is encrypted or contains encoded data which is transferred over HTTP via POST requests. The C2 traffic is used to fulfill multiple goals like sending stolen data from victim’s machine to attacker’s server, updating the Emotet binary, and mal-spamming for further infections over TCP ports like 25, 465 & 587.
We’ll be using Wireshark to analyze the network traffic. So let’s begin…
Traffic Analysis
Upon opening the pcap file in Wireshark and filtering to view the HTTP/TLS traffic. We can see multiple attempts at downloading the initial binary after the user enabled macros on the malicious doc.
The first five HTTP GET requests represent four URLs used to retrieve the initial Emotet DLL. This traffic comprises of below URLs with their responses:
- hangarlastik[.]com GET /cgi-bin/Ui4n/
HTTP/1.1 302 Found - hangarlastik[.]com GET /cgi-sys/suspendedpage.cgi
HTTP/1.1 200 OK - padreescapes[.]com GET /blog/0I/
HTTP/1.1 401 Unauthorized - sarture[.]com GET /wp-includes/JD8/
HTTP/1.1 403 Forbidden - seo.udaipurkart[.]com GET /rx-5700–6hnr7/Sgms/
We can see that the request to the URL seo.udaipurkart[.]com doesn’t show any response as it does for the other requests.
So we follow the TCP stream to see what was the response for the request or if anything was downloaded. And this is what we see…
The TCP Stream shows that the request to the URL didn’t turn out to be empty; instead, it downloaded a file called ‘nDUrg8uFD5hl.dll’. This is supported by the presence of the letters “MZ” which are the magic number present in the headers of both .exe and .dll files. Furthermore, the presence of the string “This program cannot be run in DOS mode” indicates that the file is either an executable (.exe) or a dynamic link library (.dll).
Wireshark provides the ability to export artifact files that malware downloaded. So we can export the .dll file using Wireshark onto our system and perform a quick ‘file ’command to get more information about the file.
To observe the Emotet C2 traffic, we narrow down our focus by filtering for traffic that involves HTTP POST requests. The requests shown in the screenshot below contains encoded data or it’s encrypted which is sent by Emotet from victim’s machine to attacker controlled hosts.
The traffic is particularly going to below 2 IP addresses:
- 167[.]71[.]4[.]0 over TCP port 8080
- 5[.]2[.]136[.]90 over TCP port 80
We again follow the TCP stream for one of the POST requests to see what it looks like and if we can get any more additional information about the kind of data that is sent.
The TCP Stream shows us the encrypted Emotet C2 traffic which sent 6KB worth of form-data. It’s unclear as to what kind of data was sent as the traffic is encrypted but this is clear from Content-Type and Content-Length in the above POST request.
The only other thing that I found to be happening every now and then is that there are repeated attempts to connect to 46[.]101[.]230[.]194 through TCP port 443. You can spot this by looking for TCP SYN segments that are retransmissions.
Searching the IP in VT or any other source we can see it’s directly linked to Emotet.
Final Words
There’s still more to Emotet analysis as it can download further malware from various other malware families like Trickbot, Qakbot etc.
Studying Emotet’s behavior, how it spreads, and how it does damage helps us not only stop its current attacks but also prepares us for future ones. This is where tools like Wireshark become indispensable allies. Wireshark allows us to peek into the digital conversations between malware and its command centers, shedding light on the intricate maneuvers hackers employ to infiltrate systems.
With each piece of the puzzle we solve, with every insight gained from Wireshark’s analysis, we get better at stopping malware and hopefully keeping our digital world secure.
Until next time, adios!
