CISA advisory AA26-222A documents a ransomware operation that should make every Windows administrator uncomfortable. Gunra, built on leaked Conti source code, breached 51 organizations by exploiting unpatched Fortinet firewall vulnerabilities, then executed a playbook that’s become depressingly familiar: lateral movement via SMB, credential harvesting, backup deletion, and mass encryption of up to 9 terabytes per victim.
The advisory focuses on the entry point — CVE-2024-55591 and CVE-2025-24472, both authentication bypass flaws in FortiOS and FortiProxy that were exploited as zero-days and later patched in early 2025. Organizations that haven’t patched are exposed. But here’s the problem: patching has real operational risk, especially in healthcare and critical infrastructure where those Fortinet appliances sit in front of systems that can’t tolerate downtime. The organizations that delayed patching weren’t necessarily negligent — they were making rational decisions about operational continuity versus security risk.
So what happens when the scumbags get in anyway?
Every Attack Stage After Initial Breach Is a File Operation
Once Gunra operators compromised the Fortinet appliance, they moved to establish persistence and spread. The advisory documents use of Impacket libraries — specifically psexec.py, smbclient.py, and secretsdump.py — to move laterally across victim networks via SMB and dump credentials from domain controllers.
Here’s what that actually means at the file system level: psexec.py works by copying an executable to the ADMIN$ share on a remote machine, then starting it as a service. That’s a file write operation to a network share. The ransomware payload itself has to land on disk before it can execute — another file write. Credential dumping from NTDS.dit requires reading that database file. Backup deletion is a delete operation. And the final encryption stage requires reading the original file, encrypting it in memory, and writing the encrypted version back to disk — a write operation, often accompanied by a rename operation to add the .ENCRT extension.
A kernel filter driver intercepts all of these operations before they complete.
How FileSure’s Kernel-Level File Control Would Have Stopped Gunra
FileSure Defend operates at the Windows kernel level via a filter driver that sits between the application layer and the file system. Every file operation — open, read, write, delete, create, rename — passes through the filter driver, which enforces policy before allowing the operation to proceed.
For the Gunra attack, FileSure would have applied at four distinct stages:
Stage 1: Payload delivery. When the ransomware executable attempts to land on disk after the initial compromise, FileSure evaluates the write operation. If the policy restricts which programs can write executable files to the system (and it should), an unauthorized remote session writing a .exe or .dll gets blocked before the file is created. The payload never lands. The attack stops here.
Stage 2: Lateral movement. If the payload somehow landed, Gunra’s use of psexec.py to spread via SMB requires writing executables to remote shares. A FileSure policy on those file servers would block unauthorized programs from writing executables to ADMIN$ or other administrative shares. Lateral movement fails.
Stage 3: Backup deletion. The advisory specifically notes that Gunra deleted both primary and disaster recovery backups — the most damaging element of the attack for organizations that might otherwise have recovered without paying. FileSure policies can prevent deletion of files in backup directories by unauthorized programs or users. The backups survive.
Stage 4: Mass encryption. If ransomware somehow bypassed all prior controls and began encrypting files, FileSure’s threshold rules detect the bulk modification pattern. A threshold rule configured to allow 20 file write/rename operations per hour for normal users would fire within seconds when ransomware attempts to encrypt hundreds of files per minute. Subsequent operations are blocked. Damage is contained to the files modified before the threshold fired — maybe a few dozen files instead of 9 terabytes.
Here’s a specific FileSure rule configuration that would have blocked the encryption stage:
- File name filter:
*(all files) - Operations: Write, Rename/Move
- Drive type: Hard drives, Network drives
- Threshold: 20 matches within 60 minutes
- Action: Block and alert
Normal users saving documents throughout the day stay well below 20 file modifications per hour. Ransomware encryption crosses that threshold in seconds.
The Upstream Advantage: Prevention vs. Detection
The advisory notes that most Gunra intrusion activity occurred between 10pm and 6am to reduce the likelihood of detection during business hours. That’s a telling detail. Signature-based detection tools — antivirus, EDR platforms that rely on behavioral analysis of known attack patterns — are just as blind at 2am as they are at 2pm. They’re waiting to recognize something they’ve seen before.
File operation policies don’t sleep, and they don’t need to recognize the threat. They simply enforce what’s allowed. An unauthorized program attempting to write an executable at 2am gets blocked the same way it would at 2pm, whether it’s Gunra, Conti, LockBit, or a variant that won’t have a name until next week.
The most effective intervention is the earliest one. Blocking the payload write prevents execution, which prevents lateral movement, which prevents encryption. One blocked file operation at the delivery stage eliminates the entire attack chain.
What About the Linux Variant?
The article notes that Gunra’s Linux encryptor contains a fatal cryptographic flaw that allows victims to recover files without paying — a rare piece of good news in an otherwise grim advisory. But FileSure Defend is a Windows-only product. It doesn’t run on Linux systems, so it wouldn’t have applied to the Linux variant at all.
That said, the Windows variant — which affected the majority of documented victims and used a cryptographically sound implementation — remains unrecoverable without the decryption key. Organizations hit by the Windows variant either pay the ransom, restore from backups (if Gunra didn’t delete them), or lose the data permanently.
FileSure prevents the Windows encryption from happening in the first place.
Want to see how FileSure would protect your environment? Install it on one server and ten workstations, open a Word document, and check the console — you’ll see the file operation recorded in real time. That’s the product working. Everything else is just deciding how much of it you want to use.
Start your free 21-day trial at bystorm.com — no credit card required.
Source: Gunra Ransomware Hit Hospitals and Governments; Linux Victims Should Not Pay Ransom
Category: Ransomware
Tags: gunra ransomware, conti ransomware, kernel filter driver, file system security, backup deletion prevention, lateral movement blocking, smb file writes, threshold-based ransomware detection
