Attack chain

In early May 2025, ThreatLabz identified a malware campaign delivering multiple RATs as the final payload. The attack chain for this campaign is shown in the figure below. 

Figure 1: Attack chain for a malware campaign delivering several RATs.

The threat actor uses GitHub Pages to host phishing sites impersonating popular software installers. These installer packages are ZIP archives that contain a malicious executable file. The figure below highlights an example phishing page used in the campaign.

Figure 2: Example phishing page impersonating Ding Talk that ultimately delivers various RATs.

First stage

During the initial stage of the campaign, the malware employs two distinct methods to identify sandbox environments and virtual machines (VMs):

Time stability analysis 

Using QueryPerformanceCounter, the malware measures the time for a repetitive operation, compares the average (expected 300 ms) to a threshold (0.0008), and identifies sandboxes/VMs if the deviation exceeds this limit.

Hardware configuration 

The malware assesses disk space (minimum 50 GB) and CPU cores (minimum two). If these thresholds aren’t met, the malware initiates evasive actions, including altering the Process Environment Block (PEB) structure:

• ProcessParameters->ImagePathName and ProcessParameters->CommandLine are altered to mimic %WINDIR%\explorer.exe.
• The malware also traverses InLoadOrderModuleList. If any entry’s BaseDllName matches the current process name, both BaseDllName and FullDllName are rewritten to %WINDIR%\explorer.exe.

These modifications corrupt the final process snapshot taken by sandboxes and will result in the malware terminating execution.

After completing the sandbox and VM checks, the malware performs the following anti-analysis/obfuscation methods.

• API resolution: The malware dynamically loads required Windows API functions by performing single-byte XOR (key: 0x4) operations on stack strings.
• Next-stage file decryption: The malware applies single-byte XOR operations (key: 0x1) to extract decryption keys for the next-stage files.

Memory is allocated for next-stage shellcodes, which are decrypted, written, and directly executed by the first stage. All shellcodes utilized in the campaign employ pe_to_shellcode transformation logic. 

Second stage

To bypass AV software and EDR systems, the malware employs several techniques. The first technique is verifying administrator privileges. If the malware does not have sufficient privileges, a message is displayed in Mandarin prompting the user for elevated access and exits. If the malware has administrator privileges, the malware enumerates all active network adapters and temporarily disables them, severing AV/EDR communication with the corresponding vendor’s servers.

Following this, the malware scans the system for the presence of specific AV and EDR processes predominantly associated with China-based cybersecurity vendors. These vendors include:

• 360 Total Security
• QQ电脑管家
• HeroBravo System Diagnostics suite
• Kingsoft Internet Security
• 360 Internet Security suite

If targeted processes are detected, the malware uses a known vulnerable driver (RTCore64.sys) to disable AV/EDR functionalities. This is achieved by comparing the name of the AV/EDR driver that registered each callback. The complete list of targeted drivers can be found in the ThreatLabz GitHub repository.

The malware incorporates code borrowed from the RealBlindingEDR project to remove registered system callbacks, targeting three specific types of callbacks for elimination:

• ObRegister callback: Monitors, blocks, or modifies how the system creates and duplicates handles using callback routines.
• MiniFilter callback: Allows minifilter drivers to filter specific file Input/Output (I/O) operations.
• CmRegister callback: Monitors, blocks, or modifies Windows registry operations via callback routines.

After disabling callbacks, the malware terminates and deletes files of specific AV/EDR processes at the user level. The malware also creates a scheduled task to run with SYSTEM privileges to execute a batch script on every user logon to ensure the processes are repeatedly killed.

Next, the malware modifies registry keys associated with the 360 Total Security program:

• The NetCheck registry value is set to 0 in HKLM\SOFTWARE\WOW6432Node\360Safe\360Scan (presumably to disable network checks).
• Adds random data to a null value name under the registry key located at HKU\360SPDM\CC2FCASH\speedmem2\x\b5e3891842b605bf7917ba84.

Following these registry changes, the malware re-enables the previously disabled network adapters to restore the system's network connectivity. Thereafter, the first-stage shellcode executes the third-stage shellcode, which functions as a downloader to facilitate the next phase of the attack.

Third stage

The malware retrieves and executes a shellcode file named 2025.bin from a hardcoded URL by utilizing the EnumDateFormatsA API callback. The shellcode, heavily obfuscated with junk code, downloads a Base64-encoded file named output.log, which is decoded to reveal structured data for subsequent attack stages. An example is shown below.

Figure 3: Hexdump of the decoded data used to download various RATs. 

The decoded data is structured using the delimiters 0xA1 0xF9 that act as a field separator, dividing individual fields within a record, while 0xA1 0xF6 serves as a record terminator, marking the end of each record. The decoded data consists of 62 records, each record starts with an index ranging from 0 to 61. In each record, the second field contains two URLs, and these URLs are used to download two archive files:

