Inside Gunra RaaS: From Affiliate Recruitment on the Dark Web to Full Technical Dissection of their Locker

Executive Summary

On January 15th, 2026, CloudSEK researchers detected the new affiliation program related to Gunra. Gunra is a Ransomware-as-a-Service (RaaS) that was first seen active in May 2025, but the affiliation program was newly launched on a Dark Web forum in January 2026.

Leveraging strategic Human Intelligence (HUMINT) operations, the research team successfully infiltrated Gunra's affiliate program. This allowed researchers to obtain the RaaS panel credentials and a live ransomware sample for comprehensive technical dissection.

Gunra is a sophisticated ransomware operation primarily targeting Windows systems. It features a fully-featured affiliate management panel, configurable attack parameters, and advanced encryption capabilities. The malware uses strong cryptographic algorithms and selectively encrypts files, employing intelligent path exclusions to maximize damage while ensuring the system remains operational for the ransom payment process.

Gunra Group: A Professional Ransomware-as-a-Service (RaaS) Operation

The Gunra Group runs a sophisticated Ransomware-as-a-Service (RaaS) business model, utilizing an extensive affiliate program. Their operation is designed to attract financially motivated cybercriminals seeking ready-made ransomware tools.

Key Operational Details:

• Operator: Gunra Group
• Business Model: RaaS with a comprehensive affiliate program
• Target Audience: Cybercriminals looking for accessible ransomware solutions

The group significantly lowers the barrier to entry for less-sophisticated threat actors by offering comprehensive affiliate support. This support includes detailed documentation, a user-friendly management panel, and customizable ransomware builders, facilitating the execution of ransomware attacks.

‍Geographic and Activity Overview

To fully appreciate the scope of the Gunra Group's operations, it is crucial to analyze both its global reach and its recent activity trends.

Global Victim Distribution

The following map illustrates the worldwide distribution of victims targeted by Gunra Group affiliates. This visual highlights the primary regions of focus and the broad international impact of the RaaS operation.

‍

‍

Operational Activity Timeline (May 2025 - January 2026)

The chart below provides a snapshot of the Gunra Group's operational tempo over the past nine months. Analyzing the frequency and type of their activities - including new affiliate recruitment, successful ransomware deployments, and communication frequency on the dark web - is essential for understanding their current growth trajectory and peak activity periods.

‍

Initial Discovery and Threat Actor Engagement

Our analysis began with an advertisement on the Dark Web's Ramp Forum, where CloudSEK researchers identified a Ransomware-as-a-Service (RaaS) affiliate program. The post highlighted key features of the offering:

• Cross-Platform Support: The ransomware targets Windows, Linux, ESXi, and NAS environments across multiple architectures, including x86 and ARM.
• High-Speed Encryption: It uses a combination of ChaCha20 and RSA-4096 encryption algorithms. The ad highlights "step-skip" options to further increase encryption speed.
• Ready-to-Use: Affiliates can generate a "locker" (the encryption executable) immediately from a provided management panel. 

‍

HUMINT Operation

A targeted Human Intelligence (HUMINT) operation was launched to engage the threat actor through the provided Tox ID. Utilizing careful social engineering to establish credibility within the cybercriminal community, our researchers achieved the following:

1. Trust Establishment: Successfully engaged in detailed discussions regarding the affiliate program's prerequisites.
2. Documentation Acquisition: Secured a PDF guide outlining the complete affiliate program structure.
3. Access Gained: Obtained legitimate credentials to the RaaS management panel.

‍

‍

‍

Understanding the Threat

This professional-grade ransomware variant employs a sophisticated hybrid encryption system designed to maximize impact. Upon execution, the malware efficiently encrypts files across all accessible drives by initializing its worker threads and identifying target files based on internal exclusion lists.

The encryption process relies on a robust architecture:

1. Fast File Encryption: The ChaCha20 stream cipher is used to encrypt file data quickly.
2. Unique Key Generation: For each file, the malware generates a unique, random 32-byte ChaCha20 key and 12-byte nonce.
3. Key Protection: The ChaCha20 key material is then protected using RSA-4096 public key encryption.
4. Key Storage: This encrypted key bundle is either appended to the encrypted file or stored in a separate keystore.

This methodology renders file recovery cryptographically infeasible without the attackers' corresponding RSA private key.

