Before Encryption: Where Ransomware Intrusions Are Decided — Part 2 of 2: Detecting the Window That Actually Matters

Note: This is Part 2 of a two-part series on detecting ransomware before encryption begins. Part 1 explained why the pre-encryption phase determines the outcome of most ransomware intrusions. This article focuses on the specific detections that make that phase visible and interruptible.

Detection opportunities defenders under-instrument

If I had to pick five detections to implement before anything else, anchored to telemetry most environments already collect:

1. Shadow copy deletion and backup tampering. Alert on vssadmin, wmic shadowcopy, wbadmin, bcdedit modifications to recovery state. Process creation events with command-line logging are sufficient. P1, no exceptions, page somebody.
2. EDR/AV service stop or tamper events. Hook the EDR’s own tamper-protection telemetry into the SIEM and treat it as a primary detection (this can be noisy by itself), not a hygiene log. Pair with Windows Event ID 7040 (service start-type changes) and 7036 (service state transitions) on security services.
3. LSASS access from non-system processes. Sysmon Event ID 10 with GrantedAccess masks consistent with credential theft: 0x1010 and 0x1438 (or 0x143A), the canonical Mimikatz-extended mask is a high-fidelity signal for T1003.001 (LSASS Memory). Mimikatz, Nanodump, and the Cobalt Strike mimikatz BOF all hit this.
4. Anomalous internal SMB fan-out. A single workstation establishing SMB sessions to a statistically unusual number of internal hosts inside a short window is a near-perfect discovery/lateral-movement signal. This is a netflow or Zeek detection, not an endpoint one.
5. Unsigned or rare RMM tools spawning from user-writable directories. AnyDesk launching from C:\Users\<x>\AppData\Local\Temp is not how AnyDesk gets deployed legitimately.

This is also where well-placed encryption inspection earns its keep. Disclosure: encryption inspection is SecuritySnares’ domain. Take this paragraph with that in mind. An agent that denies untrusted processes the ability to perform encryption prevents the attacker from holding your data hostage and turns the three-hour pre-encryption window into the defender’s advantage.

”We can’t detect everything in real time.”

This is the honest objection, and it deserves an honest answer. No, you cannot detect every technique in real time, and trying to do so is how SOCs end up drowning. The realistic ambition is narrower and more achievable: detect the pre-encryption phase reliably enough to give yourself a credible chance of intervention before the encryptor runs.

That ambition has three properties worth naming. First, it is bounded. You do not need full coverage of MITRE ATT&CK; you need coverage of the dozen or so techniques that consistently appear in the hours before encryption. Second, it is biased toward high-fidelity, low-volume detections: shadow copy deletion, LSASS access, EDR tamper, RMM-from-temp. Stay away from broad behavioral content that generates triage debt. Third, it accepts that mean time to respond matters more than mean time to detect. A detection that fires at 02:14 and gets actioned at 09:00 is a detection that fired during encryption. The operational question is which alerts page a human at 02:14 and which wait for the morning queue. Get that list right and the rest is tuning.

If you do those three things, you do not need to “detect everything.” You need to make the pre-encryption phase expensive and observable, and you need a runbook that isolates a host on a single high-fidelity signal without waiting for committee.

What to leave with

If you are running a SOC, take these actions this week:

1. Audit your shadow-copy and backup-tampering detections today. If vssadmin delete shadows /all does not page someone, fix that before the next standup.
2. Treat EDR tamper events as primary detections, not telemetry. Pipe them into the SIEM, pair them with another alert to reduce noise and increase fidelity, and rehearse the response.
3. Baseline internal SMB fan-out per host. The detection is cheap, the signal is strong, and it lights up exactly when you need it to.
4. Inventory and constrain RMM tooling. Allowlist the ones IT uses, alert on everything else, and treat RMM-from-AppData as compromised until proven otherwise.
5. Rewrite your ransomware tabletop to start three hours before encryption, not at the ransom note. That is where the decisions actually get made. Both theirs and yours.

The ransomware story the industry tells is about the encryption event because that is the part with the dramatic visuals. The story defenders need to tell each other is about the quiet, instrumentable hours before it. That is the window where the intrusion is still a detection problem rather than a recovery problem. Spend your attention there.

Series summary

Encryption is the most visible phase of a ransomware intrusion, but rarely the decisive one. The organizations that change outcomes are the ones that instrument and respond during the hours before it begins.

This is part two of the previous article: Three Hours Before Encryption — Part 1.