Technical Analysis

The technique of spam bombing combined with phishing and vishing continues to be an effective technique that we previously discussed in our annual ransomware report back in 2024. These attacks typically involve a threat actor sending spam email to a targeted victim and then impersonating an IT staff member from the victim’s organization. The victim is instructed to join a Microsoft Teams call and initiate Quick Assist. If the victim falls for the ruse, the threat actor deploys malware onto the victim’s system to establish a foothold on the organization’s network. ThreatLabz has been able to attribute some of these attacks to Payouts King ransomware, a group that until now has largely remained under the radar over the last year.

Obfuscation and evasion techniques

Payouts King implements several common obfuscation methods such as building and decrypting strings on the stack, importing and resolving Windows API functions by hash, and hashing important strings instead of hardcoding them. Payouts King uses a combination of FNV1 hashes and a custom CRC checksum algorithm for obfuscation. The latter has been replicated below in Python.

def payouts_king_crc32(input_string: bytes) -> int:
   checksum = 0
   poly = 0xBDC65592
   for char_val in input_string:
       char_val |= 0x20
       checksum ^= char_val
       for _ in range(8):
           if checksum & 1:
               checksum = (checksum >> 1) ^ poly
           else:
               checksum >>= 1
           checksum &= 0xFFFFFFFF
   return checksum

Interestingly, when Payouts King uses FNV1 hashes to resolve strings, the seed value is unique per obfuscated value. This defeats tools that utilize large precomputed hash tables to quickly determine the original string. Payouts King also contains a significant number of strings that are obfuscated through stack-based arrays of QWORDS, which are used to construct individual encrypted strings and the corresponding XOR keys to decrypt them.

Command-line arguments

Similar to most ransomware families, Payouts King supports command-line arguments to enable or disable specific functionality. However, the Payouts King command-line arguments are obfuscated by the custom CRC checksum function described in the section above. Despite this, ThreatLabz was able to determine the original string arguments for all of the command-line checksum values. The Payouts King command-line arguments are summarized in the table below.

Table 1: Payouts King command-line parameters.

By default the ransomware will not perform file encryption unless the -i parameter is specified with a value whose CRC checksum matches an expected value. This is likely an anti-sandbox evasion technique.

If the -nopersist parameter is not passed on the command-line, persistence is established using scheduled tasks by executing the following command:

schtasks.exe /s "localhost" /ru "SYSTEM" /create /f /sc ONSTART /TN \Mozilla\UpdateTask /TR ""

If the -noelevate parameter is not specified, Payouts King will schedule another task to elevate privileges and run as the SYSTEM user as shown below:

schtasks.exe /s "localhost" /ru "SYSTEM" /create /f /sc ONSTART /TN \Mozilla\ElevateTask /TR ""

In order to run these scheduled tasks, Payouts King creates two pipes to read and write to standard input and standard output. The code then calls CreateProcess to launch cmd.exe without any arguments and redirects standard input and output to one end of the pipe. The ransomware code then writes the commands to the other end of the cmd.exe pipe, which creates the scheduled tasks. Payouts King reads the result from the pipe and checks for the string SUCCESS to determine if the task was created. If the elevation task is successfully created, the command schtasks.exe /run /tn \Mozilla\ElevateTask is sent through the pipe to execute the task immediately, followed by schtasks.exe /delete /tn \Mozilla\ElevateTask /f to delete the task and remove forensic evidence. Payouts King will then terminate the current process to allow the elevated process to perform the file encryption.

File encryption

Payouts King ransomware uses a combination of 4,096-bit RSA and 256-bit AES in counter (CTR) mode. The encryption code leverages the OpenSSL library, which is statically linked. Each file is encrypted with a pseudorandom key and nonce. The format of an encrypted file is the AES encrypted data followed by the RSA encrypted file encryption parameters as depicted below.

Figure 1: Depicts the format of an encrypted file where the AES encrypted data is followed by the RSA file encryption parameters.

The RSA encrypted parameters contains the following 487-byte structure:

struct payouts_king_rsa_encrypted_data {
 DWORD magic_bytes;    // "CRPT" (little-endian)
 QWORD encryption_type;// 0x825456 (AES) or 0x233567 (ChaCha20)
 BYTE aes_key[32];     // pseudorandomly generated per file
 BYTE aes_iv[16];      // pseudorandomly generated per file
 QWORD total_filesize; // the original file size
 QWORD encrypted_size; // the number of bytes encrypted
 DWORD num_encrypted_blocks; // full encryption (1), partial encryption (0xd)
 BYTE padding[407];    // random data
};