• trx38.zip: When unzipped, trx38.zip includes a legitimate executable file and a malicious DLL.
• *.zip: (Where * represents a wildcard) This ZIP archive contains a file named longlq.cl, which holds the encrypted final payload.

The malware selects a record based on the last letter of the current process's filename. For example, if the filename was setup.exe, the file p.zip would be downloaded. The malware then will create a shortcut for the legitimate executable extracted from trx38.zip, add this shortcut to the startup folder for persistence, and execute the legitimate executable to sideload the malicious DLL.

The malicious DLL decrypts and executes the final payload from the file longlq.cl using a 6-byte XOR key at offset 0xD3000, with encrypted data at 0xD3006. The final payload of the campaign varies based on the second ZIP archive that is downloaded. This campaign delivers three different RATs: ValleyRAT, FatalRAT, and kkRAT. 

Final payload

Since ValleyRAT and FatalRAT are already extensively documented, they will not be analyzed in this section. However, kkRAT is a previously unknown malware family that incorporates elements from both Ghost RAT and Big Bad Wolf. These shared similarities are outlined below:

• Ghost RAT: kkRAT shares similarities with Ghost RAT’s network communication protocols, but introduces an added layer of encryption applied after data compression. kkRAT also borrows several network commands from Ghost RAT, such as COMMAND_ACTIVED, COMMAND_KEYBOARD, and COMMAND_LIST_DRIVE.
• Big Bad Wolf: kkRAT adopts specific DLL exports from Big Bad Wolf’s primary plugin DLL, including DllShell and DllScreen.

Encrypted configuration

kkRAT’s configuration, such as the C2 server IP and port, version, and group identifier, are stored as encrypted strings and sent in the registration message. A Python script for decrypting this configuration is available in the ThreatLabz GitHub repository.

Device fingerprinting

After establishing a socket connection, kkRAT gathers system information for device fingerprinting. The collected data is sent to the C2 server in a registration message with the structure below.

struct REGISTRATIONINFO
{
BYTE Token; // 0x66 hardcoded value
OSVERSIONINFOEXA OsVerInfoEx; // OS version information
DWORD CPUClockMhz; // CPU frequency
int CPUNumber; // Number of processors
IN_ADDR IPAddress; // Host local IP
char HostName[50]; // Host name
bool IsWebCam; // Is there a web camera connected?
DWORD socketTime; // Time since the socket was established
DWORD Speed; // Internet speed in mbps
DWORD MemSize; // Total physical memory size
DWORD DriverSize; // Hard disk capacity
char Group[50]; // RAT Group - set to Default
char UpTime[32]; // System uptime
char Version[32]; // RAT Version - set to Enterprise
BOOL Is64; // 32-bit or 64-bit; 1 is 64 while 0 is 32
char AV[80]; // List of AV's installed
DWORD isIdle; // Is idle for more than 3 min?
char TG[40]; // Is Telegram present on the system?
char WC[40]; // Is WeChat present on the system?
char QQ[80]; // QQ number
BOOL IsAdmin;// Is Administrator
char UserName[50]; // Account username
};

Network communication protocol

kkRAT's network communication protocol closely resembles that of Ghost RAT, with an added layer of encryption applied after data compression. Each packet exchanged between kkRAT and the C2 server is sent via TCP and follows a specific structure, as illustrated in the figure below.

Figure 4: kkRAT packet structure.

The original data is first compressed using zlib and then encrypted using an XOR-based algorithm with a key embedded in the malware binary. The Python script provided in the ThreatLabz GitHub repository can be used to decrypt the network data captured.

Plugins

kkRAT retrieves its main plugin and saves it on disk in an encrypted format. When a specific command calls for a plugin export, the encrypted plugin is read from disk, decrypted, loaded into memory, and the requested export is executed. The Python code in the ThreatLabz GitHub repository can be used to decrypt the encrypted plugin. The encryption algorithm is similar to the XOR-based algorithm used to protect network communications. 

The table below outlines the plugins and exports for kkRAT.

Table 1: Plugins supported by kkRAT.

Note that kkRAT's main plugin, Plugin32.dll, was uncovered alongside the source code of an older version on VirusTotal, which served as the basis for the RAT's name.

After receiving the registration message, the C2 server issues a series of commands for kkRAT to execute. kkRAT supports an extensive range of commands, integrating functionality from its plugin DLL exports. While the known command IDs associated with Ghost RAT are excluded, the table below provides the command IDs for the plugin DLL exports discussed earlier and the new commands introduced in kkRAT.

Table 2: Commands implemented by kkRAT.