The malware is designed for stealth and reliability, operating entirely offline during the encryption phase. All necessary components - including the RSA-4096 public key, exclusion lists for directories and file extensions, and a pre-written ransom note with a Tor hidden service address - are embedded within the binary. This offline approach bypasses network-based detection systems and ensures functionality even in isolated or highly secure environments.

High-Level Execution Flow

Technical Analysis - Execution Flow

Stage 1: Loading the Arsenal - Initialization & Setup

Upon execution, the ransomware binary is loaded by the Windows loader, and control transfers to the start function (0x1400014b0). This function first establishes the runtime environment before calling the main configuration routine at 0x1400015F1, where the malware prepares for its attack.

The configuration phase loads the embedded, PEM-formatted RSA-4096 public key. This key is central to the hybrid encryption model: while the ChaCha20 algorithm encrypts the victim's files, the RSA key is used to protect the ChaCha20 keys themselves. This ensures that only attackers possessing the corresponding private key can decrypt the data.

During configuration, the malware also defines its operational scope:

• It establishes a comprehensive target list of all drive letters (A through Z).
• It sets exclusion lists to prevent encrypting essential system directories, specifically C:\\Windows and C:\\Program Files.
• It implements file extension filters to avoid encrypting system files and executables.

Finally, the preparation phase concludes with the initialization of a two-worker thread pool and the preparation of the BCryptGenRandom interface, which is essential for generating the cryptographically secure random keys and nonces required for the encryption process.

‍

Stage 2: Mapping the Territory - File System Reconnaissance

Once configured, the ransomware initiates its file-hunting process using the ##0x140002369## function, a recursive directory walker. This function systematically scans the victim's storage, starting from drive A and proceeding through Z, attempting to access each drive and traverse its directory tree.

The malware employs a filtering logic as it discovers files and folders. It skips system directories, such as ##(C:\\Windows, C:\\Program Files, C:\\Program Files (x86))##, to avoid wasting time on non-critical files that won't compel a victim to pay. For files that pass this directory exclusion, the malware checks their extensions against a second exclusion list containing system-critical types like (##.exe, .dll, and .sys##). Files with user data extensions (e.g., documents, databases, images, archives) are approved and added to a centralized work queue for the encryption threads to process.

‍

‍

Stage 3: The Cryptographic Core - Hybrid Encryption Engine

To make sure no two files are the same (and to make recovery a total nightmare), the ransomware cooks up new crypto stuff for every single file using standard Windows BCrypt APIs. Specifically, ##sub\\_140005320## calls BCryptGenRandom (##0x1400070F0##) to create a unique 32-byte (256-bit) ChaCha20 key and a 12-byte (96-bit) nonce for each file.

The actual file scrambling is done by function ##0x140003765##, which uses the ChaCha20 stream cipher. We confirmed this because we spotted the classic ChaCha20 magic constants, the "expand 32-byte k," at addresses ##0x140003776 and 0x140003794##. For speed, it processes files in 1MB chunks. The heavy lifting for the ChaCha20 mixing happens in the quarter-round function ##0x140003710##, which includes the signature rotate-left (ROL) moves at bit counts 16, 12, 8, and 7. It runs for 20 rounds, exactly as the ChaCha20 spec calls for (10 loop iterations with 2 round-pairs), finishing up with the final XOR to turn the plaintext into ciphertext using the keystream.

After ChaCha20 does its job on the file data, the ransomware protects the keys themselves with RSA-4096 encryption, managed by function ##0x140004936##. This function encrypts a key bundle (it's about 256 bytes) containing the 32-byte ChaCha20 key, the 12-byte nonce, plus some extra info, all using an embedded RSA public key. The resulting RSA ciphertext, which is around 512 bytes, is either tacked onto the end of the encrypted file or stored in a separate .keystore file named with a SHA-256 hash of the original filename.

‍

‍

‍

Stage 4: The Message - Ransom Note Delivery & Termination

The ransomware's final phase involves post-encryption cleanup. After the worker threads finish their encryption tasks, the thread management code ensures that all operations are complete, preventing incomplete execution, which would be detrimental to the attacker's perspective.

The ransom note, located at address ##0x140012020##, serves as the instruction set for the victim. It directs them to access the payment portal via the Tor network using the Onion URL, Client ID, and Password provided within the note.

Upon completion of file encryption and ransom note deployment, the malware performs a final cleanup: shutting down the thread pool, zeroing out sensitive memory (including encryption keys), and exiting cleanly.

Key Behavioral Artifacts

Surgical File Selection - The Targeting Logic

