Introduction On Friday 2020-10-30, I generated an Emotet infection in my lab and saw Qakbot as the follow-up malware. I let the activity run for a while, then another Emotet infection appeared on the same host after Qakbot started. This appears to be an Emotet to Qakbot to another Emotet infection, with all three infections persistent on my infected lab host.
Today's diary reviews this Emotet to Qakbot to more Emotet infection from last week. The malspam The malicious spam (malspam) was a Halloween-themed message sent on Thursday 2020-10-29 to one of my honeypot email accounts. It had a Word doc attached to the message. The Word doc has a malicious macro designed to infect a vulnerable Windows host with Emotet.
The attached Word document uses a template that's typical for recent Word docs pushing Emotet.
Infection traffic The traffic didn't look much different than what I've seen before for Emotet to Qakbot infections, there just seemed to be more Emotet traffic than normal after the Qakbot traffic kicked in. That didn't seem too unusual, though.
In the above image, Emotet traffic is more frequent than I usually see. Usually, Emotet will call back every 15 minutes, unless the host has been turned into a spambot. Emotet spambot activity includes more frequent C2 callback traffic, but we would also see indicators of spambot traffic, and that's not the case here. Forensics on an infected Windows host When I checked the registry, I saw two entries for Emotet. When Emotet updates itself, it will replace an already existing binary. I'd never personally seen two separate Emotet binaries active and set up in the registry like this.
Of note, Emotet backdates the persistent EXE files 8 days before the current date. So the modified date on both of these Emotet EXE files is 2020-10-22, but the timestamp is the correct time for 2020-10-30. Based on the timestamps for these binaries, it appears that Qakbot caused the second Emotet infection. Indicators of Compromise (IOCs) SHA256 hash: ed51269c3602786ff6ddef3a808d8178d26e4e5960f4ac7af765e4bd642128dd
SHA256 hash: a4c780c8b6ecb7d73f7498a4a46286cf2a2ecc6f378e2ba89deea06591c3cc04
SHA256 hash: dcda70b5cc63629dd2760dbc76ffda0bedefd0ee92af4d4e3740acc7dd2eaff2
SHA256 hash: 4180c4c11e631a7545d40dadb74280c00f53271a75b113c387bb87adaf2cecf7
SHA256 hash: 4d1eeb527a61391ddcf30b0f9d6d9f96369e0179c1e1a65da5da33a196a991d4
HTTPS traffic caused by Word macro to retrieve initial Emotet EXE:
HTTP traffic caused by the two Emotet infections:
Traffic caused by Qakbot:
Caused by Qakbot and Emotet:
Final words In order to become infected, a victim must open the Word document and enable macros. In most cases, people would see a warning against enabling macros. Just opening the Word document by itself should not kick off the infection chain, unless the computer was set up to have macros automatically enabled. Although Emotet pushes other families of malware like Qakbot, this is the first time I've seen indications that Qakbot has pushed Emotet. A zip archive containing a pcap from today's infection is available here. The Word doc and EXE files from the IOCs have been submitted to MalwareBazaar Database. --- |
Brad 436 Posts ISC Handler Nov 3rd 2020 |
Thread locked Subscribe |
Nov 3rd 2020 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!