Deep Analysis of New Emotet Variant
Credit to Author: Xiaopeng Zhang| Date: Wed, 03 May 2017 10:50:33 -0700
Background
Last week, FortiGuard Labs captured a JS file that functions as a malware downloader to spread a new variant of the Emotet Trojan. Its original file name is Invoice__779__Apr___25___2017___lang___gb___GB779.js. A JS file, as you may be aware, is a JavaScript file that can be executed by a Window Script Host (wscript.exe) simply by double-clicking on it. In this blog we will analyze how this new malware works by walking through it step by step in chronological order.
A JS file used to spread malware
The original JS code is obfuscated, and therefore hard to understand. Based on my analysis, its task is to generate a new JS code into an array and execute it. The new code is easier to understand, as you can see in the code snippet in Figure 1. As I mentioned, it’s a downloader tool that tries to download malware from five URLs onto the affected device. Once one download is finished, the malware is saved to the system temporary folder as “random name.exe” and executed.
Figure 1. Snippet of the generated JS code
Running the downloaded exe file
While the downloaded exe file is executed, it moves itself to “%LocalAppData%random namerandom name.exe” . A random name for the file is generated using local file names. You can treat it as any random name, however, in my environment, the name is “LatnParams.exe”.
To protect itself, once LatnParams.exe is executed it extracts code from itself, inserts it into a newly-created LatnParams.exe by calling the CreateProcessW function with a CREATE_SUSPENDED flag, and then restores the second process to run. Once that is complete, the first process exits. Later, the LatnParams.exe’s lnk file is created inside the Startup folder in the system Start Menu so it can automatically run whenever the system starts. See Figure 2.
Figure 2. Malware in Startup folder
The main function of the second process
Next, we’ll look to see how the code works inside the second process that is created. There is a hidden window created for the second process. Its WindowProc function is to handle all windows messages for the window. This malware uses a WM_TIMER message to initiate it. Calling the SetTimer function can generate such a message.
Once this window is created, a WM_CREATE message is sent to the WindowProc function, where it calls the SetTimer function to keep the system posting WM_TIMER messages every 200ms and then callback the window’s WindowProc function.
Figure 3. Call SetTimer Function
Next, we will examine this WindowProc function. Figure 4 is the structure of this function in pseudo code.
Figure 4. WindowProc Function
Case 6 Code Branch
In the case 6 code branch, the malware collects system information from the affected device, including computer name, country name, the names of all running programs, and content about whether or not MS Office Outlook is installed. It then puts all the collected data together into a memory buffer and encrypts it. Figure 5 shows the data ready for encryption.
Figure 5. Collected data from the victim’s system
As you can see, the first part is the computer name. Following “16 00 01 00” is the CPU information. The next part is the running process names, followed by the string “Microsoft Outlook,” which means that MS Office Outlook is installed on this machine. You may also notice that the debugger name “OllyDBG.exe” is also in the process name list. Through my analysis I found that the C&C server checks the process names. If it learns that a debugging-related tool (such as OllyDbg, WinDbg, IDA Pro, etc.) is being running on the victim’s machine, a different response is returned. In this case, it replies with a new version of itself, causing itself to upgrade again and again until those tools exit.
After encryption, it copies the encrypted data, the encryption key, and the hash value together into a new buffer. It then sets the next case number to 7 and exits the case 6 branch.
Case 7 Code Branch
In the case 7 code branch the main function is to connect to the C&C server and send collected data to the server. It also receives data from the C&C server. We’ll take a look at how it works here.
The C&C server’s IP and port are hard-coded. In this version there are eleven, as shown below:
004175D0 ; DATA XREF: WindowProc+257r004175D0 ;sub_403AE0+Co004175D0 dd 0D453A62Dh ;212.83.166.45004175D4 dd 1F90h ;8080004175D8 dd 0ADE68843h ;173.230.136.67004175DC dd 1BBh ;443004175E0 dd 0ADE0DA19h ;173.224.218.25004175E4 dd 1BBh ;443004175E8 dd 68E38922h ;104.227.137.34004175EC dd 1BA8h ;7080004175F0 dd 894AFE40h ;137.74.254.64004175F4 dd 1F90h ;8080004175F8 dd 0BCA5DCD6h ;188.165.220.214004175FC dd 1F90h ;808000417600 dd 558FDDB4h ;85.143.221.18000417604 dd 1BA8h ;708000417608 dd 77521BF6h ;119.82.27.2460041760C dd 1F90h ;808000417610 dd 0C258F607h ;194.88.246.700417614 dd 1F90h ;808000417618 dd 0CED6DC4Fh ;206.214.220.790041761C dd 1F90h ;808000417620 dd 68EC02FDh ;104.236.2.25300417624 dd 1BBh ;443
It gets the data generated in the case 6 branch and encodes it using base64. It then sends the base64-encoded data as a Cookie value to the C&C server. Figure 6 shows the data in Wireshark.
Figure 6. Send collected system information to C&C server
In Figure 6, the status of the response from C&C server is “404 Not Found.” This message is used is to confuse analysts. The body, however, is the encrypted data. After receiving all data from the server, it sets the next case number to 8 and exits this branch.
Case 8 Code Branch
The only thing done in the case 8 branch is decrypt the data received in case 7. It then exits this branch and sets the next case number to 9.
Case 9 Code Branch
The case 9 branch is used to process the data decrypted in case 8. Figure 7 is a part of the pseudo code of case 9.
Figure 7. Pseudo code of case 9
There are some sub-cases in the case 9 branch. The case number “v8” comes from decrypted data. Following are two examples of the decrypted data.
In Figure 8, “08 01” is about a sub-case. “08” is a kind of flag or C&C command, and “01” refers to sub-case number 1. As you may know, the following data is an .exe file. In the sub-case 1 branch, this file is executed to upgrade the Emotet malware. Usually, it receives an upgrade command because the C&C server has detected that there is debugging-related tool in the running program names. It’s a way to both protect itself against debugging and confuse analysts. In sub-case 1 branch, it saves the .exe file into a system temporary folder and runs it by calling the ShellExecuteW function. Meanwhile, the parent process exits to finish the upgrade.
Figure 8. Sub-case 1 example
Figure 9. Sub-case 4 example
I manually modified the “OllyDBG.exe” to another program name before encryption (refer back to Figure 5). Then I was able to get the response shown in Figure 9. The flag changes to “08 04”, where “04” means sub-case number 4. In my analysis, it contains 3 modules (.dll files) in the decrypted data. The flags for all of them are “08 04”. Which means the modules are all processed in the sub-case 4 branch. As you can see in Figure 7, the sub-case 4 calls the CreateThread function to create threads and run the modules in the ThreadFunction, with one thread for one module.
So far, we have only finished the analysis of one of the three Emotet modules. We are still working on analyzing the others, and will share that analysis in another blog.
So next, let’s take a look at what this module is able to do.
The module loaded in a thread
Based on my analysis, this module steals credential information from a victim’s machine. It then encrypts that stolen data and sends it to the C&C server.
When this module is loaded in the ThreadFunction, it inserts the code extracted from itself into a newly-created LathParams.exe process to run. The newly-created process has a command line parameter like “%temp%A98b.tmp”. This is a temporary file used to save the stolen credential information.
It is able to steal credentials for Google accounts, FTP accounts saved in IE, Google Talk, Office Outlook, IncrediMail, Group Mail, MSN Messenger, Mozilla Thunderbird, and many others. The following screenshot shows some of them.
Figure 10. Targeted email-related credentials
For testing purposes, I added a test account into MS Office Outlook to see how it works. The account profile is shown here in Figure 11:
Figure 11. Test account added into Outlook
The stolen credential data is saved in the temporary file specified in the command line parameter, where it will be encrypted and sent to the C&C server in the ThreadFunction. In the following several figures you can see the stolen credential information in the temporary file, the data in memory before encryption, and the data sent to the C&C server.
Figure 12. Stolen credential
Figure 13. Before encryption
Figure 14. Data sent to the C&C server
Solution
The original JS file has been detected as JS/Nemucod.F436!tr and the downloaded Emotet exe has been detected as W32/GenKryptik.ADJR!tr by the FortiGuard Antivirus service.
IoC
URL:
"hxxp://willemberg.co.za/TwnZ36149pKUsr/"
"hxxp://meanconsulting.com/K44975X/"
"hxxp://microtecno.com/i17281nfryG/"
"hxxp://thefake.com/Y96158yeXR/"
"hxxp://cdoprojectgraduation.com/eaSz15612O/"
Sample SHA256:
Invoice__779__Apr___25___2017___lang___gb___GB779.js
B392E93A5753601DB564E6F2DC6A945AAC3861BC31E2C1E5E7F3CD4E5BB150A4
https://blog.fortinet.com/feed