Emotet vs Trump – Deep Dive Analysis of a Killer Info-Stealer

ATTACK FLOW

The first stage of the Emotet attack flow starts with an email that has a weaponized Microsoft Office document that contains a malicious VBA macros code. Upon loading this document, an image appears with instructions for the user to enable the macros in order to view the real document.

Enabling the macros is the only user interaction that is be needed to initiate the attack. From that point on, it will be progressing without any interaction.

MITRE ATT&CK detection by - hybrid-analysis

Once the highly obfuscated VBA has been executed, a base 64 encoded command will run through a PowerShell instance in order to download the Emotet payload on the victim’s environment.

The second stage of the Emotet attack chain is to execute a PowerShell.exe instance in order to communicate to the Command and Control and download the Emotet payload.

The PowerShell command will usually have the same pattern of malicious code, although elements within this code will often change. Most of the time the malicious PowerShell command is encoded with Base 64 encoder.

After decoding the base 64 PowerShell script,  we can see that the PowerShell instance attempts to download  the Emotet from different domains. The domains will split in the code below by the  * character. Most of the time those domains are compromised WordPress sites, these sites delivered the Emotet payloads.

Code Breakdown:

• Triple\two-digit payload name – Emotet’s malicious payload will be usually downloaded and invoked for the first time with a three or two-digit number file name. This number is randomly generated throughout the epidemic, although the number itself is already hardcoded into the code.
• Path environment variable – Represented in the PowerShell command as ‘$env:userprofile’ and stringed to the file name variable and the desired extension. The Emotet payload is saved to the User directory folder known as the environment variable as ‘$env:userprofile’ (Three-digit number).exe
• Web Client Object – Defined in the code in order to have infrastructure to download the payload.
• URL array – This command is meant to receive a string of URLs which are connected using a random character, split them by their identifying character, and insert them all into the array. This technique assists the attacker to write shorter code.
• The actual run – After setting up the infrastructure mentioned above, the code will proceed to attempt to download a file using the established web client object and save the payload to the established file location.
• Proceed to check – Check if the downloaded file matches the hardcoded length, or size of the file in bytes. If the size matches, invoke the file and break the loop, thereby exiting the code and finishing the run. If none of this works, the code is set to do absolutely nothing else which is represented by the empty catch brackets.
• We can see that indeed the command attempts to download the file from each of the addresses separately as shown in the command. This is because some domains, used for malicious activity, will usually shutdown quickly in order to avoid any traceback to the attacker, and as such the attacker provides the command multiple domains in order to ensure that at least one works.

The Command and Control downloaded the Emotet payload in a packet format (MPRESS packer). This method made the analysis and the traditional AV(Anti-Virus) detections more difficult, in most cases Emotet binary packet with a two-layer packer.

The above domain related to the following IP address:

By using known packer detection tools, we can see that the Emotet packet payload has a high entropy level which indicates that the meta-data is highly compressed and encrypted.

This is the Emotet packet payload meta-data section view:

The Emotet payload downloaded by the command to the User directory folder.

Attack Flow Process Tree:

The third stage was an instance of Svchost.exe which opened Wmiprvse.exe which in turn launched the Emotet payload that was downloaded from the attacker’s Command and Control, as mentioned above.

Grandparent process:

Parent process:

Child process:

The Emotet payload was executed by wmiprvse.exe and not by PowerShell.exe instance so it can utilize the capabilities of Wmic. In the PowerShell command, the invoke method to execute Emotet payload is with the following command:

• ([wmiclass]’win32_Process’).”cReATe”

The Win32_Process and Win32_ProcessStartup classes represents a process and the create method represents the creation of a new process. This allows the attacker to create a new process, not under the parent process. A new process will be created remotely under the Wmiprvse.exe.

WmiprvSE.exe is a DCOM server, it is spawned under the DCOM service host- svchost.exe which is executed with the following parameters:

• C:\WINDOWS\system32\svchost.exe -k DcomLaunch

The successful run of this PowerShell command results in the continuation of this tree. An instance of Wmiprvse.exe is opened under Svchost.exe and launches  the Emotet payload.

This technique “not my parent” is used to avoid behavioral detections of parent and the child process.

Emotet PowerShell command 2019:

[Diagnostic.Process]::”Start” – “Starts a process resource and associates it with a Process component.”-MSDN

Emotet PowerShell command 2020:

([wmiclass]’win32_Process’).”cReATe”

After Launching a second instance of itself, the binary of the Emotet copies itself to a different location and deletes itself from the Users directory. The new directory path of the Emotet payload:

“C:\Users\*user*\AppData\Local\+ random folder” while simultaneously changing its name, the name of the Emotet payload and the name of the new folder are the same.

