Trojan.Scavenger в вирусной библиотеке:

Trojan.Scavenger malicious apps steal user data from crypto wallets and password managers on Windows-based computers. They infect the target system in several stages, in which various members of the family are involved—e.g., trojan downloaders and the stealers themselves. Some of them exploit the DLL Search Order Hijacking class of vulnerabilities. Such vulnerabilities allow them to use legitimate programs to launch themselves.

At least two infection chains are known to use various malicious downloaders. However, in every instance, the trojan that starts the infection process is distributed via torrents under the guise of gaming mods, patches, and cheats (in the form of DLL or ASI files) and is accompanied by installation instructions. In these instructions, threat actors encourage users to copy the trojan file into the target directory. Depending on which infection chain is involved, this file is either automatically launched in the context of vulnerable applications (a DLL file) or loaded as a “mod” when a game starts (an ASI file).

Various Trojan.Scavenger modifications have a number of features in common:

• they use the same C2 servers;
• they use the same hashing and a constant table;
• they perform the same environment check when launched;
• their strings are obfuscated using XOR;
• they have a unified way of getting the WinAPI function pointers;
• they have the same techniques for calling WinAPI functions.

The environment check

When launched, most of the Trojan.Scavenger malicious apps preliminarily perform a step-by-step environment check, which is standard practice for representatives of this family. This check is to detect whether the trojans are operating in a virtual environment or debug mode.

1. They check that the following functions do not have code modifications:

   • NtClose — this function must start with the opcode 0x4c;
   • IsDebuggerPresent — this function must start with the opcode 0x48.
2. They check that the field BeingDebugged in the structure PEB has the flag False.
   
   

3. Using the function GetSystemFirmwareTable, they get the RSMB firmware list for the built-in BIOS software and check the following matches:

   • VMware
   • qemu
   • QEMU

4. They check for the presence of the following libraries in the list InMemoryOrderModuleList of the structures PEB->LDR:

   • snxhk.dll
   • Dumper.dll
   • vehdebug-x86_64.dll
   • 0Harmony.dll
   • winsrv_x86.dll
   • winsdk.dll
   • cmdvrt32.dll
   • Sf2.dll
   • SxIn.dll
   • SbieDll.dll
5. They call the function WriteConsoleW(-1LL, 0LL, 0LL, 0LL, 0LL); the returning value must not be 1.

If they detect one of these signs, the trojans stop working.

Obfuscation

The trojans call WinAPI functions by searching for the pointer to the function based on its hash. First, they go through the lists
PEB->LDR->InMemoryOrderModuleList to get information about the library. Then they parse the MZPE header and obtain the pointer to the export table:

Next, they search for the pointer to the desired function by the hash:

The strings that the trojans use are encoded with XOR and are dynamically compiled inside the malware’s code:

In addition, the trojans can call functions by their number and via syscall.

Shared C2 servers

These trojans use the following domains for communication:

• datacrab-analytics[.]com
• datalytica[.]su
• datahog[.]su

Data encryption and encoding in packets when communicating with the C2 server

Data that the trojans send to the C2 server

The original data is encrypted with the XXTEA algorithm before being sent. Next, it is encoded with base64 and transmitted to the server in this form.

Data sent from the C2 server

The original data is encoded with base64. After decoding, it can be represented as follows:

• unencrypted;
• encrypted with XXTEA;
• encrypted with XOR with a string.

Checking the encryption key

All components of the family (except Trojan.Scavenger.1) go through a key creation and encryption verification step, which includes two requests:

• receiving part of the encryption key;
• key verification.

First request sent (receiving the second part of the key)

The trojans send a request to the C2 server via the route /c/k2. In response, the server sends the second part of the encryption key. This key is used to encrypt some of the parameters and data in certain requests. The encryption algorithm is XXTEA.

Second request sent (verifying the encryption key)

This request is sent to the C2 server via the route /c/v and has the following parameters:

• v — a randomly generated string of 16 symbols;
• t — the current time;
• s — the time value, encrypted with XXTEA.

The C2 server responds to this request with the same identifier it received in the parameter v.

Starting from this request, all subsequent requests have the parameters t and s, which are standard for members of this family. Without these parameters, the control server responds to all requests with the error 403.

MITRE matrix

News about the Trojan.Scavenger malware