Introduction

In April 2022, PT Expert Security Center detected an attack on a number of Russian media and energy companies that used a malicious document called «list.docx» to extract a malicious payload packed with VMProtect. Having analyzed the network packet, we found it to be identical to the one we studied in our report on APT31 tools, suggesting that these may belong to one and the same group. The malware samples date from November 2021 to June 2022.

Detailed analysis (see the "Attribution" section) of the unpacked malware confirmed our assumptions, as the malicious payload under VMProtect was indeed identical to the one we examined earlier.

Further monitoring revealed a number of documents used in attacks on the same companies with content similar in terms of the techniques used (see the "Malware analysis" section), yet differing from what we saw earlier both in the network part and the code implementation.

Detailed analysis of the tools showed the use of the Yandex.Disk service as the C2 server. This seemed a rather curious case to us, since it involved a potentially foreign group using a Russian service specifically to make the network load look outwardly legitimate.

The technique is not new, having been deployed by the TaskMasters group in its Webdav-O malware. The point of this technique is to bypass network defenses by connecting to a legitimate service.

This group's previous use of the Dropbox cloud service, as well as overlaps with the above-mentioned tools, suggests that here too we are dealing with the toolkit of the APT31 group.

This report describes the tools and techniques and their features, discusses the similarities and differences, and lays out the characteristics on which basis we assigned them to the APT31 group.

Analyzing malicious documents

The source document we started our research with (Figure 1) uses the Template Injection technique to download a template with a macro that loads malicious components (a legitimate file, a Java component, a malicious msvcr100.dll packed with VMProtect) from a remote server.

The template macro, a snippet of which is shown in Figure 2, creates files at the following path: C:\ProgramData\KasperskyOneDrive. The main task of the legitimate file is to transfer control to the malicious library using the DLL Side-Loading technique and generate an initializing packet that is sent to C2 (see the "Attribution" section).

During a further search for similar threats, a number of documents were found with the Author field equal to pc1q213 (Figure 3), containing an identical Base64 decoding code.

Analysis of the detected documents clearly showed their external similarity (Figure 4). Moreover, the code of the macros contained in them is identical all the way up to the names of the functions and variables (Figures 5 and 6).

A characteristic feature of all the documents is that they contain components for exploiting DLL Side-Loading to run the malicious payload inside them, as well as the external similarity of macros embedded in the documents and the Base64 encoding of the payload inside the documents.

The extracted payload also shows a number of similarities:

• Most of the binary files are packed with VMProtect;
• All the identified legitimate executable files are components of Yandex.Browser and signed with a valid digital signature;
• winhttp.dll and wtsapi.dll were used as malicious libraries under the guise of legitimate ones (in particular, by the presence, number, and names of exports).

Malware analysis

Our analysis identified two new types of malware, which we named YaRAT (because it has RAT functionality and uses Yandex.Disk as C2) and Stealer0x3401 (because of the constant used in obfuscating the encryption key). What's more, we saw YaRAT in two modifications: with token encryption inside the program code, and without it.

YaRAT

The Yandex.Browser installer signed with a valid Yandex digital signature, or its portable version, was used as a legitimate file vulnerable to the Side-Loading DLL. The file loads and calls a function in the malicious winhttp.dll.

And here's an example of function calls inside a legitimate binary file.

The malicious library itself is packed and encrypted, and is unpacked by calling DllEntryPoint, which happens whenever the library is loaded. In this case, DllEntryPoint contains code similar to UPX, which is probably borrowed but slightly modified.

The first stage also involves unpacking LZMA, after which the unpacked data is decrypted twice (code sections and other sections (imports, data, etc.) are decrypted separately).

The data is decrypted using the RC4 algorithm; both encryption keys are embedded in the code. A distinctive feature of both data decryption blocks is the type of code obfuscation (Control Flow Flattening), which hinders static analysis. Alongside this technique, an extra byte (0xB9) is inserted inside the function body, which confuses the disassembler and prevents it from generating the function's decompiled form.

An example of the code responsible for data decryption after the PRNG stage is given in Figure 9.

The subsequent code for restoring imports and their addresses (resolving function and library addresses), as well as changing attributes for virtual memory blocks (VirtualProtect calls), is identical to regular UPX (Figure 10 shows a snippet of packer code, Figure 11 shows regular UPX). Note also the distinctive, UPX-specific push and pop calls at the start and end, respectively, of the unpack function. After unpacking, control passes to the payload.