The actions are executed by the three digits Emotet payload that is located in the Users directory. This is done in order to better hide the malicious payload in an unsuspecting victim system.

This path (C:\Users\User\AppData\Local\) is known as a suspicious location. The location is often favored by malicious actors, therefore knowing that helps narrow the options of exploration. Malicious executables install themselves to writable areas on a victim’s file system, the most common among them is the user home directory.

Stage four of the Emotet threat is to gain a persistence on the victim environment. Emotet persistence technique is registering the Emotet binary in the Run key in the registry, in order to ensure its run regardless of user interaction.

Additionally, in some cases Emotet can use an LNK file, a scheduled task, or by creating a service.

In this case, the Emotet used the “Microsoft\Windows\CurrentVersion\Run” registry key.

Futhermore, Emotet modifed the following registry in order to config the Internet Explorer.

The persistence and modification of the registry keys used by the advapi32.dll file is a software component of Microsoft Windows, that is designed to support several APIs including registry and security calls.

The API function that was used in order to open a specified registry key:

The enumeration process of the Emotet in order to gather system information, process list the host name etc.

For example, the Emotet used the following Windows API functions:

GetSystemInfo: “Retrieves information about the current system. To retrieve accurate information for an application running on WOW64, call the GetNativeSystemInfo function”-MSDN.

GetTimeZoneInformation: “Retrieves the current time zone settings. These settings control the translations between Coordinated Universal Time (UTC) and local time”-MSDN.

The following is the processes list:

After gaining the persistency and enumerating the compromised host the next stage of Emotet is to connect to a new IP address on port 80.

The malicious IP address stored in the memory process of the Emotet payload.

These addresses belong to the attacker’s Command and Control servers which are used to receive the information regarding the compromised host, the information is a part of the enumeration stage of the Emotet. The Command and Control server receives the data in an interval, continuously.

When following the TCP stream of the file’s conversation with the following IP addresses, it is possible to find and observe the packet sent to the server.

This HTTP body contains the data in base64 encoded format:

This packet consists of encrypted data. This data contains all the collected information from the victim’s system.

In order to deeply investigate the communication with the Command and Control, we unpacked the Emotet payload and searched for the hardcoded malicious IP address of the Command and Control in the unpacked Emotet.

The way to the find the config of the IP address is convert the IP address from decimal to hex in a reverse order and search the hex code of the IP.

After connection has been established to the Command and Control Server and the data has been successfully transferred to the attacker, alongside the fact that the malicious payload has successfully built its persistency, the attacker will be able to distribute further malware onto the infected system. This additional payload can vary to any malicious malware that the attacker is familiar with, the further malware that will dump to the compromised host depends on the information and the type of company.

Emotet unpacking process:

In order to unpack we set a breakpoint on the following Windows APIs “CreateProcessInternalW”,“VirtualAlloc” and on the return of the VirtualAlloc in order to see the calls to this function.

The ‘ret’ (return) of the VirtualAlloc, returns a value to the EAX register and this is the interesting value that the unpacked Emotet stored in the address base of all the unpacked data. In the beginning, the address of the EAX is blank(nothing has been written to the specific return address)

After using ‘run to user code’ option, the EIP register hits on the new address after the call to the VirtualAlloc, and a few values have been pushed to the stack before the call.

The next extraction is to move a buffer to the ESI register, after following the dump of the edi+54 (the buffer)

We can now see the MZ header of the unpacked Emotet. When we follow to the Memory Map, the protection page has ERW protection rights (Execute, Read, Write)

The dump of the unpacked Emotet binary:

The difference between the packed and the unpacked Emotet binary.

Interesting indicator found through static analysis is that the Emotet attacker takes an interest in the United States politics and the CNN news. They set a reference to the CNN update from 6\2\2020 .

The following highlight stings found in the meta-data of the Emotet Payload.

Emotet actions:

• Download and execute other known trojan banker malwares:
  • TrickBot
  • Ryuk
• Steal sensitive information and credentials:
  • Steal network passwords stored on a system
  • Steal email address
• Send phishing campaigns from the compromised host
  • MalDoc or Malicious Links
• Spread laterally across a network with the use of SMB protocol
• Communicate to Command and Control server
  • Data exfiltration of the stolen data

RECOMMENDATIONS

In order to clean up an infected host, it crucial to revert each of the steps taken by the payload of the attack.

• Clean the Registry for any of the manipulated values.
• Delete Malicious Child’s instances from the memory.
• Block Network Traffic to any domain contacted throughout the attack.

INDICATORS OF COMPROMISE

Type	Indicator
Registry Key	HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Payload instance location	C:\Users\*user*\”***.exe”
Payload instance location	C:\Users\*user*\AppData\Local\”*****”