Hunting Ransomware, Sabotage, and Impact-Stage Attacks

The impact stage is the one attackers actually want you to notice—eventually. Ransomware operators don’t hide the encryption. They want a ransom note on every desktop and every server share within minutes, loud and unmissable. That changes the entire hunting calculus compared to earlier ATT&CK tactics. You’re not looking for something subtle anymore. You’re racing a clock that’s already started counting down.

The uncomfortable reality: if your detection triggers when files start getting encrypted, you’re often too late to stop that specific run, though not too late to contain blast radius. The real value of impact-stage hunting is catching the pre-encryption behaviors—the stuff that happens in the hours or days before the ransom note drops.

Shadow copy deletion is still the loudest pre-encryption tell

Almost every mainstream ransomware family deletes Volume Shadow Copies before encrypting, because leaving them intact means victims just roll back and ignore the ransom demand. The command vssadmin.exe delete shadows /all /quiet, or the WMI equivalent via Win32_ShadowCopy, is about as close to a smoking gun as detection engineering gets. If you don’t have an alert firing the instant this executes anywhere in your environment, that’s a gap to close today, not next quarter.

Say your environment sees this command run on a single file server at 3 AM by a service account that’s never touched vssadmin before. That’s not a hunt lead anymore at that point—that’s an incident. But hunting for it proactively, before it fires as an alert, means checking whether your logging actually captures command-line arguments for process creation events across your whole fleet, not just your crown-jewel servers. A lot of environments log this well on domain controllers and miss it entirely on file servers, which is exactly where it matters most.

Mass file operations have a measurable signature

Encryption at scale generates a very specific I/O pattern: rapid sequential file reads followed by writes, often with file renames (adding a ransomware-specific extension) happening across thousands of files in a short window. This is detectable through file system audit logging or EDR file-monitoring telemetry—a single process touching 500+ files within a couple of minutes, especially across multiple directories or network shares, is not normal user or application behavior for almost any legitimate software.

The nuance here: some legitimate processes—antivirus full scans, backup software, search indexing—also touch huge file counts fast. Your baseline needs to account for which processes normally do this in your environment, so the analysis flags an unrecognized process (or a legitimate process being abused, like PowerShell invoking encryption via a loaded .NET assembly) rather than your own backup job every night.

Wipers and sabotage don’t always look like ransomware

Not every impact-stage attack wants money. Wiper malware—the kind aimed at destruction rather than extortion, seen in several geopolitically-motivated intrusions over the past few years—often skips the “encrypt and hold for ransom” step entirely and goes straight to overwriting MBR/GPT data or corrupting file headers irreversibly. The pre-encryption behaviors look similar (shadow copy deletion, disabling recovery options like bcdedit /set recoveryenabled no), but the payoff for the attacker is pure disruption, not payment.

Hunting for sabotage means paying attention to configuration changes that look like recovery-prevention rather than encryption-prep specifically: disabling Windows Recovery Environment, modifying boot configuration data, or targeting backup infrastructure directly (this is a pattern worth calling out on its own—attackers increasingly go after the backup servers first, specifically to remove the safety net before touching production data).

Backup infrastructure as a hunting priority, not an afterthought

If I had to pick one underrated hunt hypothesis in this whole category, it’s this: monitor authentication and administrative activity against backup servers and backup software consoles as aggressively as you monitor domain controllers. A threat actor logging into a Veeam or Commvault console with credentials that don’t normally touch that system, especially followed by backup job deletion or retention policy changes, is one of the strongest early-warning signals available for an impending destructive attack. It’s also one of the least monitored, in my experience, because backup infrastructure tends to get treated as plumbing rather than a security-critical asset.

Building detections that buy you minutes, not just documentation

The honest goal at impact stage isn’t “detect ransomware” in some abstract sense—it’s building a detection stack that shaves enough minutes off your response time to matter. Automated isolation triggered directly off a shadow-copy-deletion alert, before a human even reviews it, is a legitimate and defensible SOC design choice at this stage, because the false-positive cost of isolating a host briefly is much lower than the cost of letting encryption run for even ten more minutes.