An Unerring Spear: Cephalus Ransomware Analysis
Cephalus is a new ransomware group that first appeared in mid-June 2025. The group claims that they are motivated 100% by financial gain. Their main method of breaching organizations is by stealing credentials through Remote Desktop Protocol (RDP) accounts that do not have multi-factor authentication (MFA) enabled. Their operation is unique in that they have a form of customized ransomware that targets specific organizations, breaches them, exfiltrates their data, and then encrypts it. As of now, it is not yet known if they operate as Ransomware as a Service (RaaS) or if they have formed alliances with other ransomware groups. The name of the group comes from Cephalus, a character in Greek mythology who received an “unerring” spear from Artemis. This is seen as a sign of the group’s confidence in their success rate.
There is currently no information available on the rebranding history of the group or their clear and direct connection with other ransomware groups. There is also no information available on the existence of new strains or subgroups. Upon breaching the system, the group openly states their presence and previous cases of damage in their ransom notes to pressure the victims. They also use tactics such as proving the data breach by providing a link to a GoFile repository.
Figure 1. Cephalus leak site (DLS)
Analysis
Cephalus is a ransomware strain developed in Go. It disrupts dynamic analysis by generating a fake AES key. Upon execution, it disables Windows Defender’s real-time protection, deletes VSS backups, and stops key services such as Veeam and MSSQL to increase its encryption success rate and decrease the chances of recovery. Cephalus uses a single AES-CTR key for encryption, and this key is managed to minimize exposure on the disk and in memory. Finally, the AES key is encrypted using an embedded RSA public key, ensuring that only threat actors with the corresponding RSA private key can decrypt the key.
Initial Routine
Generating Fake AES Key
Cephalus has a feature that aims to disrupt analysis and conceal the AES key that will be used for encryption. When the ransomware is executed, it generates a 1,024-byte random buffer using crypto_rand.Read(). It then overwrites this buffer with a 32-byte string that reads “FAKE_AES_KEY_FOR_CONFUSION_ONLY!”—a process that is repeated 100 times. This means that dynamic analysis tools and systems will perform multiple memory accesses to a 32-byte key, making it appear as if the string is the actual AES key.
Figure 2. Process of generating a fake AES key
Encrypting Files
The AES-CTR symmetric key encryption algorithm is used to encrypt files. The key is generated by applying the SHA-256 function 10,000 times to a random 32-byte value created by crypto/rand.Read(). A different key is not generated for each file; instead, a single AES-CTR key is used to encrypt all files. Therefore, if an attacker can obtain the AES-CTR key, they can decrypt all encrypted files. This makes it crucial for the key to remain undisclosed. To prevent key exposure, the threat actor implemented a SecureMemory structure and related methods to manage the key’s storage, use, and disposal.
Figure 3. SecureMemory structure and related methods
The following are the features implemented to minimize key exposure.
Paging Prevention – SecureMemory.LockMemory()/UnlockMemory()
For memory efficiency, the Windows operating system internally performs a page-out operation that moves memory pages that are not referenced for a long time or when there is a shortage of available space to an area on the disk. This process poses a risk of exposing the encryption key because the key is written in plaintext on the disk file (page file). Cephalus ransomware uses the LockMemory() method to prevent this. This method internally calls VirtualLock, a Windows API, to exclude the encryption key from being a target of the page-out operation. This prevents the key from being exposed on the disk.
Key Saving/Restoring with XOR – SecureMemory.SetData()/GetData()
Cephalus is designed to prevent not only the encryption key from being left on the disk through page-out, but also to prevent key exposure in memory. The SetData()/GetData() methods are used to access the key. The SetData() method, which stores the key, does not store the encryption key as it is. Instead, it generates a random XOR key and performs an XOR operation once before storing it. As a result, in a typical memory dump scenario, only the AES key in a masked state after the XOR operation exists. In the following Figure 4, it can be seen that the AES key starting with 0xD4 and the XOR key starting with 0xF0 are being XORed.
Figure 4. The process of XORing the original key
When the original AES key is needed to encrypt the file later on, the GetData() method restores the key using the same XOR key that was used during the encryption process. Because this process minimizes the exposure of the original key in the memory, the situation when GetData() is called is the best time to obtain the key from a forensic and recovery perspective.
Ransom Note
The following figure shows the screen after the Cephalus ransomware has been executed. The desktop background remains unchanged. The ransom note is named ‘recover.txt’ and is created in all directories where encryption has been completed.
Figure 5. After encryption
Ahnlabs’ Response Status
The detection name and engine date information of the AhnLab product group are as follows.
V3
Ransom/MDP.Behavior.M2813 (2021.10.08.00)
Ransom/MDP.Decoy.M1171 (2024.09.06.02)
Ransom/MDP.Event.M1785 (2024.08.20.03)
Ransomware/Win.Cephalus.C5792414 (2025.08.27.04)
Ransomware/Win.Cephalus.C5792774 (2025.08.28.02)
EDR
SystemManipulation/EDR.Event.M2486 (2024.04.22.03)
