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.
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.
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.
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.
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:
Traffic from the Trickbot infection:
Traffic from the IcedID infection:
Traffic associated with the AZORult infection:
File hashes for malware retrieved from the infected Windows host follow. SHA256 hash: 34fd8ab80ff403db687517beac2b1d3024f69119e73c054ffe6686b1a0a40489
SHA256 hash: d9352b362629bdcd5d7c830a3ea9c5f55d1e0be4240b5df2867903fb317ee7d3
SHA256 hash: 806bc3a91b86dbc5c367ecc259136f77482266d9fedca009e4e78f7465058d16
SHA256 hash: 2cbb833b3410d0d27719614f3b4ffe8f16d7dd5242a8b85f35619405b110784e
SHA256 hash: 80aa7f6f6b25aaf43e52d5ca6971f5dac45b3b2e0ed5c5f3843080b03771c2cc
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 436 Posts ISC Handler Sep 26th 2018 |
Thread locked Subscribe |
Sep 26th 2018 3 years ago |
Hi Brad, always like to read your post but you always finish these with this:
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 |
Quote |
Sep 26th 2018 3 years ago |
Thanks for the feedback! My background is not in system administration, so I don't have configuration details for SRP or AppLocker. I always set up my lab environments to be vulnerable, so I can get a full chain of infection traffic. I always include that section for diaries about malware infections, because If I don't, someone will inevitably post a comment that these types of infections are easily preventable through such methods.
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: - bleepingcomputer.com/tutorials/create-an-application-whitelist-policy-in-windows/ - mechbgon.com/srp/ AppLocker: - techgenix.com/applocker-guide/ - blog.windowsserversecurity.com/2011/06/18/step-by-step-guide-on-configuring-applocker-in-the-domain/ |
Brad 436 Posts ISC Handler |
Quote |
Sep 26th 2018 3 years ago |
I just wanted to make two quick comments [hmm; well maybe not so quick]. As usual, I found Brad Duncan's diary very informative. And second, I just wanted to say -- and this has NOTHING to do with the diary's technical content -- how frustrating it is to read over and over again (in multiple diaries) about "properly-administered and up-to-date Windows hosts." First of all, as others have pointed out, there's always something. And there are always those looking to exploit the somethings. So even "properly-administered and up-to-date Windows hosts" are likely vulnerable to who-knows-what. (As has been pointed out, just look at the monthly updates -- and not just for the Windows OS.) But MORE IMPORTANTLY FOR ME is the simple concept: Windows is ill-defined. They keep changing it! I hated Windows 8. I hear they "improved" (made it look more like old Windows) in 8.1. Windows 10 is an abomination. I cannot even set a theme that is reminiscent of the old Windows. I lost one PC to the auto-upgrade, but no others. My "main computer" continues to be Windows Vista because IT DOES WHAT I WANT. The first thing Windows 10 did was hook me to the Internet and download information for Washington, DC's weather (I'm a couple thousand miles from there). And who knows what it shared. Microsoft stopped supporting Windows Vista, but since they don't sell a GUI replacement that works like the OS I know, I don't want it. While I practice "relatively safe computing," I am still probably vulnerable to who-knows-what. And what about browsers stopping support for still-supported Windows versions? After I switched to Google Chrome, they stopped supporting Windows Vista BEFORE Microsoft stopped supporting it. The old version of Chrome is still running OK (mostly) on Windows Vista. My "file server" runs Windows XP, and I am NOT changing it. All my other computers (other than the basically dead and useless Windows 10 PC) run different flavors of Windows 7. And basically things continue to work. My next "main computer" will likely run Windows 7 Professional. And I am sure I am not alone here. Others have complained about incomprehensible Google Chrome changes (e.g., spacing of icons in the Bookmarks bar). And there are various "GUI overlays" that make Windows look more like old Windows. (I use them.) There is even an add-on that restores the traditional menu system in Microsoft Office.
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? |
robv 23 Posts |
Quote |
Sep 26th 2018 3 years ago |
Thanks for the commentary! This viewpoint is something I should also include in my final words. The reason we keep seeing this sort of attack is precisely the reasons you state. Otherwise, it wouldn't be profitable for the criminals producing this malspam. My original intent was to show we are not completely helpless against these attacks, and there are ways to combat these threats. However, my current phrasing downplays the multitude of people who still use Windows 7 or earlier versions for a variety of reasons. I'll be revising my final words to indicate a significant target base is still vulnerable due to many of the reasons you've stated.
|
Brad 436 Posts ISC Handler |
Quote |
Sep 26th 2018 3 years ago |
The NSA has a good writeup on AppLocker.
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. |
Luke 2 Posts |
Quote |
Sep 26th 2018 3 years ago |
For those worried that blocking macros will have a negative impact might consider blocking macros in documents downloaded from the Internet. Office 2013 and 2016 have this option.
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 |
Quote |
Sep 27th 2018 3 years ago |
ROBV:
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. |
PaulOutBox 7 Posts |
Quote |
Sep 27th 2018 3 years ago |
For those looking to simplify Applocker deployment, you might wish to take a look at this blog post from Aaron Margosis:
https://blogs.msdn.microsoft.com/aaron_margosis/2018/06/26/announcing-application-whitelisting-with-aaronlocker/ |
Kurt 5 Posts |
Quote |
Sep 28th 2018 3 years ago |
Quoting PaulOutBox:ROBV: i'm using this and its look like same to same win 7, so its totally ui friendly. |
Daniel42 2 Posts |
Quote |
Sep 28th 2018 3 years ago |
Sign Up for Free or Log In to start participating in the conversation!