First observed in September 2025, Yurei is a ransomware group that leverages double extortion tactics – encrypting victims’ files while also stealing sensitive data – then demands payment to decrypt files and prevent the release of stolen information.
While double extortion is not a novel approach to ransomware, it poses a significant challenge to organizations, especially since Yurei maintains a darknet leak site to add pressure for its victims. Yurei’s technical and operational strategy and use of open-source software enables it to deploy and proliferate in an environment rapidly, creating a perfect storm of challenges for security teams.
In this article, we’ll break down how Yurei orchestrates and executes an attack, and what organizations can do to defend against this emerging adversary.
You are reading an excerpt of a Cyber Threat Intelligence (CTI) Report, delivered monthly by CyOps to Cynet partners and All-in-One customers. Download the full CTI report.
Introduction to Yurei Ransomware Group
Yurei is a sophisticated Go-based ransomware that leverages legitimate open-source cryptographic libraries from GitHub to create a hybrid encryption system using ECIES, ChaCha20, and AES algorithms. The malware performs comprehensive reconnaissance through A-Z drive enumeration and network share discovery, enabling simultaneous encryption across multiple systems from a single infection point.
The ransomware uses selective file targeting with extension-based filtering to maximize damage while avoiding system-critical files. It ensures immediate user awareness by dropping ransom notes in encrypted directories and changing desktop wallpaper to display payment instructions. Built for cross-platform compatibility and concurrent operations, Yurei employs atomic file operations and PowerShell integration for secure encryption and system modification. This malware represents a significant organizational threat due to its network traversal capabilities and use of proven encryption libraries that make files unrecoverable without ransom payment, enabling enterprise-wide impact from a single compromise.
Static Analysis
By performing a static analysis of this file and its strings, we can better understand Yurei’s functionality and capabilities.
The ransomware exemplifies how cybercriminals exploit legitimate open-source cryptographic libraries from GitHub to build sophisticated malware. The dependencies like github.com/ecies/[email protected] and github.com/fomichev/secp256k1 are all legitimate encryption tools used in secure applications worldwide. Rather than writing their own code from scratch, the attackers downloaded these established libraries and weaponized them, combining multiple legitimate tools to create a hybrid encryption system. The hardcoded ECIES public key works with these libraries to ensure only the ransom writer possesses the private key needed for decryption, making file recovery impossible without paying the ransom even if victims reverse-engineer the entire malware.
This malware was developed using Go (Golang). Go’s advantages include fast compilation, cross-platform compatibility, and strong support for concurrent operations, making it ideal for creating ransomware that can rapidly encrypt files across multiple systems and network shares simultaneously.
The following strings offer clues about configuration:
- Yurei/configuration.init shows the malware’s configuration package starting up when the program runs.
- configuration/configuration.go points to the main configuration source file used to manage settings.
- PublicKey=04103dd31870f099a6e02bff… is a built-in EC key likely used for encrypting or securing communications.
- internal/godebug.New and internal/godebug.Value are Go runtime functions that handle feature flags and config toggles at runtime.
The following strings shed light on encryption functions and stream cipher operations:
- EncryptFile() shows the main function the malware uses to encrypt files.
- generateKey() and generateNonce() create the keys and nonces needed for cryptographic operations.
- golang.org/x/crypto/chacha20.NewUnauthenticatedCipher indicates the malware can use the ChaCha20 stream cipher.
- crypto/aes.NewCipher shows it can also use AES for block cipher encryption.
- github.com/ecies/go.Encrypt points to ECIES, a hybrid encryption scheme combining asymmetric and symmetric cryptography.
- XORKeyStream is a function call that confirms stream cipher operations are taking place.
The malware leverages path/filepath.Ext and strings.HasSuffix to identify files by extension, enabling selective targeting of user data. The presence of Yurei/encryption.isExcluded indicates built-in exclusion logic, likely to avoid system-critical files. Use of os.Create confirms that new files are generated during execution, consistent with creating encrypted versions of victim files or ransom notes. These strings collectively point to a structured ransomware workflow focused on controlled, selective encryption.
The presence of internal/filepathlite.IsAbs, path/filepath.Base, and path/filepath.Clean shows that the malware normalizes and validates file paths, ensuring it can handle both absolute and relative paths consistently. Combined with strings.HasPrefix and strings.HasSuffix, the malware is able to check for specific filename patterns or extensions. This indicates a deliberate mechanism for filtering and controlling which files are processed.
The following strings indicate that Yurei scans networks for files to encrypt, in addition to local drives.
- The strings syscall.WSAEnumProtocols and syscall.WSAStartup indicate initialization of Windows socket APIs, suggesting that the malware is capable of interacting with network resources.
- The repeated references to Yurei/filewalker.EncryptAllDrivesAndNetwork and Yurei/filewalker.getNetworkRoots demonstrate that the malware is designed to enumerate and encrypt not only local drives but also network shares.
- The presence of Yurei/filewalker.monitorNetworkShares further highlights functionality for actively scanning shared resources, ensuring they are also targeted.
- Functions such as EncryptDirectory and associated wrappers confirm recursive directory encryption across these locations.
The presence of main.setWallpaper indicates that the malware is capable of modifying the victim’s desktop background. This behavior is commonly used by ransomware to replace the existing wallpaper with a ransom note, ensuring that the victim is immediately confronted with payment instructions after encryption has taken place.
The presence of syscall.ReadFile, syscall.WriteFile, os.OpenFile, and io.Copy shows that the malware is equipped to perform low-level file input/output operations. These functions enable it to open existing files, read their contents, and overwrite or replace them with modified data. In a ransomware context, this behavior is consistent with reading original victim files and writing back encrypted versions, effectively replacing accessible data with locked content.
Dynamic Analysis
By executing Yurei in a controlled environment, we can map the ransomware’s attack sequence and identify indicators of compromise.
During dynamic execution, the sample repeatedly invoked kernel32.CreateFileW on root paths of all drive letters (pattern X:\, e.g., G:\, H:\, I:\). This indicates a full A:–Z: sweep to identify existing and writable volumes prior to directory traversal and encryption. The behavior aligns with the getAllDrives() / EncryptAllDrivesAndNetwork() staging observed in static analysis. If any letters resolve to mapped network drives (DRIVE_REMOTE), these calls also function as pre-lateral-encryption reconnaissance, typically followed by GetDriveTypeW to classify volumes and FindFirstFileW/FindNextFileW to enumerate targets before encryption begins.
While paused on kernel32.CreateFileW, the path in RCX was L”C:\_README_Yurei.txt”, evidencing creation of the ransom note in the system drive root. This event occurred immediately after the drive-letter sweep, marking the transition from reconnaissance to user-facing impact. Additional strings visible in memory (e.g., L”inetpub”) indicate the sample may also stage notes in prominent directories (such as IIS paths) for visibility, while L”a:” reflects the ongoing A:–Z: enumeration context.
The file remains 0 KB, indicating no data has been written to it.
Following the zero-byte creation of C:\_README_Yurei.txt, the process invoked kernel32.WriteFile on the same handle with a valid buffer and a non-zero byte count, confirming that the ransom note content was being written.
The malware drops ransom notes in each directory where it initiates encryption; as expected, its first writes hit Cynet’s ransomware-protection decoy files, triggering the protection mechanism.
While paused at kernel32.MoveFileExW, the call referenced C:\! Cynet Ransom Protection (DON’T DELETE)\l2.docx and C:\! Cynet Ransom Protection (DON’T DELETE)\l2.docx.enc, showing a rename/swap between the original decoy and its encrypted counterpart. This is the encryption commit step typical of ransomware after writing the encrypted data, it atomically moves/renames the file to the .enc extension and it confirms the sample is acting on Cynet’s ransomware-protection decoys as intended.
After the encryption phase completes and ransom notes are created, the malware launches PowerShell to inline-compile a small C# helper (via csc.exe and cvtres.exe) and calls user32.SystemParametersInfo to set C:\Users\user\AppData\Local\Temp\Wallpaper.png as the desktop background. This powershell.exe → csc.exe → cvtres.exe sequence occurs at the end of execution as part of the ransom UX, broadcasting the change only after files have been encrypted.
MITRE ATT&CK Tactics and Techniques
Cynet vs Yurei
Note: Cynet can detect and prevent this malware using multiple mechanisms. During this simulated execution, Cynet’s Cybersecurity Platform is configured in detection mode (without prevention) to allow Yurei ransomware to execute its full flow. This lets Cynet detect and log each step of the attack.
Yurei is blocked by three layered detections within the All-in-One Cybersecurity Platform:
- File Dumped on the Disk
Cynet’s AV/AI engine detects that malicious files were dumped on the disk or are attempting to run:
- Threat Intelligence Detection Malicious Binary
In addition to Cynet’s AV mechanism, Cynet also utilizes 3rd party cyber threat intelligence data to detect the presence of suspicious and malicious files: - Unauthorized File Operation Attempt
This mechanism detects and reports on attempts to create suspected encrypted files, the modification of Cynet’s Ransomware decoy files, and the creation of possible ransom notes:
Conclusion
Security teams should review ransomware prevention best practices and incident response strategies in the wake of attacks that leverage low barrier-to-entry open-source code. Robust backups, regular patching, strong implementation of multifactor authentication policies, and enforced software updates help create a strong defensive posture against Yurei and other emerging threats.
Cynet helps organizations defend against ransomware like Yurei by providing an AI-powered platform that detects and stops threats across endpoints, networks, and users before they can encrypt or exfiltrate data. Our 24×7 CyOps MDR service and built-in response automation enable rapid containment, ensuring attacks are neutralized without requiring additional tools or manual intervention.