While Payouts King contains code to support AES or ChaCha20 encryption, the samples identified by ThreatLabz have only used AES.

The file content is encrypted according to the following algorithm:

• If the file extension matches any of those listed in Table 3 (shown in the Appendix), the full file content will be encrypted.
• If the file size is less than 10,485,761 bytes (10MB), the full content of the file will be encrypted.
• Otherwise, the file will be divided into 13 (0xd) blocks. Half of each block will be encrypted and the other half will not be encrypted. This is a performance optimization for encrypting large files that is commonly implemented by ransomware.
• If the -percent command-line option is specified, the corresponding percentage of the file will be encrypted in 13 blocks.

When encrypting files, Payouts King attempts to open the targeted file. If opening fails due to an error code 32 (ERROR_SHARING_VIOLATION), the ransomware will enumerate the running processes and compute a checksum value for each process name and compare the result against a list of 131 hardcoded DWORD checksum values. Many of these process checksums correspond to antivirus and EDR applications. ThreatLabz was able to recover most of the original process names, which are provided in the Appendix. If the process name checksum value matches, Payouts King will attempt to terminate the process. However, instead of using standard Windows API calls, the ransomware uses low-level direct system calls to evade antivirus and EDR hooks. The system call numbers are determined at runtime by manually walking the loaded ntdll module’s export table for function names that start with a Zw prefix to build a table of Zw* function names and addresses. 

Note that the table is sorted by the Zw* function addresses, and therefore the index in the table can be used to map the system call with the corresponding system call number. Payouts King ransomware then calculates a CRC for each Zw* function name with the malware’s custom CRC algorithm and compares it against an array of expected DWORD checksum values. These checksum values correspond to the following functions:

Table 2: Payouts King system call checksum mapping used to terminate security-related processes.

If the -backup command line parameter is specified, Payouts King creates temporary files to hold the original file data in case the encryption process is interrupted.

These files use a 56-byte structure in the following format:

struct payouts_king_backup_file_hdr {
 QWORD magic_bytes; // 0x1F2013150205BEF3
 QWORD num_bytes_encrypted; // current number of bytes encrypted
 BYTE reserved[16]; // unused
 QWORD file_data_offset; // current offset in file being encrypted
 QWORD block_size; // size of the data to encrypt in the next block
 QWORD custom_crc_checksum; // checksum of current block; performed only on the first byte of the block (likely a bug)
};

This data structure is updated for each block that is encrypted, and can be used to determine the last block of data that was encrypted if the process is interrupted. 

The following files are not encrypted since they are relevant to file encryption:

• .esVnyj (temporary backup file extension used during file encryption)
• .ZWIAAW (encrypted file extension)
• readme_locker.txt (ransom note filename)

The following Windows files are also not encrypted:

• desktop.ini
• ntuser.dat
• ntuser.ini

The following file extensions are also not encrypted:

• .bat
• .cat
• .dll
• .exe
• .lnk
• .msi
• .mum
• .sys

The following directories are also skipped:

• :$recycle.bin\
• :$winreagent\
• :\programdata\microsoft\
• :\program files\windowsapps\
• :\recovery\
• :\system volume information\
• :\windows\

After the content of a file is encrypted, the file is renamed with a hardcoded extension appended to the original filename. The file is renamed by using a more obscure technique via the function SetFileInformationByHandle using the FileRenameInfo class. This is likely designed to avoid antivirus and EDR detection that monitors calls to MoveFile and MoveFileEx.

Similar to most ransomware families, Payouts King deletes Windows shadow copies with vssadmin.exe delete shadows /all /quiet (to delete backups), empties the recycle bin via SHEmptyRecycleBinW (to remove deleted files), and clears the Windows event logs using EvtClearLog (to hinder forensic analysis).

Interestingly, the ransom note is not written to disk unless the -note parameter is specified on the command-line at runtime. The ransom note is written to the file named readme_locker.txt on the victim’s desktop as shown below.

Figure 2: Example of Payouts King ransomware note.

The ransom note contains information about how to contact Payouts King via TOX and provides a link to the group’s data leak site via Tor. The Payouts King data leak site is shown below.

Figure 3: Payouts King ransomware data leak site.