Payload

At the first stage, a mutex named YandexDisk is created, and the malware adds itself to startup via a registry key.

Next, the malware generates string requests to Yandex.Disk with the Authorization: OAuth parameter, to which the token for this account is concatenated (Figure 13). The token itself is stitched into the code. We found several keys belonging to three accounts: jethroweston, Poslova.Marian, upy4ndexdate.

After that, two lines are generated according to the pattern: pcname + /a.psd and pcname + /b.psd, for example: DESKTOP-IM5NM8R/a.psd, DESKTOP-IM5NM8R/b.psd.

The first request sent by the malware to C2 is a PUT to

    

https://cloud-api.yandex.net:443/v1/disk/resources?path=
    

If the connection is successful, the malware downloads a file (Figure 15) whose name consists of the following strings: the name generated in the previous step and the string modifier a.psd, which ends (is concatenated to the end of) the string name. For example,

    

https://cloud-api.yandex.net/v1/disk/resources/download?path=DESKTOP-IM5NM8R%2Fa.psd
    

The downloaded file contains a list of commands to be executed by the malware in order to retrieve basic information about the infected machine.

The commands are executed in a standard Windows shell (cmd.exe); the malware concatenates their results, forms them into a response, and sends them to Yandex.Disk as a b.psd file. Note that the result of the execution of each command is separated from the others by the line ==============\r\n (Figure 16 clearly shows the results of execution separated by this line).

Next, the malware switches to command execution mode. Malware-executed commands:

• DIR — retrieves the list of files in the directory;
• EXEC — executes the command (in fact, calls the WinExec function of the kernel32.dll library);
• SLEEP — calls the Sleep function with a parameter (0x3E8 multiplied by the passed constant);
• UPLOAD — uploads a file to Yandex.Disk;
• DOWNLOAD — downloads a file from Yandex.Disk.

All network communication is via cURL. In turn, data is transferred in JSON format, so the nlohmann/json, library is used to handle it; both libraries are statically compiled with the project.

Second YaRAT modification

Also found were a number of samples covered by VMProtect and not packed with the packer described above. A distinctive feature of all the samples is that only DllEntryPoint is covered by the protector, while the exports, which contain the main functionality, were not virtualized (except for some WinAPI calls).

Another distinguishing feature of such malware samples is the Blowfish-encrypted token with a key embedded in the code.

Despite the virtualized API calls, the application lends itself to static analysis and has a functionality quite similar to the one discussed above. The names of the built-in commands have not changed, and some commands may be missing.

As in the previous case, communication is via cURL; the same library is used to process JSON.

Stealer0x3401

The infection mechanism in this case is identical to the one examined in in our report: the legitimate binary file dot1xtray.exe downloads the malicious msvcr110.dll. In this instance, the __crtGetShowWindowMode export was malicious.

In the first step, the malware checks the name of the running process, which should not be qip.exe, aim.exe, or icq.exe. Otherwise, control will not pass to the main functionality.

Next, the address of the C2 server is decrypted (Figure 18). This algorithm is clearly identical to the one discussed in the previous report. Both the encryption key and the format of its location remained unchanged.

Next, the malware harvests the necessary information about the system by group. A list of these groups is shown in Figure 20 Note that this list is highly detailed and we have not seen such a list before. What's more, earlier tools used by the group collected other data. The fact that the malware contains lines in Russian is also curious (Figure 19).

All collected data is RC4-encrypted and Base64-encoded before being sent. In contrast to what we saw earlier, an encryption key is generated for each new run; the key generation algorithm is as follows (Figure 21): based on the current time, 16 pseudo-random numbers of qword type are generated (the loop adds 64-bit numbers up to the specified address; the difference between them is 128 bytes; accordingly, 16 qword values are obtained as per the data type), to which the standard key expansion procedure for RC4 is then applied. After that, the collected data is encrypted using the expanded key.

When transmitting encrypted data, the encryption key is not sent in cleartext; to obfuscate it, the previously unseen, so-called checksum procedure (Figure 22) is used for each qword value used in the key expansion procedure.

The procedure itself consists of two stages: generating a hash calculation table and directly calculating the result. The first stage involves cyclically computing the remainders from dividing the initializing constant (in this case 0x3401) using modulo 2 (until it becomes zero), that is, the number of rounds at each step of the checksum calculation will be identical.