The malware employs a sophisticated file selection algorithm, implemented in function 0x140001903. This mechanism prioritizes high-value data while ensuring the victim's operating system remains functional.

Exclusion Strategy: The algorithm first extracts the file extension using strrchr to locate the last dot. It then performs a case-insensitive comparison against an exclusion list (located at 0x140012780). This list specifically contains fourteen system-critical file extensions:

[##Exe, Dll, Sys, Com, Pif, Bat, Msi, Scr, Drv, Cxd, Mui, Cpl, Fon, ini##]

Files matching any of these extensions are immediately skipped to preserve system operability.

Targeting Strategy:

All other file types are targeted for encryption. This includes valuable user data such as:

• Documents
• Databases
• Images
• Videos
• Source code
• Archives

Furthermore, the malware avoids encrypting its own ransom note (##R3ADM3.txt##) and any files already marked with the ##.ENCRT## extension, preventing redundant re-encryption. This targeted approach maximizes the impact on a victim's data, simultaneously ensuring they can access the ransom note and proceed with payment.

Speed Through Parallelism - Multi-Threaded Architecture

The ransomware implements a thread pool architecture with worker threads that process files in parallel. Function ##0x140005500## manages the thread pool, implementing a producer-consumer pattern where file enumeration routines add paths to a shared queue and worker threads pull tasks for processing. The default configuration uses two worker threads, though this appears configurable.

This parallel processing enables the ransomware to encrypt multiple files simultaneously, overlapping cryptographic computation with disk I/O operations. While one thread performs ChaCha20 encryption operations on a large file, another can be reading a different file or writing encrypted data. Combined with ChaCha20's exceptional performance, this architecture enables the malware to encrypt entire file systems in minutes rather than hours.

‍

SHA-256 Hashing for Keystore Management

The ransomware employs a sophisticated dual-mode key storage system that relies on an integrated SHA-256 cryptographic component. This component, specifically functions 0x14000513A through 0x1400052C0, is used exclusively for generating unique filenames for the key bundles.

In its separate keystore operational mode, the malware needs a reliable method to link encrypted files to their corresponding key storage files. Instead of using the original, potentially problematic filename (due to special characters or length limitations), the ransomware computes the SHA-256 hash of the original filename. This hash is then converted into a 64-character hexadecimal string, which forms the standardized keystore filename: {sha256_hash}.keystore.

The implementation of SHA-256 strictly adheres to the standard specification. The process involves function 0x14000513A for initializing the hash context with standard values (e.g., H0=0x6A09E667), 0x140005182 for processing data in 64-byte blocks, and 0x1400051D9 for the finalization and padding steps. The core transformation is handled by the 64-round compression function 0x140004F40, which uses standard K constants and sigma operations. Finally, function 0x1400052C0 converts the binary hash output into the necessary hexadecimal string format.

This cryptographic approach offers multiple benefits: a consistent filename length regardless of the original name, avoidance of issues related to special characters, cryptographic uniqueness to prevent filename collisions, and a deterministic generation process that enables the decryption mechanism to reliably locate the correct keystore file by recomputing the same hash.

Dynamic Analysis 

After completing the initial static analysis, CloudSEK researchers moved the sample into a controlled, isolated VM environment for dynamic analysis. This stage allowed the team to observe the "Locker" in action - monitoring its runtime behavior, system interactions, and encryption processes as they unfolded in real time.

Runtime Behavior Overview

Immediately after execution, the ransomware spawned worker threads and began high-volume filesystem enumeration. ProcMon logs show rapid sequential access across multiple drive letters, confirming the recursive drive scanning routine described in the static execution flow.

Key runtime observations:

• Continuous ##CreateFile## and ##QueryDirectory## operations across user directories
• High-frequency read/write operations on document and archive file types
• Immediate renaming of encrypted files with the .##ENCRT## extension
• Creation of ransom notes (##R3ADM3.txt##) in affected directories
• No attempts to encrypt excluded system directories

The behavior demonstrates optimized throughput consistent with a multi-threaded producer-consumer architecture.

File Encryption Activity

Dynamic execution confirms the hybrid encryption engine is triggered per file. ProcMon captures show a repeating pattern:

1. File opened with read access
2. Sequential chunk reads (~1MB blocks)
3. Immediate write-back of modified content
4. File rename operation to ##.ENCRT##

This pattern is consistent across hundreds of files within seconds, demonstrating ChaCha20’s performance advantage and parallel execution.

Additionally, keystore files are generated when the ransomware operates in separate key-storage mode. These appear as: ##{64-hex-character hash}.keystore##

These files are created in the same directory as their corresponding encrypted file.

Ransom Note Deployment

After encryption completes within a directory, the ransomware writes a ransom note named R3ADM3.txt. ProcMon captures a deterministic pattern:

• Directory traversal completes
• New text file created
• Write operation injects static ransom message
• File handle closed immediately

Network Behavior

No DNS requests, HTTP traffic, or socket creation events were observed during execution. The ransomware performs full encryption without requiring command-and-control connectivity, reinforcing its resilience against network isolation defenses.

Tor portal interaction is victim-driven and occurs only after encryption, via instructions in the ransom note.

Impact

• Severe Data Inaccessibility: Files are encrypted using strong ChaCha20 + RSA-4096 encryption, making decryption impossible without attacker-controlled private keys.
• Operational Downtime: Business operations may be disrupted due to loss of access to critical documents, databases, and system resources.
• Financial and Recovery Costs: Organizations may face financial losses from ransom demands, incident response efforts, system restoration, and business downtime.
• Reputation and Trust Damage: Security incidents can negatively impact organizational reputation, customer confidence, and long-term brand credibility.
• Extended Restoration Timeline: Full recovery may take significant time, especially if reliable offline backups or recovery mechanisms are unavailable.

Recommendations

• Implement Robust Backup Strategy: Maintain frequent offline and immutable backups, and regularly test restoration procedures to ensure data recoverability.
• Restrict Execution of Unknown Files: Enforce application allowlisting and prevent execution from user-writable directories to reduce malware execution risk.
• Enhance Endpoint Monitoring: Monitor for suspicious file activity such as .ENCRT extensions, ransom note creation, and high-volume file modifications.
• Strengthen Email and Access Security: Apply phishing protection, enforce multi-factor authentication (MFA), and educate users on safe file handling practices.
• Establish Incident Response Preparedness: Maintain a tested ransomware response plan, ensure rapid system isolation capabilities, and preserve forensic evidence during incidents.

Appendix

Indicators of Compromise (IOCs)

‍

‍

MITRE ATT&CK Mapping

‍

Ransomware groups/families with similar TTPs

The ransomware ecosystem proves that the number of sophisticated threat actors who possess the skill to make a locker from scratch are few, hence we see some resemblance with other active lockers due to the legacy from leaked conti source code:

• Black Basta uses ChaCha20 for file encryption + RSA-4096 for key protection, with multi-threaded, intermittent encryption for speed and evasion. Enumerates all drives (local/network) and recursively processes files/volumes. Targets user documents, databases, and sensitive data with double-extortion (encryption + exfiltration), often via phishing, QakBot, or FIN7-linked tools. Strong Conti derivative ties.
• Rhysida employs ChaCha20 + RSA-4096 (or Curve25519 in some variants for key exchange. Maps network/local drives and recursively encrypts across volumes. Focuses on user files, documents, and high-value targets (e.g., healthcare), with double-extortion tactics. Shares behavioral overlaps with Vice Society (possible rebrand).
• Akira applies ChaCha20 (or variants) + RSA-4096 for hybrid encryption, with partial/intermittent modes in some builds. Performs drive discovery, enumeration, and recursive file traversal.
• Qilin (aka Agenda) Supports ChaCha20 (fallback for non-AES-NI systems) + RSA-4096/2048; Rust-based variants (Qilin.B) use AES-256-CTR or ChaCha20 + RSA-4096 OAEP. Conducts drive/file discovery, recursive traversal, and network propagation (e.g., PsExec, SSH). 
• Royal (rebranded as BlackSuit) utilizes ChaCha20 + RSA-4096 in modular Windows/Linux variants. Enumerates drives A–Z (including shares) and recursively encrypts. 
• DoNex (aka DarkRace / Muse) employs ChaCha20 + RSA-4096 hybrid encryption (notable key-gen vulnerabilities in some samples). Scans/enumerates drives recursively, targeting all accessible volumes. Excludes critical system paths for crash prevention and offline modes. Targets user files/documents with exfiltration and advanced evasion (e.g., API obfuscation).

References

• https://www.cyfirma.com/research/gunra-ransomware-a-brief-analysis/
• https://www.darkreading.com/threat-intelligence/nimble-gunra-ransomware-linux-variant
• https://www.trendmicro.com/en_us/research/25/g/gunra-ransomware-linux-variant.html
• https://datatracker.ietf.org/doc/html/rfc7539