Emotet 2.0: Everything you need to know about the new Variant of the Banking Trojan

Since it was first identified in 2014, the Emotet banking trojan has been a persistent threat that has affected over 1.6 million computers and led to millions of dollars in loss. However, in January 2021 a collaborative effort between law enforcement in several countries, coordinated by Europol and Eurojust, dismantled the operations of Emotet, which was followed by several arrests in Ukraine. 

Despite the disruptions in their operations, within 9 months, in November 2021, new Emotet samples were discovered in the wild. Though the new variant of Emotet is very similar to the previous bot code, it differs in the encryption scheme used for command and control communications. 

In this article, we delve into the technical aspects of the re-emerged Emotet malware dubbed Emotet 2.0. 

Analyzed Samples

Emotet 2.0 has been analyzed based on the following samples:

Documents:

• 349d13ca99ab03869548d75b99e5a1d0
• eb02f3635fbe19caf518a59aceb753ed

PE Images:

• 4b957e4473826a37066f4489f5abbed4

Initial Access

After almost a year-long hiatus, the Emotet malware has returned to the threat landscape through spamming campaigns. Adversaries are using weaponized Microsoft Word document files to spread the infection. 

As shown in the image below, users are tricked into clicking “Enable Content” to execute the malicious Macros that downloads Emotet malware hosted on various WordPress websites compromised by the attackers.

Having extracted the malicious Macros embedded in the document, we found that:

• The Macros are heavily obfuscated to hinder the analysis. 
• After deobfuscation, we observed that the Macros execute the Powershell command on the victim system to fetch the Emotet payload from the attacker’s infrastructure. 
• After analyzing multiple files, we observed that the campaign uses different PE image files, like executable and DLLs (Dynamic-link libraries), to spread the malware.
• While some campaigns leverage DLL files to deploy the malware, others use .exe files to deploy it. 

The images below illustrate the different Powershell payloads from multiple malicious documents:

1. Powershell payload that downloads DLL files

When the payload is DLL, the campaign uses Rundll32 to execute an exported function Control_RunDLL to deploy the Emotet payload.

2. Powershell payload that downloads .exe files:

When the payload is a .exe executable file, the Powershell payload fetches the .exe file from the attacker’s infrastructure and executes on the victim’s system.

Emotet Malware Payload

• The Win32API IsProcessorFeaturePresent is commonly used in malware for anti-debug purposes. 
• The argument value 0xA is passed to the API to check if the SSE2 instruction set is available on the victim system. Here, 0xA represents the constant value:  PF_XMMI64_INSTRUCTIONS_AVAILABLE.
•  Systems that support the SSE2 instruction set can use special registers xmmn, where n can have values from 0 — 7. 
• Later in the process the malware uses xmmn registers to transfer data.

Loading Mechanism

• The DLL/exe file dropped by the malicious document acts as a dropper to deploy the Emotet malware. The analyzed DLL has a PE image hidden inside it as shown in the image below:

• Here, the malware uses the SSE2 instruction set for data transfer, i.e. the xmmn registers transfer hidden payload bytes within the malware. 

The code responsible for transferring hidden payload bytes within the malware

• The malware then allocates memory to dump the hidden Emotet payload using VirtualAlloc Win32 api. 
• The argument 0x40 has a value of PAGE_EXECUTE_READWRITE, which sets the permission of the newly allocated memory to read, write, and execute. 

• The malware copies the hidden PE image into an address starting from 0x10000000. The address of the newly allocated memory can be found in the EAX register, as shown below:

As seen in the image below, the memory permissions for the region 0x10000000 to 0x00028000 have been set to ERW (Execute, Read, Write).

• The malware uses the code seen below, to copy the PE image, segment by segment, into the newly allocated memory with Execute, Read, Write permission. 

• After transfering the byte, the newly allocated memory has a PE image with its MZ header, and the segments are ready to be executed by the malware.

• The malware then transfers control to a hidden payload by calling the memory address 0x100143B3.

• The image below shows the value stored in the Stack, when the above call happens. The execution starts from address 0x100143B3 in the newly allocated memory.

• Subsequently, the Emotet malware is executed. The shellcode is polymorphic in nature as each set of shellcode bytes are encoded by XORing with a key value to evade signature based detection as shown in the image below. The basic functionalities of the shellcode are covered in the System Wide Activity section. 

• Finally the Emotet shellcode exits from the system.

Extracting the Emotet Payload

• The PE image hidden in the loader has a hash value of 9DA12DAF87DFF61804EDF0ECE87E1DA2, which is PE image DLL32 and has no exported functions. 
• The instructions in the DLL are dynamically decoded using XOR to evade detection. 
• There are no hits on VirusTotal for this hash.

System-Wide Activity

• The Emotet malware spawns a new process of Rundll32 with a new command line. This is responsible for maintaining connection with the attacker’s C2 (Command and Control) server. 

• In the new command line shown below, we can see the malware has already been able to write the file in C:\Users\<user>\AppData\Local\<Random_string>\<random>.<random_extension>. We have confirmed that the file written in this extension is the same as the initial file dropped from the malicious document. 

• It is not in the nature of the Rundll32 system program to make network connections. However, because the malware is executed via Rundll32, we can see live traffic from it on the system, when it connects to the attacker’s Infrastructure.

• The persistence mechanism employed by Emotet is a classic technique that utilizes the Run registry key. As mentioned above, a PE image is written to: C:\Users\<user>\AppData\Local\<Random_string>\ directory as <random_string>.<random_extension>. After which, the Rundll32 is abused to run the exported function in the DLL.

Indicators of Compromise (IOCs)

• Author Details

Anandeshwar Unnikrishnan

Threat Intelligence Researcher , CloudSEK

Anandeshwar is a Threat Intelligence Researcher at CloudSEK. He is a strong advocate of offensive cybersecurity. He is fuelled by his passion for cyber threats in a global context. He dedicates much of his time on Try Hack Me/ Hack The Box/ Offensive Security Playground. He believes that “a strong mind starts with a strong body.” When he is not gymming, he finds time to nurture his passion for teaching. He also likes to travel and experience new cultures.

Co Authors

Deepanjli Paulraj

Lead Cyberintelligence Editor, CloudSEK

Total Posts: 3

Deepanjli is CloudSEK’s Lead Technical Content Writer and Editor. She is a pen wielding pedant with an insatiable appetite for books, Sudoku, and epistemology. She works on any and all content at CloudSEK, which includes blogs, reports, product documentation, and everything in between.

×

Anandeshwar Unnikrishnan

Threat Intelligence Researcher , CloudSEK

Anandeshwar is a Threat Intelligence Researcher at CloudSEK. He is a strong advocate of offensive cybersecurity. He is fuelled by his passion for cyber threats in a global context. He dedicates much of his time on Try Hack Me/ Hack The Box/ Offensive Security Playground. He believes that “a strong mind starts with a strong body.” When he is not gymming, he finds time to nurture his passion for teaching. He also likes to travel and experience new cultures.

Latest Posts

• 
• 
• 
•