When ransomware hits an organization, the first visible symptom is usually not on the compromised endpoint. It's on a file server or shared drive, where dozens of file extensions start changing in the space of a few minutes. By the time someone notices the share is unusable, the encryption has already spread across every mapped drive that endpoint could reach.
That gap — between initial compromise and share-wide encryption — is where an EDR-based containment strategy earns its keep. The goal isn't just to detect ransomware; it's to detect the specific signature of mass file modification against SMB shares fast enough to sever the connection before the damage becomes irreversible.
What we watch for
- Abnormally high-velocity file writes and renames against a single UNC path
- Sequential extension changes across many files in a short window
- A single host touching an unusual number of files across multiple shares
- Process lineage — is the writing process a known backup/sync tool, or something unrecognized spawning from a script or macro
- Correlation with recently modified or newly created scripts on the source endpoint
Detection is only half the job
Detecting the pattern matters far less than what happens in the next thirty seconds. A practical containment control needs to be able to automatically isolate the offending host's network access — or terminate its SMB session specifically — without waiting on an analyst to be at a keyboard. That means building and testing containment policies before an incident, not during one, and validating that the policy doesn't quietly break legitimate high-volume file operations like backup jobs or data migrations.
The organizations that come through a ransomware event with a shrug, rather than a headline, are the ones who tested their containment policy against a false positive before they ever needed it against a real one.
Where this tends to go wrong
- Containment thresholds tuned so loosely that real attacks slip under them
- Thresholds tuned so tightly that backup software trips them weekly, training the team to ignore alerts
- No tested rollback plan if containment fires on a legitimate business process
- Detection logic that only watches the endpoint, not the share — missing attacks that originate from an already-compromised machine outside your EDR's visibility
None of this requires exotic tooling. It requires a clear-eyed view of what your EDR platform can actually see on network shares, a containment policy that's been pressure-tested against your own backup and sync traffic, and a runbook that tells the on-call analyst exactly what happens automatically versus what still needs a human decision.
This note sits next to our endpoint security, EDR, and XDR work.
Share this on LinkedIn
Most ransomware detection strategies watch the wrong machine. The first sign of an attack is rarely on the endpoint that got compromised — it's the sudden spike in file writes on a shared drive three hops away. Wrote up the EDR-based approach we use to catch it there: 🔗 [link]
