Important elements of the analysis: 

• Attack vector with Fortinet VPN vulnerability 
• Auto-encryption of the ransomware itself to perform bypassing 
• Dynamic and consecutive changing of encrypted file extensions 
• UPX packing 
• OpenSSL, AES OCB, ChaCha20_Poly1305 algorithms 
• Scheduled tasks 
• Restart management executions
• Enumeration of network shares 
• Using the C:\ProgramData\ntuser.dat file for the public key of the auto-encryption 
• Encryption of files in buffers  

Introduction 

Cactus Ransomware is a new threat, first identified in March 2023, with some special characteristics. It is distributed in compromised infrastructures mainly using certain Fortinet VPN vulnerabilities as an attack vector, allowing unauthorized access. The main feature of this ransomware is the auto-encryption, so the encryption of the ransomware takes place during the deployment phase, which means that the threat cannot be easily detected by EDR, XDR and anti-malware. During the encryption process of the target files, the extensions used are dynamically changed from .cts0 to .cts1. During the execution phase, the malware checks, similar to what happens in a concurrential access, whether a file is accessible at a certain time or not. 

The sample possesses the data leak portal hxxps[://]cactusbloguuodvqjmnzlwetjlpj6aggc6iocwhuupb47laukux7ckid[.]onion, which contains details of the various victims and their data. 

 
The communication channels of the malcoders are mainly the e-mail address cactus[@]mexicomail[.]com and the TOX Chat with URL hxxps[://]tox[.]chat[/):]7367B422CD7498D5F2AAF33F58F67A332F8520CF0279A5FBB4611E0121AE421AE1D49ACEABB254686 

Static analysis and assessment 

The sample submitted for analysis has the hash 78c16de9fc07f1d0375a093903f86583a4e32037a7da8aa2f90ecb15c4862c17, it is in a packed state with the UPX packer. 

Below are the details of the UPX and .rsrc packer sections of the file. 

Within the Overlay section, which contains data “appended” to the Portable Executable image, there are references to encryption functions such as ocb_decrypt and the .rdata section. 

Also within the Overlay data are details of what would appear to be a Boolean control attribute regarding a leaking context. 

With regard to imports, we can highlight the ADVAPI32.dll library (to execute the event log function appending ReportEventW), RstrtMgr.dll (to execute the RmGetList function to obtain a list of applications and services using the resources registered within the Restart Manager session), WS2_32.dll and WSOCK32.dll (in order to manage connections via sockets). 

The highest entropy coefficient, due to UPX packing, is 7.94368. 

The PE manifest has an attribute of requestedExecutionLevel as ”asInvoker”, so  it is executed with the same permissions as the parent process token. 

From the strings extracted from the executable, one can see references to CBC encryption routines and CBC decryption routines relating to the AES algorithm. 

Below are the details of some public key storage objects, for example EVP_PKEY_set1_encoded_public_key: 

The EVP_PKEY_verify_recover_init function can be used to verify the signature associated with the public key algorithm. 

Below is a detail on the chacha20_poly1305 algorithm, the cipher object is highlighted. The algorithm in question is a mix of ChaCha20 and Poly1305 and involves a preliminary authentication process. 

In the screenshot below, the private key loading functions associated with OpenSSL are highlighted: 

Here is the UPX unpacking phase: 

From the extracted strings there are details concerning authentication processes (lsass.exe and winlogon.exe), services.exe, the ProgramData folder. 

Cactus Ransomware bypasses Windows Defender protection, uses TOR Browser to contact malcoders, the file (stored in the folder C:\ProgramData) is used for the purpose of storing the key for encrypting the executable file. It doesn’t represent the original Windows ntuser.dat file, but rather a file so named in all likelihood to evade and confuse the nature of the file itself. In addition, the batch script rn.bat is most likely used for the file renaming phase. The log file C:\ProgramData\update.log is used for tracking the ransomware infection, while the threat also threatens to publish the victim’s data if the ransom is not paid. 

Cactus Ransomware creates a scheduled task for malicious persistence called “Updates Check Task”. 

Here a detailed MD5 and SHA1 hashing digest: 

Note the functions IsFileFree (which is used in order to check whether a certain file can be encrypted), canWriteDirectory (to check whether a certain folder allows write events), killFileProcesses (with the purpose of terminating processes that occupy the resources of a certain file), weCanKillProcess (used in order to check whether a certain process can be terminated) 

Dynamic analysis and disassembling 

Contextually with ChaCha20 executions, in the label loc_14010E1BE, there are numerous movaps, movdqa and movdqu operations inherent in xmm registers 

There are references to attributes N and 9 relating to registers xmm2, xmm9, xmm0 and xmm11. 

Below is a detail concerning characters with newline attributes within the exception management section .xdata: 

Cactus Ransomware makes changes to the desktop.ini configuration file, and newline attributes are also added to the update.log tracking file: 

The e-mail address cactus[@]mexicomail[.]com is the contact address of the malcoders: 

Here is an introduction string from the ransomware readme file: 

Within the cryptFullFile function, the EVP_EncryptUpdate function and istream and ostream functions were called up to manage the file attributes taken in consideration during the encryption phase: 

Initially, the extension “.cts0” is “appended” to the encrypted files: 

It is subsequently replaced with the extension “.cts1”: 

There is the use of the wildcard “*” for filesystem enumeration: 

Here the enumeration function of the compromised machine’s disks: 

Following are the details of the killFileProcesses function, which includes the RestartManager to “free” the resources of the files to be encrypted from the processes that are (possibly) using them. 

Below is a reference that would seem to be associated with access to network shares, as well as concurrential access to the files to be encrypted, taking in consideration their attributes and through a Boolean confirmation: 

Here the check of longpaths by Cactus Ransomware taking in consideration UNC (Uniform Naming Convention) paths: 

The rn.bat script is most likely used when renaming files taken in consideration during the infection kill chain: 

The extractDirPath function obtains the filenames given a specific path: 

Cactus Ransomware has a global attribute, which would seem to refer to a blacklist of extensions, in fact named extBlackList:

The function hexEncode takes as an input parameter the variable var_178, used in a lea instruction with the rbp register, to load the memory address in question: 

The makeNtUserFile function is crucial in order to save the ransomware’s own encryption string during post-infection-deployment: 

Here, the wildcard “*” is used in the file enumeration loop to obtain the files to be subjected to the encryption process: 

The files taken in consideration are saved in a filesArray variable, in case there are errors when accessing them, an error string is produced: 

Here is a detail of logging a disk infection: 

The operation of reading the C:\ProgramData\ntuser.dat file is crucial for the decryption of the ransomware itself:  

Here, in fact, the reference to the sample’s encryption ID: 

Second malware assessment 

This sample of Cactus Ransomware was compiled on 24 March 2023: 

Suspicious indicators in the sample are mostly related to TLS callbacks, extensions heuristically associated with ransomware infections, the number of symbols attributes, encryption functions, network enumeration, compression routines, file management, reckoning and environment discovery, Base64 encoding, desktop configuration management, services management, password references and keyboard keys management. 

The entropy of the .text section is 6.692: 

The imported libraries identified as suspicious were rstrtmgr.dll, ws2_32.dll and wsock32.dll: 

Functions to watch out for include, for example, FindFirstFileW, GetCurrentProcessId, GetLogicalDriveStringsW, GetVolumeInformationW, MoveFileExW, RemoveDirectoryW, TerminateProcess, CryptAcquireContextW, CryptGenRandom, CryptReleaseContext, RegisterEventSourceW, RmRegisterResources, accept, bind, closesocket. 

Below is a detail referable to the private key attribute with the data type set to %d, so decimal integer, there are also attributes referable to strings relating to IP addresses and e-mail addresses. 

The RVA (Relative Virtual Address) entrypoint of the sample under consideration is 000013F0: 

Here are details of some sections on the PE packing process: 

The send function of socket connections has as Import by Name raw 00522E1A: 

Within the disassembled .text section, it is possible to highlight a call instruction at address 0x1403FAA00: 

There are also references to mov instructions within the RBP register with different offsets: 

The OptionalHeader has a size of 240, with 14 PE sections. 

The size of the full image is 67B000, while the size of the headers is 600: 

Here are the addresses for the export, import, resources, exceptions (section .xdata), security, debug directories. 

The largest section is .text, containing executable code: 

In the screenshots below, there is fundamental evidence of some of the malicious execution functions already mentioned concerning the context of encryption, event log management, restart management, and sockets connections management. 

Here below a reference to parameters and exception addresses at address 530180: 

Here is a reference to the mingw compilation command: 

Assembly dumping 

By dumping the low-level assembly instructions, we can see that there is a tryFileOpen object in the isFileFree function. 

At address 0x140002ab7, a lea instruction is executed to load the memory address for the ntuser.dat file into the rax register. 

The SearchFiles function uses an enumeration loop by checking the fullpath via the checkingfullpath function. 

The memory address for cryptKey with an offset of 0x10 is loaded into the rax register. 

It is also checked if a file or folder exists by means of the std::filesystem::exists function. 

The content of the Cactus Ransomware readme at 0x140002a42 follows: 

At the same time as encrypting the files obtained after their enumeration, an array buffer of the encrypted files is defined: 

The enumerated disks on the compromised machine are saved in an array: 

Here a detail of the loading of the public RSA key in PEM format: 

Here, the AES decryption function, whose input attributes include EVP_CIPHER_CTX, ciphertext, ciphertext_len, key, iv and plaintext: 

Within the EVP_DecryptInit_ex function, the memory address of the openssl_3.1.0_crypto_evp_enc.c object is saved in register r13 at address 0x14001b184. 

The EVP_CIPHER_CTX_gettable_params and EVP_CIPHER_CTX_rand_key structures contain the attributes and parameters of the encryption object obtainable and the randomly generated public key, respectively: 

At the same time as obtaining the length of the cipher key, an edx register XOR instruction is executed, followed by a call to a function to randomize the private key bytes and a subsequent XOR instruction. This resets the value of the eax register to zero. 

Here the details of a Boolean attribute used to control whether a certain process can be terminated or not, and the session key variables: 

Here are the details of the hexadecimal code of the analyzed sample, where references to chars and strings management are evident: 

Debugging session 

Following are some details of the debugging session carried out, where we note references to the Cactus Ransomware readme TXT file, the unique ID of the ransomware infection, a reference to TOX chat for contact with malcoders: 

If files and folders that have not to be encrypted are taken in consideration, they are “skipped” by the encryption process. 

Here the details of some strings that can be found in a debugging context, especially concerning the ntuser.dat file, scheduled tasks, the C:\ProgramData folder and the ransomware encryption string itself. 

The C:\ProgramData\ntuser.dat file contains a random string referring to the encryption string of the ransomware sample:

Here are the ASCII and hexadecimal details of the processes taken over by the infection kill chain and the call of the AES_init_key function: 

Here we can see encryption attributes of OpenSSL and ChaCha20Poly1305: 

Note the details regarding the Blake2 encryption routine and the insertion of the private key with the data types %s (string) and %C (characters). 

The sample is recognized as malicious by OSINT sources and identified as trojan.cactus/genericfca: 

Here a detail of a key finding attempt using the random string entered in the C:\ProgramData\ntuser.dat file: 

By decoding the string in question from hexadecimal, it is possible to identify the Freedom of Information Act domain and the justice[.]gov domain. However, with later patterns, it should contain the substring used as the public key for encrypting the ransomware. 

IOCs: 

• 78c16de9fc07f1d0375a093903f86583a4e32037a7da8aa2f90ecb15c4862c17 
• cb570234349507a204c558fc8c4ecf713e2c0ac3 
• e28db6a65da2ebcf304873c9a5ed086d 
• Updates Check Task scheduled task 
• CaCtUs.ReAdMe.txt 
• cactus[@]mexicomail[.]com 
• TOX Chat ID: 7367B422CD7498D5F2AAF33F58F67A332F8520CF0279A5FBB4611E0121AE421AE1D49ACEABB254686 
• cactus787835[@]proton[.]me 
• cactusbloguuodvqjmnzlwetjlpj6aggc6iocwhuupb47laukux7ckid[.]onion 
• sonarmsng5vzwqezlvtu2iiwwdn3dxkhotftikhowpfjuzg7p3ca5eid[.]onion 

YARA rule: 

rule CactusRule 

{ 

    strings: 

        $cactusStr = “CaCtUs.ReAdMe.txt” 

        $cactusHex = { 43 61 43 74 55 73 2e 52 65 41 64 4d 65 2e 74 78 74 } 

    condition: 

        $cactusStr or $cactusHex 

} 

CONCLUSIONS: 

Cactus Ransomware has several features that, at least potentially, could change the scenario for new ransomware infections. The new threats would take on new fundamental characteristics of auto-encryption and the consecutive change of several extensions of encrypted files, which would make it more difficult to identify the files themselves, which are subjected to the encryption process. There is also a peculiarity concerning the use of the C:\ProgramData\ntuser.dat file to store the string used as the public key for encrypting the malware sample itself. The file ntuser.dat represents an element used ad-hoc for the self-encryption of the ransomware specifically with such a filename for the probable purpose of confusion and evasion. To understand the nature and functioning of Cactus Ransomware, we can mention two important peculiarities: it uses the UPX packer, which is widely known and easy to “unpack”. Furthermore, the files subjected to the encryption process are divided into portions saved in micro-buffers, probably to speed up the management of encrypted data streams.