Ransomware operators sabotage recovery before they encrypt a single file, and that step is where detection engineering wins. Minutes before the encryptor runs, a domain-joined Windows host quietly issues vssadmin delete shadows /all /quiet, and most security operations centers only alert once files start changing extensions. That command maps to a behavior MITRE ATT&CK, the industry catalog of adversary techniques, tracks as T1490, Inhibit System Recovery.
Four Pre-Encryption Signals Every Ransomware Intrusion Leaves
LockBit, tracked by CrowdStrike as Bitwise Spider and long the busiest ransomware-as-a-service (RaaS) operation, runs nearly the same routine on every victim network before it encrypts anything. The joint CISA #StopRansomware advisory on LockBit 3.0 documents the sequence step by step, and each step throws off telemetry a defender already collects. Four signals fire before encryption does:
- Recovery inhibition. The operator deletes backups with vssadmin delete shadows /all /quiet, wmic shadowcopy delete, wbadmin delete catalog, and bcdedit /set recoveryenabled no. Every one of these lands in process-creation telemetry, Windows Event ID 4688 or Sysmon Event ID 1.
- Mass deployment by Group Policy. A new Group Policy Object (GPO) pushes an immediate scheduled task and startup script to every domain host, so one encryptor reaches the whole fleet. That is Group Policy Modification (T1484.001) paired with scheduled-task abuse (T1053.005).
- Defense tampering. The same GPO or a dropped vulnerable driver disables Microsoft Defender and endpoint detection and response (EDR) tooling, a move MITRE tracks as T1562.001. Tamper-protection events and unsigned driver loads (Sysmon Event ID 6) mark it.
- Exfiltration staging. Before encryption, the crew moves data out with rclone, MEGAsync, or WinSCP to build extortion leverage (T1567.002). Sustained outbound transfers to cloud storage from a server that never behaves that way are the tell.
Why Detection Engineering Should Skip the Encryptor
Ransomware is unusual among malware in that its final act is deliberately loud, so most programs aim their detection budget at the encryption itself: canary files, mass file-rename heuristics, entropy spikes. Those fire during encryption, when recovery is already gone and the responder is doing damage assessment rather than prevention. The pre-encryption steps are better targets for a reason that is easy to miss. They are both mandatory to the attack and rare in normal operations. A backup admin occasionally clears one shadow copy on one server; nobody legitimately runs vssadmin delete shadows /all /quiet across forty hosts inside ten minutes. That pairing of a low base rate with fleet-wide velocity is the highest signal-to-noise ratio in the whole intrusion, and it sits in logs you already ingest. We have covered how modern crews target even encrypted backups, which is why recovery-inhibition telemetry deserves a dedicated alert rather than a dashboard tile. Incident-response retrospectives fixate on dwell time, but the operationally useful read is that the last hour before encryption is where the loudest signals cluster, part of a broader shift in ransomware toward fast, hands-on-keyboard deployment.
Ship Pre-Encryption Detections Before the Next vssadmin Deletion
Sequence this detection engineering work by signal strength, cheapest and highest-fidelity first, so the recovery-sabotage alert exists before the deployment and tampering rules that need more tuning.
Alert on recovery-inhibition commands, scored by fleet velocity – Detect vssadmin, wmic, wbadmin, and bcdedit with deletion arguments in process-creation telemetry, and raise severity when one command fires across many hosts at once. That velocity is what separates a LockBit rollout from a backup admin doing maintenance.
Watch Group Policy and SYSVOL for new immediate tasks – Alert on directory-service change events, Windows Event ID 5136 and 5137, and on new ScheduledTasks.xml files written to SYSVOL. A fresh Group Policy Object pushing a task to every endpoint minutes before mass process activity is the deployment fingerprint the CISA advisory describes.
Treat Defender tampering and vulnerable-driver loads as encryption precursors – Route tamper-protection alerts and known-vulnerable driver loads to a high-priority queue instead of an archive. Disabling defenses is step one of the encryption routine, not background noise, and it gives you the earliest warning of all.
When that same domain-joined host issues vssadmin delete shadows /all /quiet next time, the alert fires while the shadow copies still exist. Detection engineering built on process-creation and directory-service telemetry buys the responder the minutes needed to isolate the host before the encryptor gets its turn.
Join our LinkedIn group Information Security Community!
