I published a diary on malicious spam (malspam) pushing Emotet back in June 2017 (link). Since then, I continue to catch the occasional sample, and this malspam appears to occur on a near-daily basis.
Emotet is generally known as a banking Trojan, and TrendLabs published a good write-up earlier this month on some recent samples.
Emotet is not exactly big news, nor is it a new threat. Instead, it's another ongoing presence in our current cyber threat landscape. Emotet malspam bears some discussion, because it's a continuing concern. Therefore, today's diary examines recent malspam pushing Emotet on Wednesday 2017-11-29.
Malspam pushing Emotet occurred throughout the day on Wednesday 2017-11-29. As usual, these were invoice-themed emails. They came from different mail servers, each had different sending addresses, and the URLs occasionally changed. I collected 30 emails and saw 19 different URLs to download a fake invoice for the malware.
Clicking on the links in these emails returned a Word document disguised as an invoice. These documents had malicious macros designed to infect a victim's host with Emotet malware.
I generated two infections from this malspam. The first was at 19:34 UTC, and the second was at 22:22 UTC. In both infections, I saw an HTTP GET request for the initial Word document, followed by another HTTP GET request after enabling the Word macros to retrieve the Emotet binary.
During the second infection, the original URL to retrieve the Emotet binary had been taken off-line, so additional HTTP GET requests were seen.
After the Windows host was infected, I saw HTTP POST requests on a non-standard port. This was post-infection callback traffic from the infected Windows host. During the first infection, this post-infection callback traffic used TCP port 7080. During the second infection almost three hours later, I saw HTTP POST requests over TCP port 443.
Forensics on an infected Windows host
On a Windows 10 host, I had to disable Windows Defender. If not, the downloaded Word document was quickly detected as a severe threat. After I disabled Windows Defender, macros from the Word document retrieved an Emotet binary. However, my Windows 10 host didn't generate any post-infection traffic. I had to infect a Windows 7 host to get a full infection chain.
The following are indicators of this campaign. Many of the domains represent legitimate websites that have been compromised, and they have been used to host malware for this campaign.
Links from the emails to download the Word document:
Traffic generated by the Word macros to download the Emotet binary:
Post-infection traffic generated by the Emotet malware:
Malspam pushing Emotet is easily caught by any decent spam filter, and the associated malware is easily caught by any decent anti-virus. Windows 10 hosts seem well-protected against this threat. I had to set up a vulnerable Windows 7 host to get a full infection chain.
This malspam campaign cannot be very effective, yet it occurs practically every day. That's a testament to how cheap and easy it is to establish these campaigns. The Internet contains an endless supply of poorly-configured servers ripe for compromise by criminals looking to spam victims with malware. There's obvious a return on this type of investment, because we continue to see such malspam.
As always, on versions of Windows prior to Windows 10, system administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.
Emails, pcaps, and malware samples for today's diary can be found here.
Nov 30th 2017
3 months ago