Analysis of Encryption Structure of Yurei Ransomware Go-based Builder

Analysis of Encryption Structure of Yurei Ransomware Go-based Builder

The Yurei ransomware group is a new group that was first publicly identified in early September 2025. This group adopts a typical ransomware operation model that infiltrates corporate networks, encrypts data, deletes backups, and then demands a ransom for the stolen information. While there is no clear evidence of their involvement in Ransomware as a Service (RaaS) or collaboration with other groups, there have been no reports of rebranding or modification of existing ransomware groups. Contact with victims is made through their dedicated dark web site.

 

The known countries that have suffered from the attacks are Sri Lanka and Nigeria, and the main industries targeted are transportation and logistics, IT software, marketing and advertising, and food and beverage. While it is known that the ransom demand for recovery is calculated on a case-by-case basis after assessing the financial status of the victim company, the specific range of the amount demanded has not been disclosed.

 


Figure 1. Yurei ransomware DLS site

 

 

Analysis

Yurei is a ransomware strain developed in Go. It performs an encryption preparation routine without any special initial routines, such as changing permissions, setting argument values, creating mutexes, or decrypting strings, typically found in other ransomware strains. It uses the ChaCha20-Poly1305 algorithm for file encryption and generates a 32-byte key and a 24-byte nonce as random values. It then encrypts these generated key and nonce values using the embedded public key in the secp256k1-ECIES method and stores them inside the encrypted file. This design ensures that only the threat actor with the corresponding secp256k1-ECIES private key can decrypt the file.

 

Encryption Preparation

 

Yurei performs an encryption preparation routine without any special initial routines found in other ransomware strains, such as changing permissions, setting argument values, creating mutexes, or decrypting strings. It begins a routine to obtain the drive information of the current execution environment and traverse all drive paths to find encryption targets.

 


Figure 2. Routine that obtains drive information of the current execution environment

 

To prevent the system from being destroyed by encrypting key files, the following directories, extensions, and files are excluded from encryption. For the excluded extensions and files, Yurei has specified the encryption infected extensions used in the Yurei ransomware, such as “.Yurei” and “_README_Yurei.txt”, as encryption exclusion targets to prevent re-encrypting files that have already been encrypted. The name of the ransom note is also specified as an exclusion target, so that victims can check the ransom note and proceed with negotiations.

 

Directories excluded from encryption

windows, system32, programdata, program files, program files (x86), public, system volume information, \system volume information, efi, boot, perflogs, microsoft, intel, appdata, .dotnet, .gradle, .nuget, .vscode, msys64

Table 1. Directories excluded from encryption (19)

 

Extensions of files excluded from encryption

.sys, .exe, .dll, .com, .scr, .bat, .vbs, .ps1, .lnk, .inf, .reg, .msi, .ini, .Yurei

Table 2. File extensions of files excluded from encryption (14 types)

 

Files excluded from encryption

boot, bootmgr, bcd, desktop, config, autoexec, _README_Yurei.txt

Table 3. Files excluded from encryption (7 types)

 

File Encryption

 

Once the files to be encrypted are finalized, the file encryption routine is executed. At this point, the Yurei ransomware generates the 32-byte key and 24-byte nonce of the ChaCha20-Poly1305 algorithm to be used in file encryption. The generated key and nonce are then encrypted using the secp256k1-ECIES method and stored inside the encrypted file.

 

The secp256k1-ECIES method used by the Yurei ransomware operates as shown in Figure 3. It utilizes the public key inside the ransomware and the generated temporary private key to create a shared secret using the Elliptic Curve Diffie-Hellman (ECDH) algorithm. This shared secret is then transformed into a key to be used in encryption through a key derivation function, ultimately serving as the key for the AES-GCM algorithm. During this process, a randomly generated temporary nonce value is also used, ensuring that the encryption results are different each time. This encryption method is designed to prevent the threat actor from directly exposing the key used in encryption by protecting it with the ECDH and AES-GCM methods. It also ensures that a different temporary key is used each time to prevent the threat actor from monopolizing the decryption key, thereby making it impossible for the victim to recover their data without making a payment.

 


Figure 3. Operating principle of secp256k1-ECIES

 

As mentioned earlier, the file is encrypted using the ChaCha20-Poly1305 algorithm, and it is processed in 64 KB block units. Before writing the encrypted data, the 32-byte key and 24-byte nonce encrypted with secp256k1-ECIES are written as shown in Figure 4, with the “||” marker used as a delimiter. The encrypted data is then written sequentially after this.

 


Figure 4. Structure of the encrypted file

 

Ransom Note

 

The ransom note claims to have breached the company’s internal infrastructure and deleted all accessible backups. It also threatens to leak a massive amount of data and warns that both the victim’s own recovery attempts and external recovery services may cause data corruption and permanent loss. The note also threatens to delete the decryption key and expose or sell the stolen data on the dark web and inform regulatory bodies and competitors if the victim delays negotiations or fails to respond within five days. The note also includes a threatening message that emphasizes the fact that the threat actor has stolen key data, such as databases, financial documents, legal records, and personal information.

 


Figure 5. Ransom note (_README_Yurei.txt)

 

AhnLab Response Status

 

The following are the detection name and engine date of AhnLab products.

 

V3

Ransom/MDP.Event.M1785 (2017.11.23.00)

Ransom/MDP.Decoy.M1171 (2016.07.14.02)

Ransom/MDP.Event.M1875 (2018.03.10.01)

Ransomware/Win.YureiCrypt.R721068 (2025.09.08.03)

Ransomware/Win.YureiCrypt.R721188 (2025.09.08.03)

Ransomware/Win.PrinceRansom.R722378 (2025.09.10.01)

Ransomware/Win.PrinceRansom.C5753655 (2025.04.17.02)

Ransomware/Win.PrinceRansom.C5682303 (2024.10.14.02)

Ransomware/Win.PrinceRansom.C5738216 (2025.03.09.01)

Ransomware/Win.PrinceRansom.C5709845 (2024.12.24.03)

Ransomware/Win.PrinceRansom.C5685012 (2024.10.21.03)

Ransomware/Win.PrinceRansom.C5682303 (2024.10.14.02)

Ransomware/Win.PrinceRansom.C5685192 (2024.10.21.03)
 

EDR

Ransom/EDR.Decoy.M2470 (2022.09.29.03)
Ransom/EDR.Event.M1946 (2018.09.07.03)

 

MD5

1263ffe930e8ccde5bc62b043a5b6bd8
1f9700295e592ce3ea40b282e91597a2
24b4a69e3220b4e52e7c14f71e0f8dd6
32d489eef7cbbdf51dc41d07648d7d8f
331f9e123696007a9b2cc962dfb86d12