Analysis of a Fresh Variant of the Emotet Malware

Emotet is not a new malware family. In fact, it’s been around for several years. We captured a JS file spreading Emotet in 2017, which I then analyzed it and published two research papers on it, Part I and Part II.

Recently, FortiGuard Labs captured a fresh variant of Emotet. This time, it’s embedded in a Microsoft Word document. I did a quick analysis on it, and in this blog I’ll show you how it works on a victim’s machine.

Word Sample with Macro

The original file name of this infected document is PAY09735746167553.doc, and it contains malicious VBA code (Visual Basic for Applications) in a Macro. Figure 1 shows its content when it’s opened in Microsoft Word. The malicious VBA code is executed automatically using its “autoopen”  function once a victim clicks the button “Enable Content”, as shown in Figure 1. After a period of time it generates a ton of PowerShell code and then executes it. This generated PowerShell code downloads the actual Emotet file from several URLs that are dynamically generated, as shown in Figure 2.

Emotet is Relocated to %LocalAppData%

The downloaded file is the Emotet malware. The name it uses is random string, and it is located in the %temp% folder. When it runs, it compares the file path of current process, and if it is not the same as %LocalAppData%\culturesource\culturesource.exe, it moves the original exe file from the %temp% folder to the above folder (it even creates the folder if it doesn’t already exist) and renames it as culturesource.exe. The word “culturesource” is a constant string decrypted from its memory.

Below is the relevant ASM code snippet. It calls API SHFileOperationW to perform the file relocation. It is called in a Timer callback function, which I’ll talk more about later.

Finally, it calls the API CreateProcessW to run the culturesource.exe file and it then exits the current process.

Anti-Analysis Technique

Next, the malware starts a second process of culturesource.exe, which is where holds and will perform Emotet’s major functions. Once the second culturesource.exe is running normally, the first one exits. Emotet then dynamically releases code and data into a number of memory blocks, which then take over the follow-up task for Emotet.

Most of the functions are split into multiple parts. I’ll pick one to show you how it uses this trick. Figure 3 shows that a normal function was split into seven parts, which are all connected using “jmp” instructions, to increase the difficulty of code analysis.

All strings are encrypted, and they are then decrypted before being used during the runtime.

All imported API are also encrypted, and are all also decrypted at the beginning of their execution. Figure 4 shows a code snippet that decrypts a string “user32.dll” from “unk_3031F0”. It calls the API LoadLibraryW to load “user32.dll”, and it then uses the decrypted API information to find the exported APIs in the module “user32.dll”.

Timer Function

Emotet also uses a Windows Timer event to execute its code. In my previous analysis, it used the “WindowProc” function to capture a Timer message to perform malicious activities. It’s a little bit different in this version. Here, it directly uses the timer callback function.

When it calls the API SetTimer, it sets the interval time to 1000. This means that the callback function is called once every 1000 milliseconds. Below is the pseudocode of this callback function.

In case 0, one of its purposes is to relocate the process to the expected position with the file name that I mentioned before. It also collects the computer name, file system, and volume by calling the APIs GetComputerNameW and GetVolumeInformationW. It puts the two data sets together and saves them in a global variable, which is used in the C&C server as the ID for this victim. That ID will then be used in the packets that communicate with the C&C server. Emotet then calculates a CRC32 of its EXE file and saves it in another global variable, which is used when sending the first packet to the C&C server. I’ll talk about that in next section.

Another purpose is to set up a Windows service named “culturesource” for running Emotet at Windows startup, when it can open the “Service Control Manager” successfully (by calling the API OpenSCManagerW). Meanwhile, “culturesource.exe” is moved to the folder “%windir%\system32”. Figure 5 shows a screenshot of the installed service “culturesource”, whose Startup type is “Automatic”.

Case 1 is used to initialize a number of DLL modules and decrypt the exported API functions that Emotet uses, including “urlmon.dll”, “userenv.dll”, “wininet.dll” and so on.

Case 2 is the main branch. It collects data from the victim’s system and sends that data to its C&C server, as well as executes commands from the C&C server.

Communication with C&C server

The malware calls several API functions to collect information. For example, it calls “RtlGetVersion” to obtain the Windows version information, and “GetNativeSystemInfo” to gather system and CPU information. It also picks a DWORD value at offset 0x1D4 of PEB, which is defined as SessionID.

Emotet continues to collect the names of running processes by calling the APIs CreateToolhelp32Snapshot, Process32FirstW, and Process32NextW.  The next step is to put all collected data together into a structure and then encrypt the entire data set. Figure 6 shows that the data has been copied into a structure. The values in red rectangle are flags to indicate what the following data is. The string behind ‘12’ is the computer name, the data behind ‘18’ is the native system information, and the byte after ‘20’ is the SessionID from PEB. The DWORD value next to ‘2D’ is the CRC32 value of Emotet, the string following ‘32’ is the collected process name list, and the value with a blue underscore is the length of the following data, which uses a kind of utf-8 encoding.

As I mentioned in my previous blog, its C&C server can check if there are analysis tools (like wireshark, debuggers, etc.) running on the victim’s machine. If detected, it will not reply with available data.

After the data is encrypted, it is encoded using Base64. Moreover, it then disguises the Base64 code as a Cookies value of an HTTP header. You can see the Base64 code in Figure 7.

In Figure 7, you can also see the C&C server replies back with some data. When the device receives data for the first time from the C&C server, it creates an auto-run entry named “cultruesource” under the sub-key “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” in the system registry. Now it has two ways to start Emotet, i.e. the system service and the auto-run in the system registry. In Figures 8 and 9 you can see more information about adding the auto-run entry to the registry.

By decrypting the received data, I am able to get a PE file, as you can see in Figure 10. From my analysis, I found that the decrypted PE file is another Emotet. It is just used to upgrade itself.

So far, this is my analysis for this new variant. I will continue to monitor this Emotet campaign for additional functions and changes.

[…]

To read the original article:https://www.fortinet.com/blog/threat-research/analysis-of-a-fresh-variant-of-the-emotet-malware.html