Cynet Research Labs published a detailed analysis of Settra ransomware in September 2026, and the technical breakdown reveals an attack where file encryption is the final act—not the opening move. By the time victims see a ransom note, the scumbags have already exfiltrated data, deleted backups, cleared event logs, and shut down security software using a vulnerable kernel driver. The encryptor is just the demolition crew sent in after the movers have left.
This is a long way from 2013, when CryptoLocker charged $300 and the standard advice was to keep backups and restore your files. That advice assumed ransomware was a nuisance, not a multi-stage intrusion with data theft built in.
What Settra Does Before It Encrypts Anything
According to Cynet’s analysis, the Settra encryptor won’t run without a command-line password, which defeats automated sandboxes—they see a binary that exits cleanly and reports success. Once an operator supplies the password, the encryptor unpacks itself and spends considerable effort preparing the system before locking a single file.
It powers down Hyper-V virtual machines so their disk files can be encrypted. It disables the Windows Recovery Environment. It deletes the Windows Server Backup catalog. It clears twelve event logs and wipes the NTFS change journal that investigators use to reconstruct timelines.
Most ransomware deletes shadow copies with vssadmin delete shadows, a command every detection rule watches for. Settra shrinks the shadow copy storage allocation to 401 MB instead, and Windows purges the old restore points automatically to fit under the new limit. Whoever wrote that has read the same detection rules you have.
The encryptor uses Restart Manager—a built-in Windows feature—to shut down databases, mail servers, and other applications holding files open. And it has no HTTP client, no upload mechanism, and no callback for encryption keys. The public key is baked into the binary. Pulling the network cable once encryption starts won’t stop it, and a clean traffic log from the ransomware tells you nothing about whether data left the building, because Cynet’s assessment is that the theft happens hours or days earlier.
The intrusion starts with stolen credentials or a compromised VPN, moves through credential dumping and remote access tooling, and includes loading a signed but vulnerable driver—identified as part of Safetica’s STProcessMonitor family—to disable security software from the kernel. The ransom note tells victims not to follow standard emergency procedures, warns them off hiring recovery firms, and insists all negotiation happen in a private Tor chat. It reads like it was written by somebody who has dealt with incident response teams before and would rather not do it again.
How FileSure’s Kernel Filter Driver Stops This Attack
Every stage of the Settra attack chain involves Windows file system operations, and FileSure intercepts those operations at the kernel level before they complete.
Stage 1: Initial payload delivery. Whether the malware arrives via a compromised VPN, a phishing email, or lateral movement from another compromised system, it has to write an executable to disk before it can run. A FileSure rule that blocks unauthorized programs from writing executable files prevents the payload from landing. If the malware never touches the disk, none of the subsequent stages—driver exploitation, backup sabotage, data exfiltration, encryption—can occur. This is the most upstream intervention point.
Stage 2: Vulnerable driver installation. Settra loads a signed but vulnerable .sys driver file to disable security tools from the kernel. That driver has to be written to the Windows drivers directory before it can be loaded. FileSure blocks unauthorized writes of .sys files to system directories. Even if the initial payload somehow landed, the driver exploit fails because the driver file can’t be written.
Stage 3: Data exfiltration. The article makes clear that data theft happens before encryption. Exfiltration requires reading files from disk and transmitting them—either by copying to a staging directory, uploading via HTTP, or writing to a remote SMB share. FileSure rules can restrict which programs are allowed to read sensitive files (e.g., only authorized backup software and database applications can read files in D:\PatientRecords\), and they can block unauthorized programs from writing to network shares or external drives. An alert fires the moment an unauthorized program attempts bulk file reads, giving you visibility into exfiltration attempts in real time.
Stage 4: Backup and log sabotage. Settra modifies shadow copy storage settings, deletes the Windows Server Backup catalog, and clears event logs—all file write and delete operations. FileSure rules can make backup metadata files and event log files read-only to unauthorized programs, preventing tampering. The scumbags can’t erase the evidence or sabotage your restore capability if they can’t modify those files.
Stage 5: File encryption. If all else fails and the encryptor somehow starts, it still has to write encrypted versions of your files and rename them. FileSure’s threshold rules detect bulk file modification patterns—20 write or rename operations within 60 minutes, for example—and block further operations once the threshold is crossed. Normal users don’t modify 20 files per hour. Ransomware modifies hundreds per minute. The threshold fires within seconds, and subsequent encryption operations are blocked. Damage is contained to the files modified before the rule triggered.
A sample FileSure rule to block ransomware encryption:
- File name filter:
*(all files) - Operations: Write, Rename/Move
- Drive type: Hard drives, Network drives, Removable drives
- Threshold: 20 matches within 60 minutes
- Action: Block and alert
That rule is active on install. You don’t have to wait for a signature update or hope your vendor recognizes the threat. It works on Settra, and it works on ransomware variants that don’t exist yet, because it controls file operations rather than trying to recognize malware.
The Upstream Problem
The article’s author notes that his 2013 advice about backups still stands, with amendments: keep backups offline under separate credentials, forward logs off the machine in real time, and understand that a backup won’t recover data that’s already been copied.
The real amendment is this: if unauthorized programs can’t write to your file system in the first place, you don’t need to restore from backup because nothing got encrypted. And if unauthorized programs can’t read your sensitive files, there’s nothing to exfiltrate.
Settra’s encryptor is sophisticated—password-protected, sandbox-evasive, designed to sabotage recovery and evade detection. But it still has to write files to disk before it can do any of that. Block the write, and the attack stops at the delivery stage.
FileSure Defend runs on all Windows versions, operates at the kernel level, and requires no signature updates to stop zero-day threats. Start your free 21-day trial at bystorm.com and see it block a simulated ransomware payload in under three minutes.
Source: Settra Ransomware Is the Last Thing That Happens
Category: Ransomware
Tags: settra ransomware, double extortion, vulnerable driver exploit, shadow copy deletion, data exfiltration, kernel filter driver, file system security, ransomware prevention
