APT31 new dropper. Target destinations: Mongolia, Russia, the U.S., and elsewhere

Our pros at the PT Expert Security Center regularly spot emerging threats to information security and track the activity of hacker groups. During such monitoring in April 2021, a mailing list with previously unknown malicious content was sent to Mongolia. Similar attacks were subsequently identified in Russia, Belarus, Canada, and the United States. According to PT ESC threat intelligence analysts, from January to July 2021, approximately 10 attacks were carried out using the discovered malware samples.

Some of the files found during the study had rather interesting names ("хавсралт.scr" ["havsralt.scr"] (mong. attachment), "Информация_Рб_июнь_2021_года_2021062826109.exe") and, as the study showed, they contained a remote access trojan (RAT). A detailed analysis of malware samples, data on the paths on which working directories and registry keys were located, techniques and mechanisms used by the attackers (from the injection of malicious code to the logical blocks and structures used) helped correlate this malware with the activity of the APT31 group.

In this article, we will study the malware created by the group, focus in more detail on the types of droppers discovered and the tricks used by its developers.  You may find the whole text of the research and indicators of compromise that can be used by cybersecurity specialists to identify traces of the group's attacks and search for threats in their infrastructure here.

Dropper

The main objective of the dropper, the appearance of the main function of which is shown in Figure 1, is the creation of two files on the infected computer: a malicious library and an application vulnerable to DLL Sideloading (this application is then launched). Both files are always created over the same path: C:\ProgramData\Apacha. In the absence of this directory, it is created and the process is restarted.

Figure 1. Overview of the dropper's basic function

At the second stage, the application launched by the dropper loads the malicious library and calls one of its functions. It is noteworthy that MSVCR100.dll was chosen as the name of the malicious library in all cases. A library with an identical name is included in Visual C ++ for Microsoft Visual Studio. It is available on almost all PCs, but in a legitimate case it is located in the System32 folder (Figure 2). Moreover, the size of the malicious library is much smaller than the legitimate one.

Figure 2. Parameters of the legitimate MSVCR100.dll

It is also worth noting the trick of the malware developers: by way of exports, the library contains names that can be found in the legitimate MSVCR100.dll. Without a doubt, this was done to make the malicious library as identical to the original version as possible.

Figure 3. Part of the exports of malicious MSVCR100.dll

However, the number of exports in the malicious sample is much smaller, and most of them are ExitProcess calls.

Below is an example of a call to a malicious function from the created library. After the call, control is transferred to the malicious code. Note that the names of malicious functions were most often those used during the regular loading of applications.

Figure 4. Calling a malicious function inside a legitimate application

During the analysis of malware samples, we detected different versions of droppers that contain the same set of functions. The main difference is the name of the directory in which the files contained in the dropper will be created. However, in all the instances studied, the directories found in C:\ProgramData\ were used.

The version of the dropper that downloads all files from the control server is worthy of particular note. Let's take a closer look. At the first stage, the presence of a working directory is also checked, after which connection is made to the control server and the necessary data is downloaded from it.

Figure 5. Checking for a directory

Communication with the server is not encrypted in any way, nor is the control server's address inside the malware. Downloaded files are written to the created working directory.

Figure 6. Creating files in the working directory

Figure 7 displays the code sections responsible for downloading all files from the server (the last reviewed case), while Figure 8 displays the code for loading the main library (first instance).

Figure 7. Downloading files from C2

Figure 8. Downloading a malicious library from C2

Examining the open directories of control servers revealed unencrypted libraries (Figure 9).

Figure 9. Encrypted and unencrypted libraries on the server

It is also worth noting that in some cases, particularly during attacks on Mongolia, the dropper was signed with a valid digital signature (Figure 10). We believe that this signature was most likely stolen.

Figure 10. Valid digital signature of a dropper

Malicious library

Execution commences with receipt of a list of launched processes. That said, this has no impact on anything and is not used anywhere. The library then checks for the presence of the file C:\\ProgramData\\Apacha\\ssvagent.dll. This is the encrypted main load downloaded from the server.

In fact, this is a 5-byte XOR with a key built into the library. Inside the binary file, the key is stored in the form xmmword with the constant 9000000090000000900000009h (the fifth byte is added to the memory by the malware itself using the direct address). In fact, encryption is performed with byte 0x9. After decrypting the C2 address, it connects to the control server and downloads the encrypted payload from it. Then the received data is saved in the file C:\\ProgramData\\Apacha\\ssvagent.dll, and the legitimate application ssvagent.exe is restarted. The main part of the described functions is presented in Figure 11.

Figure 11. Decrypting the C2 address, loading and launching a new instance of ssvagent.exe

If the payload has been loaded earlier, it is checked for an application that is already running. To do this, a mutex named ssvagent is created; if it has been created, the application ends.

The library then writes the legitimate ssvagent.exe to startup via the registry, as shown in Figure 12.

Figure 12. Persistence via registry key

After this, the file downloaded from the server is decrypted using a XOR operation with a 5-byte key. Then the decrypted data is placed in the application memory, and control is transferred to it.

Payload

The main library starts its execution by creating a package that will be sent to the server. Officially, the package is created from three parts:

1. main heading
2. hash
3. encrypted data

The research describes their structures (learn more).

To generate a hash, which is preceded by the main heading, the malware obtains the MAC address and PC name (the result of executing GetComputerNameExW). These values are concatenated (without using any separators), after which an MD5 hash is taken from the resulting value, which is then converted into a string. An example of hash generation is presented in Figure 13.

Figure 13. Example of hash generation

The third part of the package is then formed.

Figure 14. An example of a generated package

The format of a complete generated package is presented below. The main heading is highlighted in green; the hash, in red; the encrypted data, in yellow.

Figure 15. Encrypted package with all headings

Figure 16. Decrypting data from a specific position within a binary file

The generated package is encrypted with RC-4 with the key 0x16CCA81F, which is embedded in the encrypted data and sent to the server. After this, malware waits for commands from the server.

Let's take a look at the list of commands that the malware implements:

0x3: get information on mapped drives.

0x4: perform file search.

0x5: create a process, communication through the pipe.

0xA: create a process via ShellExecute.

0xC: create a new stream with a file download from the server.

0x6, 0x7, 0x8, 0x9 (identical): search for a file or perform the necessary operation via SHFileOperationW (copy file, move file, rename file, delete file).

0xB: create a directory.

0xD: create a new stream, sending the file to the server.

0x11: self-delete.

The code for processing the last command is particularly intriguing: all the created files and registry keys are deleted using a bat-file.

Figure 17. Code for removing all components

A more detailed description of the payload is available in the full report.

Attribution