EMOTET banking trojan is still active： shellcode release methods, infrastructure updates, and traffic encryption

Since the EMOTET banking trojan was discovered in 2014, it has been active until now and has become one of the most influential malicious software families. This trojan often spreads through spam emails and has iterated many versions. In the early days, it was delivered through malicious JavaScript scripts, and later turned to spreading through documents containing malicious macro code. We disclosed it last September, and as of now, the infrastructure of this trojan is still being updated.

Program entry analysis

This malicious sample belongs to the MFC class program, and the entry of the main function of the program is as follows:

Through static and dynamic debugging analysis, it is not possible to locate the core functional function from the entire execution flow of the main function.

By examining strings, the import functions used by the program, and dynamic debugging, the following function is the main entry function of the functional module.

It uses Windows resource operation-related functions to find the resource section, then imports resources, and decrypts related data.

The following is related data in the resource section of the program:

The program jumps to the shellcode section to execute, and then performs multiple decryption operations, using the VirtualProtectEx function to modify the properties of the memory page where the next execution code is located, changing it to readable and executable.

Then, it switches to the corresponding entry to execute the main malicious function.

Virus 'self-deletion'

The virus file is moved to the system directory (and the original file is deleted) by using the SHFileOperationW function.

Then, related files ending with Zone.Identifier are deleted. Zone.Identifier type files are other附属 information stream files of the target file, which may include information such as where the target file comes from, such as local, shared, and network.

Then, a new process is created to run.

Virus persistence

Persistence is achieved by creating a Windows service.

Persistence is achieved by creating an auto-start registry entry.

Infrastructure Analysis

C2Basic Information Analysis

 The specific information of the requested IP and port is as follows:

Communication Process Analysis

Obtain the IP address to be remotely accessed.

Parameters required to create an HTTP request message. Strings are randomly generated using the RtlRandom function.

Since the file upload method using the post form needs to be used for data upload, the boundary-related fields are required.

The InternetOpen function is called to initialize the network request.

By calling the InternetConnectW function, we can connect to the remote server, and we can see the specific request port from the parameters.

Then, the request is made through the POST method.

Finally, the related request body is sent through the HttpSendRequestW function. The request body is uploaded through the form upload method, with the content type of multipart/form-data.

Content Analysis Submission

The content uploaded by the malicious sample to the remote server includes encrypted keys, computer names, and currently running processes, etc. These data are encrypted during transmission.

After obtaining the computer name, system directory, and drive information, etc., then concatenate.

The assembled string at the end is as follows:

Obtain the list of running processes on the computer.

As follows is the content to be encrypted and the encrypted content.

Then, the encrypted data is uploaded. The network request entity parameters also indicate that the uploaded data includes the key and the encrypted collected information.

Encryption Algorithm Analysis

The malicious software will encrypt the uploaded data when uploading information, and the encryption algorithm used in the communication process is RSA_AES mode.

Firstly, the CryptAcquireContextW function is used to create a key container. From the parameters, we can know that an RSA_AES key container is created, with PROV_RSA_AES = 24.

Then, the RSA public key is imported by calling the CryptImportKey function. The specific information of the RSA public key can also be obtained from the parameters of this function, such as the public key modulus, public key exponent, and the modulus of the public key.

Then, the CryptGenKey function is called to generate the key. From the parameters, we can see that the key algorithm is AES_128.

The used hash is SHA1.

Then, the CryptEncrypt function is called to encrypt the collected information data.

The AES key information generated previously is exported using the CryptExportKey function. During the export, the RSA public key is used to encrypt as part of the uploaded data. After the server receives it, it can decrypt the AES key using the RSA private key, and then further decrypt the main data. CALG_AES_128=0x0000660e.

Shellcode Analysis

This sample performs 2 important correction operations before entering the core function module, the first is to load the resource data into memory, then decrypt the first shellcode, and then jump to this location to execute. As shown in the figure below:

The second operation is to jump to the shellcode and execute after sorting, then allocate content again, copy related content, and change this memory segment to be readable and executable, and then jump to this core function. First, it calls the system function through the windows api hash method, rather than using it directly.

Then call the VirtualAlloc function to allocate space.

Then prepare to start copying data. It is worth noting that it first operates on the data starting from 0027053F. We can see from the previous memory address that this is exactly the start of the MZ header. Therefore, the decrypted shellcode contains the PE data of the core module of this program in its entirety.

Then the copied data is as follows, which is missing the MZ header of the PE data. The author may do this to prevent us from easily seeing that the core module is actually a complete PE format file, in order to prevent static auxiliary analysis from being performed during dump.

Then modify the memory attributes and jump to the core function entry to execute.

We dump this module and can see the complete entry of the core module.

The general process of the core module is as follows:

It can also be viewed with the help of code, since the functions used by this program are all dynamically obtained after running, so dynamic analysis is still required. However, with static disassembly, it can be more convenient to assist in viewing.

We can also see that there are many encrypted strings in the data segment, which are basically decrypted by the function sub_402B80.

We can also see relevant information in the dynamic debugging, of course, in addition to dynamic debugging, after static decompilation, decryption can also be performed through IDAPython.

We can see that this function was called a total of 31 times.

Solution

Do not click on emails and attachments of unknown origin;

Do not click on links contained in emails of unknown origin;

Please download the program from official websites;

Use strong passwords, avoid using weak password passwords, and change passwords regularly;

Open system automatic update, and check for updates to install;

IOC