Overview
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, I’m not good at English(It’s like a kindergarten children). For the sake of simplicity, I will explain using figures.
Target malware hash value:
MD5:545BFDC9B1976AE0003443FF4F90EB7E
SHA1:92E8CE006BB3C4A1DDB8D8BA8DE3A90C0BBB6326
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.
- This specimen runs in 32 bits.
- The MFC-based code is started and the encrypted payload is unpacked.
- It is using a 32-bit hash to hide the Windows API. And it searches the API using a 32-bit hash.
- The code expanded in memory is used “function-based encrypted” technique, which executes malicious code.
- Modify the registry so that it will be executed itself when “WSReset.exe” is executed, and execute “WSReset.exe” to restart itself.
- After restarting, the malware runs another routed program.
Start 64-bit “svchost.exe” in suspended using WOW64 function. - Run 64-bit code using “Heaven’s Gate”.
- The 64-bit code refers to the data prepared by the 32-bit code, injects the code into “svchost.exe”, and resumes.
- The code injected into “svchost.exe” performs a main infection such as registration in the task scheduler.
These flows are shown in the figures below.
First step: restart process
Flow
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.
https://sachiel-archangel.medium.com/malware-function-based-encryption-technique-and-analysis-c83036254486
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
Flow
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.
https://sachiel-archangel.medium.com/analysis-of-heavens-gate-part-1-62cca0ace6f0
https://sachiel-archangel.medium.com/analysis-of-heavens-gate-part-2-3943b347fb18
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.
Consideration
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.