At the second stage, the initial value is modified (_inputVal in Figure 22) in accordance with two variables initially equal to 0 and 1 (temValDword_1 and tempvalDword2 in Figure 22), from which at each step a value of type __int64 modulo 0x90c9bff is generated (result_x64Val in Figure 22). The constants themselves are also modified in each round.

As we see, the initial value is modified in each specific round as per the table of remainders created in the first stage. If the remainder is equal to 1, the hash, the variables themselves used in calculating the intermediate values, and the final value are all modified. Hence, a final value is generated for the specified 14 rounds (known in advance as regards modifying the initial value, since the table for all rounds is identical).

The generated hash for each of the qword components of the encryption key, the malware transmits to the server side.

Thus, the structure describing the encoded data is fairly simple:

    

struct Message{
    QWORD key[16]; // hash array of qword components of the RC4 key
    char encrData[sizeOfData];
};
    

The generated data is Base64-encoded, after which it is prepended with the data= string and transmitted in this form to the server (Figure 23).

The malware sends the generated data to the C2 server ramblercloud[.]com, which is disguised as a legitimate Rambler cloud drive, but is not.

Attribution

While examining a document that used Template Injection (see the "Analyzing malicious documents" section) and infected the system when run, we detected traffic described by us in our previous report (see Figure 24).

After infecting the system, the malware exchanges data with C2, then executes commands from it.

Analysis of the unpacked sample revealed similarities with the samples we found earlier. In particular, the names of RTTI objects (including the names of the vtbl tables used for communication with C2) turned out to be identical, as did the functionality of both applications. No changes to the architecture, executable commands, or packet generation methods were identified, nor had the traffic encryption key embedded in the program code been modified. The sole difference between the malware samples is the partial virtualization of API calls inside the protected application (which is typical for any program covered by VMProtect). A snippet of the function for processing commands from the server is given in Figure 25.

Also unchanged are the service strings and format strings used to generate packages and data structures within the application, the names of the APIs used, and the order in which they are called.

Analysis of various malicious components revealed a characteristic sign that points to a single code base. In all cases, the malware harvested information about network adapters, and the function code and call sequence were identical: a call to GetAdaptersInfo, then retrieval of the value of the NetCfgInstanceId and Characteristics keys in the SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E972-E325- 11CE-BFC1-08002BE10318} registry hive.

These calls by themselves are quite standard; that said, we found no other examples of using this technique.

The code generated by the compiler was also identical, snippets of which (see Figure 26) we found in all unpacked malware components used in the campaign.

Confirms our assumption that this malware belongs to the APT31 group.

All the malicious components we detected can be divided into several groups:

• Documents with the same stub;
• Source documents have the same Author field;
• Malicious components have unique (within the scope of our coverage) code snippets that we have not seen elsewhere;
• Malware uses a cloud service in the role of C2.

The first point of interest is the external similarity between the stub in the documents that we attributed to the APT31 group above and the stub in one of the documents that extracted malicious components interacting with Yandex.Disk. The second is the identical code for retrieving information about network adapters that we encountered in both the attributed tools and in the tools described in this report.

Of particular note is the malware that harvested information about the infected system. This malicious component contains code we saw in the previous report on APT31 activity, with the code itself identical to that which was presented there. This malware additionally installed in the system a document with the Author field that we saw in other detected malware.

This malware thus acts as a linchpin for all the malicious components discussed above.

Having analyzed the above-mentioned tools, we can assign the malware samples studied to one group with a high degree of certainty. And given the use of cloud services as C2 servers (in this case, Yandex.Disk), which this group had already weaponized (previously it used Dropbox), we can assume that a single code base was used to write the malicious components.

The similar infection and persistence techniques, the numerous intersections within the code implementation framework, and the artifacts of the compilation tools used all strongly suggest that the group may continue its attacks on organizations in Russia.

Authors: Denis Kuvshinov, Daniil Koloskov, PT ESC

Indicators of compromise (IoC)

File indicators

Network indicators

portal.super-encrypt.com

super-encrypt.com

portal.intranet-rsnet.com

intranet-rsnet.com

p1.offline-microsoft.com

offline-microsoft.com

cdn.microsoft-official.com

microsoft-official.com

ramblercloud.com

yandexpro.net

MITRE TTPs