This article from Quercus IT does a solid job explaining the four-stage anatomy of a modern ransomware attack: initial footprint, reconnaissance and lateral movement, backup targeting, and finally exfiltration and encryption. It’s accurate. The problem is that most organizations focus their defenses on the later stages — trying to detect the reconnaissance, trying to protect the backups, trying to stop the encryption — when the real opportunity to kill the attack happens much earlier.
The Initial Payload Write Is the Choke Point
The article describes Step 1 as a phishing email delivering “a tiny piece of malicious code” that executes silently. Here’s what that description glosses over: before that code can execute, it has to be written to disk as a file. That write operation happens at the Windows kernel level, and it’s the single most upstream point where you can intervene.
When a normal person clicks a malicious link in an email, their email client (Outlook, Thunderbird, a browser rendering webmail) attempts to write an executable file — a .exe, .dll, .scr, or some other executable format — to a location on the hard drive. That write request passes through the Windows kernel before it completes.
FileSure Defend operates at exactly that layer. It’s a kernel filter driver that intercepts every file operation — open, read, write, delete, create, rename — before the operation completes. You define a rule: unauthorized programs cannot write executable files to this system.
When the phishing payload tries to land, FileSure sees the write request, checks the rule, sees that Outlook (or Edge, or whatever delivery vector the attacker used) is not authorized to write executable files, and blocks the operation. The file never lands. The malware never executes. The attacker never gets a foothold. Steps 2 through 4 — reconnaissance, backup destruction, encryption — never happen because the evildoer never made it past Step 1.
A Specific Rule Configuration That Stops This
Here’s what that rule looks like in practice:
File name filter: *.exe, *.dll, *.scr, *.bat, *.cmd, *.ps1, *.vbs
Program name filter: outlook.exe, msedge.exe, chrome.exe, firefox.exe, iexplore.exe
Operations: Create, Write
Action: Block
Any attempt by an email client or browser to write an executable file to disk gets blocked and logged. Legitimate software updates and IT-approved installations still work because you define those programs as authorized. The phishing payload doesn’t make that list.
Why This Matters More Than Patching and MFA
The article correctly recommends multi-factor authentication and automated patching. Those are good practices. But they don’t stop a phishing payload from landing if the user clicks the link. MFA stops credential theft. Patching closes known vulnerabilities. Neither prevents an email client from writing a file to disk when the user opens an attachment.
FileSure does. It doesn’t matter if the payload is a zero-day variant that no antivirus vendor has seen before. It doesn’t matter if the user’s password was already compromised. The write operation gets blocked because the program attempting the write isn’t authorized. The attack stops there.
The article also recommends isolating backups, which is absolutely correct. But if you stop the attack at Step 1, the attacker never gets far enough to target your backups in the first place.
See It Work
Install FileSure on a test machine. Send yourself a phishing simulation email with a harmless executable attached. Open the attachment. Check the FileSure event log — you’ll see the blocked write attempt, the program that tried it, and the file it tried to create. That’s the whole demo. It works exactly like that, every time, for every phishing payload that tries to land.
Start your free 21-day trial at bystorm.com.
Source: The Anatomy of a Ransomware Attack (And How to Stop It)
Category: Ransomware
Tags: ransomware, phishing, kernel filter driver, file system security, zero-day defense, payload blocking, lateral movement prevention
