This post is also available in: 日本語 (Japanese)
Malicious spam (malspam) pushing Emotet malware is the most common email-based threat, far surpassing other malware families, with only a few other threats coming close.
In recent weeks, we have seen significantly more Emotet malspam using a technique called “thread hijacking” that utilizes legitimate messages stolen from infected computers’ email clients. This malspam spoofs a legitimate user and impersonates a reply to the stolen email. Thread hijacked malspam is sent to addresses from the original message.
This technique is much more effective than less sophisticated methods, which many people have now learned to spot. The approach is more successful at convincing potential victims to click on an attached file, or to click on a link to download a malicious Word document with macros designed to infect a user with Emotet.
Here, we review a case study of Emotet’s thread hijacking process so we can better recognize and understand this technique.
Palo Alto Networks customers are protected from this threat because our Threat Prevention security subscription detects and prevents these types of Emotet infections. AutoFocus users can track Emotet activity using the Emotet tag.
Case Study Timeline
To illustrate Emotet’s thread hijacking process, our case study focuses on an infection from Sept. 3, 2020. In this example, Emotet hijacks the most recent email in an Outlook inbox from an infected host.
The timeline is:
- 15:35 UTC – Legitimate message received by email client on host.
- 16:31 UTC – Host infected with Emotet.
- 16:34 UTC – Legitimate message collected from infected host is sent through Emotet command and control (C2) traffic.
- 18:22 UTC – Emotet botnet sends spoofed email using legitimate message from the infected host.
This process took one hour and 51 minutes to progress from the infection to the arrival of a thread-hijacked email.
Legitimate Email From the Infected Host
In our example, a vulnerable Windows 10 host used Microsoft Outlook as its email client. Outlook was synchronized to a Microsoft account at email@example.com (we have redacted information from the email addresses for this case study). The most recent message in the infected host’s email client is shown in Figure 2, and we have loaded a redacted copy of the legitimate email to GitHub.
As we see in Figure 2, the most recent email was received at 15:35 UTC, approximately one hour before the host was infected with Emotet. This email is a response from firstname.lastname@example.org to a previous message from email@example.com.
Data Exfiltration Through C2 Traffic
Emotet uses HTTP POST requests over C2 traffic to send data collected from the infected host. This data is encoded or otherwise encrypted before it is sent over HTTP.
Most of these POST requests contain only a small amount of encoded data from the infected host, often much less than 1,000 bytes. These requests contain an extra 4 kB of data for padding and form header data. Figure 3 shows a typical example of Emotet C2 traffic from our case study.
Since the amount of encoded data is so small, it does not contain any email chain data collected from the infected user’s email client. However, at 16:34 UTC, we find 13.9 kB of encoded data sent over Emotet HTTP C2 traffic as shown in Figure 4.
This amount is large enough to contain email chain data collected from the infected Windows host. It is the only significant amount of data sent in HTTP POST requests from the Emotet-infected host before we find the thread-hijacked email at 18:22 UTC.
Spoofed Message From Hijacked Email
At 18:22 UTC, a spoofed email was received by firstname.lastname@example.org, the Yahoo account that had sent the most recent message in correspondence to the infected host. It contains an attached Word document with macros for Emotet. This message is shown in Figure 5, and we have loaded a copy of the spoofed email to GitHub.
The message is a reply to email@example.com that spoofs firstname.lastname@example.org from the infected host.
These thread-hijacked messages either have an attached file, or they have a link to download a malicious Word document with macros designed to infect a vulnerable host with Emotet.
Emotet’s thread-hijacked message from this case study spoofed the name in the sending address line from the infected host. Headers from the spoofed message indicate the actual sender may have been from a botnet host in Brazil, or a Brazil-based host may have been used to relay the message. Botnet hosts from all over the world are used to send these thread-hijacked messages from Emotet infections.
These spoofed messages tend to be the most recent emails from a victim’s email client because those are the most likely to fool someone.
Of note, we cannot always assume the spoofed sending address is from an infected victim. If the original message from an infected victim has multiple recipients, a hijacked email could spoof one of the other recipients.
We’ve stored an example of the legitimate email that was hijacked in this case study.
We’ve also stored an example of the spoofed messages sent from the Emotet botnet.
The pcap of infection traffic from this case study is also available.
This case study shows an example of Emotet thread hijacking so we can better understand how Emotet malware utilizes this technique. Emotet is a very active threat that constantly updates its malware in an attempt to evade detection. This vector of infection can reach a great deal of potential victims.
However, organizations with effective spam filtering that follow best security practices have a much lower risk from this infection vector. Palo Alto Networks customers are further protected from this threat, because our Threat Prevention security subscription detects and prevents these types of Emotet infections. AutoFocus users can track Emotet activity using the Emotet tag.