At CYFIRMA, we are committed to delivering timely insights into emerging cyber threats and the evolving tactics of cybercriminals targeting individuals and organizations. This report provides a concise analysis of Yurei Ransomware, which is a sophisticated ransomware family designed to rapidly encrypt data, disable recovery options, and frustrate forensic investigation. It appends a “.Yurei” extension to encrypted files, deletes shadow copies and system backups, and erases event logs to block restoration and hinder response.
The malware spreads laterally via SMB shares, removable drives, and credential-based remote execution (PsExec/CIM). It uses per-file ChaCha20 encryption keys, each wrapped with the attacker’s embedded ECIES public key, making decryption without the operator’s cooperation infeasible.
CYFIRMA has observed a new Ransomware, “Yurei Ransomware” developed in Go language, whose samples are available in various malware databases. This ransomware is designed to target Windows systems, utilizing advanced encryption methods and adding a unique file extension to encrypted files.
| Target Technologies | Windows |
| Encrypted Files Extension | .Yurei |
| Ransom Note File | _README_Yurei.txt |
| Programming Language | Go |
Yurei stages its payload from temporary directories, deploys polished ransom notes with Tor-based contact channels, and executes secure deletion routines to erase artifacts. Taken together, these features point to a professional, double-extortion-ready operation optimized for speed, stealth, and irreversible impact.
Execution begins with the main routine running a loop that, once triggered, calls the function EncryptAllDrivesAndNetwork, responsible for encrypting all accessible drives and network shares before changing the victim’s desktop wallpaper using a PowerShell wrapper for the Windows SystemParametersInfo API. Following this, the desktop background is changed by calling the setWallpaper() function.
The disableBackups routine tries to turn off backup and recovery features, likely stopping backup services and deleting Volume Shadow Copies before calling getAllDrives to list all local and network drives for encryption.
The disableBackups() function removes recovery options by assembling PowerShell commands that invoke native Windows utilities to delete backups. Using PowerShell, it builds and executes commands such as vssadmin Delete Shadows /All /Quiet and wbadmin Delete Catalog -Quiet via os/exec.(*Cmd).Run, silently removing all Volume Shadow Copies and backup catalogs.
Since Go strings are represented as offset–length pairs rather than null-terminated text, static analysis often misses references. Deeper inspection of recovered strings shows it assembling a PowerShell command designed to purge Windows event and system logs from %SystemRoot%\System32\winevt\Logs and %SYSTEMROOT%\Logs. It leverages Get-ChildItem -Recurse piped to Remove-Item -Force, combined with -ErrorAction SilentlyContinue to suppress errors and ensure deletion, modifying file metadata by setting CreationTime (effectively manipulating timestamps). Together, these actions remove log evidence and obscure forensic timelines, which is a pattern strongly aligned with ransomware anti-forensic behavior.
The PowerShell fragment copies a staged payload from a temp file to multiple target locations using Copy-Item -Force, notably writing to $drive\svchost.exe and $drive\WindowsUpdate.exe (masquerading as legitimate service binaries) and to a network share as System_Backup.exe, then removes the temp file.
Clear-Host wipes the console history, then the GC sequence forces immediate collection of unreferenced managed objects; the subsequent 1 MB random overwrite obliterates their residual heap data, ensuring forensic tools recover only high-entropy garbage instead of cleartext commands, credentials, or share paths.
The selfDestruct function is intended to fully erase the malware after it runs. It sequentially calls secureDelete, cleanTraces, and wipeMemory, which removes persistence and significantly hinders forensic recovery or post-incident investigation.
The secureDelete routine destroys the ransomware binary to prevent recovery. It performs three overwrite passes using a 1 MiB buffer filled with cryptographically strong random bytes from crypto/rand.Read, writing each pass with os.WriteFile to obliterate the file contents. After overwriting, it renames the executable twice using randomly generated names and temporary paths.
Finally, the malware deletes its on-disk executable, calls os.Remove to remove the file, and runs cleanFileMetadata to scrub timestamps, MFT entries, and other file attributes. This cleanup is an anti-forensics measure meant to eliminate persistence and make recovery and attribution more difficult.
stealthPropagation infects removable media, leverages open network shares, and launches remote execution via PsExec. An infinite loop keeps these propagation attempts running nonstop until the process is stopped.
The script lists SMB shares and iterates over each share path. For writable shares that don’t already have the file, it copies itself into the share and writes the payload as System32_Backup.exe.
The executable iterates all removable drives with valid letters, checks for WindowsUpdate.exe at each root, and if absent, copies its own executable there as WindowsUpdate.exe, disguising propagation via USB under a familiar system-like filename, and increases infection success more silently.
The ransomware leverages a C# wrapper with P/Invoke to call user32.dll and execute SystemParametersInfo(20, 0, path, 3) to change the desktop wallpaper. Since the specified path refers only to a locally dropped file rather than an external source or URL, the outcome is a forced black desktop background, creating an immediate and highly visible effect.
It creates a per-file ChaCha20 key and nonce, wraps the key with ECIES via go_ecies, then writes a custom header to the target file containing the wrapped key and nonce, followed by the 0x7c7c (“||”) separator. That marker cleanly delimits the wrapped-key/nonce blob from the ciphertext, so the wrapped key is trivial to find during decryption. Finally, the file body is encrypted with ChaCha20 and appended.
The loop processes files in 2 MiB chunks (0x200000 bytes each), feeding each block into ChaCha20’s XORKeyStream to apply the keystream, then writing the encrypted output back. This chunked approach enables streaming encryption of large files without ever loading them fully into memory.
After processing, the code closes any open handles, deletes the temporary file used during encryption, and then renames the temp file to the original filename. That sequence releases locks, removes artifacts, and atomically moves the encrypted file into place to reduce recovery chances and forensic evidence.
The attacker’s public key is baked into the executable at Go build time (stored in the binary’s build metadata). The payload uses that embedded public key to wrap each file’s symmetric key, so only whoever holds the matching private key can unwrap and decrypt the files.
The loop creates a ransom note named _README_Yurei.txt, writes the ransom note into it, and places it alongside each encrypted file’s directory. This is the payload’s final step after encryption, ensuring that every affected directory contains the ransom instructions under a consistent filename.
When executed in the controlled environment, the sample drops a file named _README_Yurei.txt and displays a professionally written ransom notice addressed to management. The note asserts a full compromise and data exfiltration, claims backups and shadow copies have been destroyed, advertises payment incentives (such as a 24-hour test decryption), provides negotiation instructions, and explicitly warns victims against attempting recovery or involving third parties. Its authoritative tone and double-extortion demands are intended to coerce rapid payment.
Ransom notes include a Tor .onion chat link (GUID path), a Ticket ID, a blog .onion, and a hex-like YureiSupp token. Those artifacts let the operators correlate victims by ticket and conduct talks over Tor, implying both ransom demands and a threat to leak stolen data.
Temp directory contents show multiple staged payloads and transient artifacts in %LOCALAPPDATA%\Temp, including several exe files. This indicates the ransomware stages copies of its binary in Temp, and creates temp containers for PowerShell scripts (*.ps1).
The dropped script constructs a PSCredential object from the supplied username and password, opens a CIM session, and copies the local file’s raw bytes to the remote host. It then invokes a remote process whose command line writes the payload to disk and executes it. After execution, the script closes the CIM session. In effect, this implements credential-based lateral execution (PsExec-style).
All encrypted files were renamed by appending the ransomware extension .Yurei to the original filename.
Each encrypted file starts with a header that contains an asymmetrically encrypted ChaCha20 key, immediately followed by the encrypted nonce. A fixed delimiter (0x7c7c, ASCII “||”) separates this header from the ciphertext. This layout gives each file a unique key/nonce pair while enabling the attacker’s decryptor to reliably parse and recover the values required for decryption.
During execution, the sample launches multiple PowerShell commands to delete shadow copies and backup catalogs (vssadmin Delete Shadows /All /Quiet, wbadmin Delete Catalog -Quiet) and recursively removes event and log files, demonstrating active anti-recovery and anti-forensics measures. Simultaneously, it stages and drops payloads to local Temp and root directories and attempts credential-based lateral movement using net use, CIM sessions, and PsExec-style remote execution, including repeated net use \\<ip>\IPC$ attempts with different credentials. This combination of backup destruction, log wiping, payload deployment, and network propagation reflects a coordinated kill-chain aimed at maximizing impact while hindering remediation and forensic investigation.
Yurei Ransomware was first identified on September 5, 2025, with its initial reported victim being a food manufacturing company in Sri Lanka.
While “Yūrei” (幽霊) is a Japanese word meaning “ghost” or “spirit,” this alone does not provide enough evidence to conclude that the developer of the Yurei ransomware is from Japan.
The first Yurei Ransomware sample was submitted to a malware database on September 7, 2025, originating from Morocco, and was later reuploaded from Germany and Turkey. However, these submissions alone do not confirm that the developer is based from these countries.
The executable’s compile-time metadata reveals a Windows username (intellocker) on the C: drive and a path on D: (D:\satanlockv2), suggesting potential ties to other known ransomware groups. The presence of these embedded paths and usernames in the binary indicates a possible connection between the Yurei ransomware build and a SatanLockerV2 development environment.
Blog Link (Currently not accessible):
http[://fewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd[.onion
Chat Link (Currently not accessible):
http[://fewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd[.onion/chat/777676f8-2313-425f-873a-65c4df8d5def/chat[.php
Analysis of the Yurei ransomware reveals a possible significant degree of source code reuse from the open-source Prince-Ransomware project. The link is established through symbol retention, matching cryptographic schemes, structural similarities in file handling, and inherited behavioral quirks.
Key overlaps:
Yurei Ransomware is a highly sophisticated malware family leveraging advanced encryption (ChaCha20 + ECIES), per-file keys, and professionalized ransom notes. Its propagation methods, including SMB shares, removable drives, and credential-based execution, enable rapid lateral spread across networks. Anti-forensics routines such as log wiping, secure deletion, and memory cleansing hinder recovery and forensic analysis. The ransomware’s double-extortion capabilities increase pressure on victims, threatening data leaks in addition to ransom demands. Analysis indicates possible code reuse from the Prince ransomware, with minor modifications and inherited flaws. Overall, Yurei represents a professional, high-impact threat designed for stealth, speed, and irreversible data compromise.
| Indicator | Type | Remarks |
| 1263280c916464c2aa755a81b0f947e769c8a735a74a172157257fca340e1cf4 | Sha256 | 3dec9093b6da575c8700a9eb.ps1 |
| 4f88d3977a24fb160fc3ba69821287a197ae9b04493d705dc2fe939442ba6461 | Sha256 | YureiRansomware.exe |
| hXXp[:]//fewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd[.]onion | URL | BLOG LINK |
| hXXp[:]//fewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd[.]onion/chat/777676f8-2313-425f-873a-65c4df8d5def/chat[.]php | URL | CHAT LINK |
| Tactic | Technique ID | Technique |
| Execution | T1047 | Windows Management Instrumentation |
| Execution | T1059 | Command and Scripting Interpreter |
| Execution | T1106 | Native API |
| Execution | T1129 | Shared Modules / Get kernel32 base address / PEB access |
| Persistence | T1543 | Create or Modify System Process |
| Persistence | T1543.003 | Windows Service |
| Defense Evasion | T1006 | Direct Volume Access (searches for available drives) |
| Defense Evasion | T1027 | Obfuscated Files or Information (packing, encryption/encoding) |
| Defense Evasion | T1027.002 | Software Packing |
| Defense Evasion | T1036 | Masquerading (creates files in user directories) |
| Defense Evasion | T1045 | Software Packing (local sandbox packer harvesting — unknown) |
| Defense Evasion | T1064 | Scripting (use of PowerShell utilities) |
| Defense Evasion | T1070 | Indicator Removal (clears Windows events/logs) |
| Defense Evasion | T1070.004 | File Deletion (deletes shadow copies / vssadmin, wbadmin) |
| Defense Evasion | T1070.006 | Timestomp (yara indicators triggered) |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information (AES via x86 extensions) |
| Defense Evasion | T1202 | Indirect Command Execution (uses suspicious Windows utilities) |
| Defense Evasion | T1562 | Impair Defenses (attempts to stop active services) |
| Defense Evasion | T1562.001 | Disable or Modify Tools (attempts to stop active services) |
| Defense Evasion | T1564 | Hide Artifacts (uses ADS / alternate data streams) |
| Defense Evasion | T1564.003 | Hidden Window (creates process with hidden window) |
| Defense Evasion | T1564.004 | NTFS File Attributes (interacts with ADS) |
| Credential Access | T1003 | OS Credential Dumping |
| Credential Access | T1552 | Unsecured Credentials (harvests mail client data) |
| Credential Access | T1552.001 | Credentials in Files (Outlook .pst exfiltration) |
| Discovery | T1012 | Query Registry (MachineGuid, fingerprinting) |
| Discovery | T1016 | System Network Configuration Discovery (reads network adapter info) |
| Discovery | T1057 | Process Discovery (queries list of running processes) |
| Discovery | T1082 | System Information Discovery (memory, volume info) |
| Discovery | T1497 | Virtualization/Sandbox Evasion (process count anomaly) |
| Collection | T1005 | Data from Local System (harvests Outlook .pst) |
| Collection | T1074 | Data Staged (manipulates recycle bin / staging) |
| Collection | T1114 | Email Collection |
| Command & Control | T1071 | Application Layer Protocol (suspicious network indicators) |
| Command & Control | T1090 | Proxy (Tor onion address observed) |
| Impact | T1485 | Data Destruction (clears Windows events/logs; anomalous deletions) |
| Impact | T1486 | Data Encrypted for Impact (modifies/renames user files; .yurei extension) |
| Impact | T1489 | Service Stop (attempts to stop active services) |
| Impact | T1490 | Inhibit System Recovery (deletes volume shadow copies / disables backups) |
import “hash”
rule YUREI_RANSOMWARE
{
meta:
author = “Cyfirma Research Team”
description = “Detects Yurei ransomware samples using SHA256 hashes or associated strings/IOCs”
date = “2025-09-26”
strings:
$exe_name = “YureiRansomware.exe” nocase
$ps1_fragment = “3dec9093b6da575c8700a9eb.ps1” ascii nocase
$onion_domain = /\bfewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd\.onion\b/i
$onion_chat = /\bfewcriet5rhoy66k6c4cyvb2pqrblxtx4mekj3s5l4jjt4t4kn4vheyd\.onion\/chat\/[0-9a-fA-F-]{8,48}\/chat\.php\b/i
$nonce_like = “ENCRYPTED_KEY || NONCE || CIPHERTEXT” ascii nocase
condition:
// Hash-based detection (high confidence)
hash.sha256(0, filesize) == “1263280c916464c2aa755a81b0f947e769c8a735a74a172157257fca340e1cf4” or
hash.sha256(0, filesize) == “4f88d3977a24fb160fc3ba69821287a197ae9b04493d705dc2fe939442ba6461” or
// String / IOC-based detection (broader coverage)
any of ($exe_name, $ps1_fragment, $onion_domain, $onion_chat, $nonce_like)
}
Strategic
Tactical
Operational
Technical
