One Emotet infection leads to three follow-up malware infections
Introduction
During 2018, Emotet has been a continual presence in the malicious spam (malspam) landscape. With few exceptions, malspam from this campaign is active every weekday. As the months progress, I've generally found follow-up malware from Emotet infections in my lab. I wrote about one such malware team-up back in July 2018, and Symantec has published an in-depth look at Emotet's evolution from banking Trojan to a delivery service for other threat actors.
In recent weeks, I've generally seen Emotet retrieve Trickbot, the IcedID banking Trojan, or spambot malware for its follow-up infection. I rarely see Emotet retrieve more than one type of follow-up malware. But on Tuesday 2018-09-25, my infected lab host retrieved Trickbot and IcedID immediately after an Emotet infection. Then IcedID caused another infection with AZORult on the same host.
Shown above: Flow chart for the infection.
Emotet malspam
I currently find three types of Emotet malspam. The first type has an attached Microsoft Word document with a macro. The macro is designed to infected a vulnerable Windows host with Emotet.
The second type of Emotet malspam has a link to download the malicious Word document instead of an attachment.
The third type of Emotet malspam has a PDF attachment without any links in the message. The PDF file contains a link to download the malicious Word document.
All three cases involve a malicious Word document with macros. In all three cases, opening the Word document and enabling macros will kick off the infection process on a vulnerable Windows host.
Shown above: Three different types of malspam for Emotet infections.
Shown above: Example of Emotet malspam with a PDF attachment.
Shown above: Downloading an Emotet Word document and enabling macros.
Infection traffic
I kicked off an infection with a URL that retrieved an Emotet Word doc. This could've come from an email link, or it could've come from a PDF attachment. There's no way tell based on the URL alone.
Shortly after my lab host was infected with Emotet, I saw indictors of a Trickbot infection. I also saw indicators of an IcedID infection. Finally, I saw an HTTP request that returned an AZORult malware binary, and it was followed by AZORult post-infection traffic. See the image below for details.
Shown above: Traffic from the infection filtered in Wireshark.
The Emotet infection was kept persistent on my infected lab host through the Windows registry. IcedID and Trickbot were kept persistent through a scheduled task. After the AZORult executable ran on my infected lab host, it deleted itself, and I didn't find any method of persistence for AZORult.
Shown above: Emotet persistent on my infected Windows host.
Shown above: IcedID persistent on my infected Windows host.
Shown above: Trickbot persistent on my infected Windows host.
Indicators
The following are indicators (IP addresses, domain names, and file hashes) associated with the infection of my Windows lab host.
Traffic from the Emotet infection:
- 5.101.138.188 port 80 - sloegincottage.co.uk - GET /tyoinvur/En_us/Clients/092018/
- 108.167.161.63 port 80 - louisianaplating.com - GET /18Ge0wDF
- 88.208.252.82 port 80 - stonehouse.me.uk - GET /AlvUfSm
- 88.208.252.82 port 80 - stonehouse.me.uk - GET /AlvUfSm/
- 190.147.53.140 port 8090 - 190.147.53.140:8090 - GET /
- 201.111.8.75 port 50000 - Attempted TCP connections, but no response from the server
- 31.167.248.50 port 443 - 31.167.248.50:443 - GET /whoami.php
- 31.167.248.50 port 443 - 31.167.248.50:443 - POST /
Traffic from the Trickbot infection:
- port 80 - icanhazip.com - GET / (IP address check by the infected host, not inherently malicious)
- 170.81.32.66 port 449 - SSL/TLS traffic caused by Trickbot
- 195.123.210.156 port 447 - SSL/TLS traffic caused by Trickbot
- 138.34.45.133 port 8082 - 138.34.45.133:8082 - POST /arz1/[long string with host info]/90
Traffic from the IcedID infection:
- 93.189.41.44 port 443 - calgama.com - HTTPS/SSL/TLS traffic caused by IcedID
- 185.154.21.160 port 80 - segregory.website - GET /data2.php?B41857926E193158
Traffic associated with the AZORult infection:
- 108.167.137.17 port 80 - www.pruebas.litcel.com - GET /crypt_AU3_EXE.exe (caused by IcedID)
- 107.182.230.25 port 80 - 107.182.230.25 - POST /index.php
File hashes for malware retrieved from the infected Windows host follow.
SHA256 hash: 34fd8ab80ff403db687517beac2b1d3024f69119e73c054ffe6686b1a0a40489
- File size: 211,584 bytes
- File description: Downloaded Word doc with macro for Emotet
SHA256 hash: d9352b362629bdcd5d7c830a3ea9c5f55d1e0be4240b5df2867903fb317ee7d3
- File size: 219,648 bytes
- File description: Emotet malware executable
- File location: C:\Users\[username]\AppData\Local\Microsoft\Windows\[various file names].exe
SHA256 hash: 806bc3a91b86dbc5c367ecc259136f77482266d9fedca009e4e78f7465058d16
- File size: 519,149 bytes
- File description: Trickbot caused by Emotet infection (gtag: arz1)
- File location: C:\Users\[username]\AppData\AIMT\[string of characters].exe
SHA256 hash: 2cbb833b3410d0d27719614f3b4ffe8f16d7dd5242a8b85f35619405b110784e
- File size: 392,192 bytes
- File description: IcedID caused by Emotet infection
- File location: C:\ProgramData\{12345678-1234-1234-1234-12345689ABC}\[string of characters].exe -- various hex digits between the { }
SHA256 hash: 80aa7f6f6b25aaf43e52d5ca6971f5dac45b3b2e0ed5c5f3843080b03771c2cc
- File size: 536,576 bytes
- File description: AZORult caused by IcedID infection
- File location: C:\Users\[username]\AppData\Local\[string of characters].exe
- File location: hxxp://www.pruebas.litcel.com/crypt_AU3_EXE.exe
Final words
Most enterprise spam filters are quite good at blocking malspam pushing Emotet. From what I can tell, online email services like Gmail and Yahoo also seem to keep these messages from your inbox. But it only takes one message to make it through, and it only takes one person to click their way through any warnings to successfully infect a vulnerable Windows host.
However, properly-administered and up-to-date Windows hosts are not likely to get infected. Windows warns potential victims if such Word documents are downloaded from the Internet, and recent versions of Microsoft Office have a Protected View feature that should prevent people from accidentally enabling these macros. Furthermore, system administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.
Email examples, pcap, and malware associated with today's diary can be found here.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
Comments
System administrators and the technically inclined can also implement best practices like Microsoft’s Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.
Could you reference us with some details configuration to accomplish this and implement such best practice in our environment to better prevent these type of attacks too common these days?
Anonymous
Sep 26th 2018
6 years ago
So, unfortunately, I don't have any thing ready that can help. I hope some other readers can post comments with the details you're looking for. In the meanwhile, I've included links to some guides for setting up SRP and AppLocker below. I'll also look into updating the wording or links in that section, so it can better help people. Thanks again for the feedback!
SRP:
- https://www.bleepingcomputer.com/tutorials/create-an-application-whitelist-policy-in-windows/
- http://www.mechbgon.com/srp/
AppLocker:
- http://techgenix.com/applocker-guide/
- http://blog.windowsserversecurity.com/2011/06/18/step-by-step-guide-on-configuring-applocker-in-the-domain/
Anonymous
Sep 26th 2018
6 years ago
To the editor: I will understand if you don't publish this. But let's get real. Some people are on -- and will continue to be on as long as possible -- old versions of S/W because new versions, in a word, suck. Hmm. Makes me wonder -- is forcing S/W levels a legislative priority? Don't get me started. Hmm. If there is only one ISP supporting a location, does it -- should it -- have the right to block port 25?
Anonymous
Sep 26th 2018
6 years ago
Anonymous
Sep 26th 2018
6 years ago
https://www.iad.gov/iad/library/ia-guidance/tech-briefs/application-whitelisting-using-microsoft-applocker.cfm
They also have a best practices document for application whitelisting I suggest.
https://www.iad.gov/iad/library/ias/adversary-mitigations/application-whitelisting-best-practices.cfm
Remember you will need alerts if files get blocked. During audit mode with applocker, it's one eventID for 'would have blocked' and when setup for blocking it's another EventID. Deny by default, that's why they call it whitelisting. Also, don't let someone talk you out of whitelisting with a Panacea Fallacy; i.e. because it doesn't protect against all attacks, we shouldn't do it.
Anonymous
Sep 26th 2018
6 years ago
This will mitigate these types of threats while a more thorough review can be performed to determine which users can be blocked from using macros altogether.
Source: https://cloudblogs.microsoft.com/microsoftsecure/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/
Anonymous
Sep 27th 2018
6 years ago
I kept using Vista for TurboTax until it finally stopped working.
I would recommend a BSD/Linux Distro to help with your older PC's. Depending on which one you choose the support may last many years. I'm pretty sure that have Desktop Overlays that looks just like XP/Win7.
Anonymous
Sep 27th 2018
6 years ago
https://blogs.msdn.microsoft.com/aaron_margosis/2018/06/26/announcing-application-whitelisting-with-aaronlocker/
Anonymous
Sep 28th 2018
6 years ago
I kept using Vista for TurboTax until it finally stopped working.
I would recommend a BSD/Linux Distro to help with your older PC's. Depending on which one you choose the support may last many years. I'm pretty sure that have Desktop Overlays that looks just like XP/Win7.[/quote]
i'm using this and its look like same to same win 7, so its totally ui friendly.
Anonymous
Sep 28th 2018
6 years ago