Ransomware Hunting Before Encryption

By the time files start showing a .locked extension, the incident is already lost. Encryption is the final five minutes of an attack that’s usually been running for days, sometimes weeks. The teams that actually stop ransomware aren’t the ones with the fastest encryption detection they’re the ones hunting the boring, quiet stuff that happens long before anyone touches a shadow copy.

That’s the part worth internalizing early: modern ransomware operations follow a shockingly consistent playbook. Initial access, credential harvesting, lateral movement, backup sabotage, then deployment. Every stage before deployment leaves traces, and every one of those traces is a chance to stop the whole chain before it matters.

Initial access rarely looks dramatic

Phishing, exposed RDP, or a vulnerable edge device that’s still the overwhelming majority of ransomware entry points, and none of them are exotic. What’s worth hunting isn’t the delivery mechanism itself so much as what happens in the first hour after it. A user opening a macro-enabled document that spawns cmd.exe or powershell.exe as a child process is a pattern old enough that most EDR products flag it by default, but the interesting hunt is in the cases that don’t trip the default rule a LOLBin like mshta.exe or regsvr32.exe making an outbound connection to a domain registered within the last thirty days.

Domain age is an underused signal. Say a workstation reaches out to a domain that was registered eleven days ago, over HTTPS, from a process that has no business making network calls that combination, cheap to check against any threat intel feed with WHOIS data, catches a meaningful chunk of first-stage payload delivery that pure signature detection misses entirely.

Credential harvesting and internal recon come next, and they’re noisy if you know where to look

Once an attacker has a foothold, the next move is almost always some flavor of credential dumping followed by internal reconnaissance net group "domain admins" /domain, nltest /domain_trusts, or automated tools like AdFind and SharpHound. These commands are individually mundane; system admins run variations of them constantly. What separates malicious recon from routine admin work is sequence and speed. An account that’s never run a domain enumeration command in six months of logon history suddenly running four of them back to back within ninety seconds is a pattern worth building a detection around, not just an alert to eyeball once.

This is also where credential theft toolkits show up Mimikatz variants, LSASS dumping via comsprocedures instead of the obvious command line, or DCSync attempts. If you’ve already got hunts built for these from your AD and Windows credential work, this is exactly where they earn their keep. Ransomware operators aren’t inventing new credential theft techniques most weeks they’re using the same ones everyone else is, just on a tighter timeline.

Backup sabotage is the single strongest late-stage warning sign

Here’s the thing I’d flag above almost everything else on this list: ransomware operators go after backups deliberately, and they do it before deployment, not during. Deleting Volume Shadow Copies with vssadmin delete shadows /all /quiet, disabling Windows Server Backup, or targeting backup software agents directly these actions have almost zero legitimate business justification for showing up unscheduled, outside a change window, on production systems.

If your organization builds exactly one high-confidence, low-noise detection this quarter, make it shadow copy deletion command-line monitoring. It’s cheap, it’s specific, and by the time it fires you still typically have a window sometimes hours, sometimes a full day before mass encryption actually starts. That gap is your entire incident response opportunity, and a lot of organizations waste it because nobody was watching for the sabotage step specifically.

Lateral movement volume tells its own story

Ransomware crews move fast and wide in the final stages before deployment, because encrypting one machine is a nuisance and encrypting three hundred is a business-ending event that’s the whole economic model. PsExec, WMI, RDP, and increasingly RMM tools that were never meant for this get used to push the payload across as many hosts as possible in a short window.

The hunt that catches this reliably is connection-count analysis rather than technique-specific detection: one source host establishing SMB or WMI sessions against a dozen or more destination hosts within a short window is abnormal for the overwhelming majority of environments, admin workstations included. Baseline what your actual admin tooling looks like first a legitimate patch deployment might touch fifty hosts too but the difference is usually in the account behind it and the time of day. A patch job runs from a known service account during a maintenance window. Ransomware staging runs from a freshly compromised user account at 2 a.m.

Building the hunt as a chain, not five separate alerts

The mistake a lot of SOCs make is treating each of these stages as an isolated detection competing for analyst attention alongside a thousand other alerts. That’s how a domain-age flag from Tuesday and a shadow copy deletion from Thursday end up reviewed by two different analysts on two different shifts, neither of whom connects them.

What actually works is correlation logic that treats these stages as a narrative new domain contact, followed by credential access indicators, followed by internal recon, followed by any backup-related command scored cumulatively rather than individually. A single stage might be low-confidence on its own. Three stages from the same host within 48 hours should escalate automatically, no analyst judgment call required at that point.