SANS ISC: One Emotet infection leads to three follow-up malware infections - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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

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?

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/

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?

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.

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.

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/

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.

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/

Quoting PaulOutBox: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.

i'm using this and its look like same to same win 7, so its totally ui friendly.