Tactics of an “Emotet” malware


As techniques used by “Emotet” packers in the spring of 2020, I blogged about using “Function-based encryption” and “Heaven’s Gate.” Articles describe each technique and how to analyze it, but malware uses them in a series of steps. And the other techniques are also used. In this article, I will describe how this specimen goes through the sequence before infection. I think that knowing these will be useful for malware detection, analysis and tool development. There may be a lack of information to avoid being used to implement malware. Please note that point.

Also, Im not good at English(It’s like a kindergarten children). For the sake of simplicity, I will explain using figures.

Target malware hash value:

Malware infection flow

This malware has two steps to execute. The first step modifies the registry to start malware itself , and uses other processes to start a new itself process. And the first process is terminated. The second step is the restarted process. And the process creates a “svchost.exe” process to inject and resume the “Emotet” payload.

The flow in which this specimen is executed and the payload of the malware is executed is as follows.

These flows are shown in the figures below.

Figure 1. First step behavior of this specimen
Figure 2. Second step behavior of this specimen

First step: restart process


The flow of the first step is as shown in Figure 1.

When the process is started, the native code is executed first(1). This code is small enough that it is difficult to identify it as malicious code. Malicious code is encrypted.

Native code decrypts encrypted code and data (2). Make a memory allocation to store the decryption result. This process is done multiple times.

Malicious code expanded in memory is called (3).This code contains the initials processing and the encryption / decryption functions required for “Function-based encryption” technique.

It uses the “Function-based encryption” technique to execute malicious code (4).
See another article on my blog for more details on the technique.

The first step is to modify the registry (5). Run the following command to modify the registry.

C:\Windows\system32\reg.exe add HKEY_CURRENT_USER\Software\Classes\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command /v “DelegateExecute” /t REG_SZ /d “” /f

C:\Windows\system32\reg.exe add HKEY_CURRENT_USER\Software\Classes\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command /t REG_SZ /d “C:\Windows\system32\cmd.exe /c start (path to malware)” /f

In addition, make the same settings with the RegSetValueExW API. (I don’t know why I do it twice.)

As a result, the following registry changes:

Key : HKEY_CURRENT_USER\Software\Classes\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command\DelegateExecute
Value : (blank)

Key : HKEY_CURRENT_USER\Software\Classes\AppX82a6gwre4fdg3bt635tn5ctqjf8msdd2\shell\open\command
Value : C:\Windows\system32\cmd.exe /c start (path to malware)

This is a standard function of Windows, and it is a setting to execute the registered command automatically when “WSReset.exe” is executed.

After setting the registry, execute “WSReset.exe” (6). This is a trigger to launch the malware as another process. And the first step ends with “ExitProcess”. With “Function-based encryption” and first-step behavior, it can be difficult to detect as malware.

Technical points

The biggest technical point of the first step is the restart of the malware itself by executing “WSReset.exe”. It takes advantage of standard Windows OS features.
I think this purpose is sandbox avoidance.
The sandbox traces the behavior of the target specimen. The sandbox may also trace “WSReset.exe” launched by this specimen. However, this technique does not launch the malware’s second step process by the malware’s first step or “WSReset.exe”. Triggered by the starting of “WSReset.exe”, the OS starts the second step process. Indirect process launches can cause sandbox tracing to fail. If it were a simple sandbox, the first step in the malware would appear to be just modifying the registry and running “WSReset.exe”. Also, “WSReset.exe” is an official Microsoft application. Therefore, the sandbox may not be able to detect this behavior as malicious. If the sandbox wants to detect the second step of malware, the sandbox will need to look at the entire OS.

In addition, the “Function-based encryption” technique is used in the first step process. I think the purpose is to prevent them from being detected as malware. Perhaps it is a trick that makes it difficult to understand how to run “WSReset.exe” to restart the malware itself.

Second step: Execution of malicious payload


The flow of the second step is as shown in Figure 2.

From (1) to (4), the behavior is the same as the first step.

In the second step, the process branches in the middle. Launch the 64-bit “svchost.exe” with “Suspended” (5). The malware process is 32-bit, but I changed the Wow64 settings to launch a 64-bit process.

Switch to 64-bit code execution using “Heaven’s Gate” and start 64-bit code execution (6).

See another article on my blog for more details on the technique.

These 64-bit codes also using the “Function-based encryption” technique.

The 64-bit code refers to the decrypted “Emotet” payload in the 32-bit code area and injects it into the memory of “svchost.exe” (7). Also the 64-bit code refers to handles of processes and threads in the 32-bit code area.

Resume “svchost.exe” after the memory injection is finished. As a result, the payload of Emotet in the “svchost.exe” will be performed (8).

Technical points

The biggest technical point of the second step is the execution of 64-bit code using “Heaven’s Gate”.
I think this purpose is to avoid static analysis.
Perhaps, it might sandbox can be avoided. If an analyst or tool analyzes this malware as 32-bit, the 64-bit code will not be able to analyze it correctly. Therefore, static analysis will fail. It will also upset analysts who do not know how “Heave’s Gate” works. The sandbox may not be able to successfully trace 64-bit code execution by “Heaven’s Gate”. The attacker may have used “Heaven’s Gate” as a trick to fail the analysis of the injection technique.


The purpose of the malware tactics in this article is to evade detection and analysis. Each technique is a diverse approach to the weaknesses of detection and analysis techniques. If any one is successful, there is a concern that detection and analysis will fail.

We need to know these techniques for correct detection and analysis. In addition, the knowledge needed to develop better tools. Therefore, I thought it was necessary to analyze “Function-based encryption” and “Heaven’s Gate” correctly. That’s why I blogged about analytical techniques.

What the attacker knows and the defender does not know leads to a great threat. I hope these articles will be useful for detection, analysis and tool development.

Security Analyst in Japan. GIAC GREM (Gold)