Actually, I was thinking publish to article about Project Injection techniques but it took a little longer than I expected. My article will about Emotet malware.
Before the start unpacking, it will be better to get some information about malware.
As the above PEstudio output shows, the malware is introducing itself to users as a Windows Disk Diagnostic User Reseolver. When we look at the other outputs, performs a fraudulent certificate - name is
OCOEZIHQ- installation that was created on 12/03/2019. It is also designed to work on x86 architecture built processors.
As the above
Detect It Easy output shows, we can see that it is written by C/C++ language but does not detect any packer.
When we look at the import section of the PE Bear output, based on IAT information, we can see that there are several different Window DLL is loading; ; kernel32.dll, user32.dll, gdi32.dll, advapi32.dll, shell32.dll and shlwapi.dll.
We can also take a look at our malicious file on IDA Pro before proceeding with unpacking. Especially in the process of the unpacking process to make our easier in advance.
We notice that a small portion of the imported functions may appear in the previous PEBear output. One of them is
VirtualAlloc, which points to a possible custom packer.
Another conspicuous detail, we notice that there are calls to data segments.
Before the dynamic analysis, let’s first look at the behavioral analysis of malware. When first time the run the file, the malware runs itself first.
It then creates second exe file named
AppData\\Local\\mapituip. We then notice that the first file terminates the function and second copied file continues to run.
Dynamic analysis - Unpacking
We are going to open malicious file with x64Dbg and start unpacking process. When throw the malware into Debugger, we are going to create Breakpoint on Create Process Internal. Because when we do behavioral analysis, we found that the file we run creates a subprocess. So we expect that that’s probably the whole state for PE file.
So it is actually going to be unpacked in memory, we will pop over to symbols kernel32.dll and look for Create Process Internal W then put breakpoint here.
After the run operations, we need to reach the breakpoint we put in Create Process Internals W. When we get here, so we understand that somewhere in memory there is an unpacked version of this PE file. So then we are going to pop over to our memory map and we start looking protected sections.
When we look at the Memory Map section above, we can see 4 memory zones set with ERW (Execute-Read-Write) flags. 3/4 are PE files, based on the header. We can proceed with the second phase of analysis.
Dynamic Analiz - Dumped binaries
Actually I exported dump all files to check with IDA pro. I tried all dump file step by step but there was some error for 3 dump files. It was worked only one of them without any error.
As the above IDA Pro output shows, the execution starts with 3 function calls. When look at
Sub_40DF80, it contains the encrypted versions of the APIs to be loaded dynamically.
When look at the details of these two functions; when the encrypted values are loaded into the stack, we notice that it calls another function called sub_401550. This function is probably responsible for the decryption function.
When we try this file again with debugger, we can check whether it is MUTEXT or not. As you can see in the picture above, the name of
Once MUTEX created, malware looks for
Windows Directory to copy itself there. As well as it also looks the
%APPDATA% folder to copying. The new Binary here (under the %APPDATA%) is named under a different name and left here. The second file name in my analysis is called
Obviously, I have not done any work with IP addresses, domains and hosts.
In this analysis, I performed the analysis of the exe file directly. So I want to state that I have not done anything about macro analysis.
If there is a any mistake or any wrong information, just let me know.