Ransomware is always evolving, and Cactus is no exception. When I came across this sample, I knew it was worth a closer look. It’s built to obfuscate, encrypt, and evade, but like any malware, it leaves behind clues. In this series, I’ll walk you through the process of analyzing Cactus ransomware, starting with static analysis.

Why start with static analysis? It’s a safe and essential first step. Without executing the malware, we can explore its structure, identify potential artifacts, and gather valuable insights that lay the foundation for deeper analysis. Whether it’s examining its file format, extracting interesting strings, or analyzing metadata, this approach helps us build a clear picture of what we’re dealing with.

In this article, we’ll:

• Take a close look at the binary structure of Cactus to understand its layout.

• Extract key strings that might reveal commands, URLs, or other indicators of compromise (IOCs), among other interesting details.

To follow along, you’ll need a secure lab environment and some basic tools. If you don’t already have a preferred set, don’t worry—this is flexible. Tools like Detect It Easy (DIE) and PEStudio are great starting points. If you’ve installed REMnux OS or FLARE-VM, you already have half the job done.

In the next section, we’ll dive right in and open up the binary. We’ll start peeling back the layers, step by step. Ready? Let’s get to work.

If you want to follow along with me before starting, here is the hash of the sample we’ll be using:

SHA256: 78c16de9fc07f1d0375a093903f86583a4e32037a7da8aa2f90ecb15c4862c17. You can download it from the following website: https://tria.ge/

I will use Detect it Easy and Flare-VM first and here you can see the hash:

Upon opening the Cactus ransomware binary in our static analysis tool, the first thing we noticed is this:

So it seems to be packed using UPX (Ultimate Packer for Executables) version 4.02. The tool also flagged additional characteristics indicative of packing, including high entropy, section collisions, and compressed sections labeled as “UPX1”. This is a common tactic used by malware developers to obfuscate the executable’s true functionality and make analysis more challenging. 

Examining the Memory map feature, the sample reveals its section layout. The binary includes two primary sections: UPX1, which is typically associated with packed data, and .rsrc, which often contains resources like icons or metadata. Additionally, the overlay segment at the end hints at potential appended data, possibly configuration files or additional payloads. The presence of a valid MZ header confirms the binary format as a Windows executable. These observations further support the need to unpack the UPX-packed section to uncover the executable’s true content and functionality:

Taking a closer look at the entropy of the sample, it’s clear we’re dealing with a packed binary. The UPX1 section stands out with an entropy value of around 7.94, a classic sign of compression or obfuscation. This fits perfectly with the earlier detection of UPX packing. The .rsrc section and the overlay, on the other hand, show lower entropy, which is what we’d expect from uncompressed data and extra appended information. This tells me one thing: before we can dig into the real functionality of this malware, we’ll need to unpack that UPX1 section to see what’s really hiding underneath.

With the UPX packing confirmed, the next step was to unpack the binary to access its real content. Using the UPX tool, I first tested the sample to verify that it was indeed packed (just to be sure). As expected, the tool identified the file as packed with UPX 4.2.4. Following this, I executed the unpacking command (upx -d) and successfully unpacked the binary, reducing its compression ratio and producing an unpacked version named cactusunpack. Now that the binary is unpacked, we’re ready to dive deeper and analyze its underlying functionality.

After unpacking the binary, I loaded it into Detect It Easy (DIE) to verify the changes and analyze the new structure. The unpacked file is identified as a PE64 executable, with a file size of 8.67 MB and a timestamp indicating it was compiled on March 24, 2023. The binary is a 64-bit console application, targeting Windows Server 2003 (AMD64). The linker details suggest the use of GNU Binutils for compilation. These details give us the first real insight into the malware’s architecture and confirm that we’ve successfully stripped away the UPX packing layer, leaving us ready for deeper analysis.

Now that we have the unpacked binary’s imports, we get a clearer picture of the libraries the malware relies on for its functionality. Among the imported DLLs, we see critical Windows libraries like KERNEL32.DLL, ADVAPI32.DLL, and USER32.DLL, which suggest system-level operations and interaction with the Windows API. 

Networking-related imports such as WSOCK32.DLL and WS2_32.DLL indicate that this malware likely communicates over a network, possibly to send data or retrieve commands. Additionally, the presence of SHELL32.DLL and RstrtMgr.DLL could point toward file manipulation and potential recovery or restart management mechanisms. These imports provide strong hints about the capabilities of the ransomware, giving us leads for further investigation into its behavior.

Now, let’s take a look at some basic Strings:

If you search for “cipher” you will find some interesting algorithms involved, for example, we can see strings like chacha20_poly1305_tls_cipher and various DES cipher modes (des_cfb64_cipher, des_ofb_cipher, etc.). These suggest that the ransomware includes cryptographic functionality, likely for encrypting victim files or secure communication. The presence of ChaCha20, (which is a modern and efficient cipher often used in secure protocols), indicates that the malware might leverage advanced encryption schemes. These findings are crucial as they provide direct evidence of how the ransomware operates and might also help in developing potential decryption or mitigation strategies.

Diving into the strings of the binary, a few patterns quickly emerged that give us insight into how Cactus ransomware operates. The ransomware makes heavy use of the C:\ProgramData directory, a common location for malware to store temporary or operational files due to its accessibility and low visibility to users. Within this directory, the file ntuser.dat is referenced—likely not the legitimate system file, but a decoy name chosen to avoid drawing attention. Based on its context, it’s plausible that this file is used to store encryption keys or other critical data necessary for the malware’s functionality.

Another interesting find was the presence of the batch script rn.bat, which is likely responsible for renaming files during the encryption process. This aligns with typical ransomware behavior where filenames are altered to signal their encrypted status, adding further complexity for the victim to manually recover the data.

Similarly, the file update.log, also located in C:\ProgramData, appears to function as a log for the ransomware, potentially recording encrypted files, execution errors, or timestamps. This logging behavior suggests a level of sophistication in tracking the ransomware’s progress.

Adding to this, the strings revealed a ransom note with messages like Your systems were accessed and encrypted by Cactus and instructions to contact the attackers via email (cactus@mexicomail.com) or Tox chat (https://tox.chat/). These messages confirm the ransomware’s coercive strategy of data theft and encryption, combined with anonymous communication channels to negotiate payments while avoiding detection.

Finally, the references to the Tor browser are worth noting. This suggests that the ransomware leverages Tor for connecting with command-and-control servers or facilitating anonymous payment methods. By combining these elements—file manipulation, cryptography, logging, and anonymous communication—Cactus demonstrates a calculated and layered approach to ransomware deployment.

This seems like the perfect point to halt our advance. In the next installment, I’ll unsheathe my combat knife—codename Ghidra—and carve into this ransomware, exposing its guts to uncover more intel. We’ll thoroughly inspect its inner workings before launching into our dynamic analysis.

SmouK out!