Security teams detect vssadmin delete shadows by alerting on execution of the command and any attempt to remove shadow copies or other recovery points. Attackers use it to destroy backups and hinder ransomware recovery. Monitor process creation, command-line arguments, and post-compromise activity from administrative shells, then verify whether deletion was authorised by change records or backup operations.
What to monitor to catch vssadmin delete shadows
Detection should focus on the command itself, the parent process that launched it, and the surrounding administrative activity. The useful signal is not just a single executable name, but a deletion attempt that appears in a privilege-bearing shell, remote admin session, script, or service context. That pattern is especially important because it often appears shortly before backup disruption or encryption activity.
To make this reliable, alert on process creation with command-line capture, command lineage, and any use of MITRE ATT&CK Enterprise Matrix techniques associated with recovery-point removal or post-compromise staging. The strongest detections usually combine the command, the account context, and a short time window of follow-on actions such as backup service tampering, escalation, or log clearing.
How to tell it is malicious rather than operational
Legitimate administration can touch shadow copies in recovery workflows, imaging, or backup maintenance, so context matters. A deletion request from a known backup job, approved change window, or endpoint management workflow is very different from the same command issued from an interactive admin shell, a remote session on a server that should not be under maintenance, or a script launched after unusual discovery activity.
Good triage asks whether the host, user, and timing fit an approved recovery or backup task. If the answer is unclear, verify the change record, the automation source, and whether other hosts were touched in the same way. A single command may be benign, but repeated use across multiple systems is a strong sign of destructive tradecraft.
Why this command matters in ransomware defence
Attackers use shadow-copy deletion to reduce recovery options and increase pressure to pay. Once backup snapshots or restore points are removed, defenders often lose the fastest path to business restoration even if endpoint containment succeeds. That makes this a high-value post-compromise indicator rather than a low-level housekeeping action.
Because the command is often used alongside backup deletion, service termination, or volume manipulation, a detection program should correlate it with broader ransomware-preparation behaviour. A useful anchor for response planning is Ransomware Prevention Guide, which covers recovery-point protection, immutable backups, and the controls that reduce the impact of shadow-copy deletion. The practical point is that detection should not stop at the alert, it should also tell responders whether recovery paths are still intact.
Risk and Threat Considerations
Shadow-copy deletion is risky because it targets resilience, not just availability. If attackers can remove restore points after they gain administrative execution, they can convert an ordinary intrusion into a much harder recovery problem, especially when backups are online or poorly segmented.
Failure mechanism: The attacker gains a privileged shell or script execution path, removes shadow copies, and then follows with backup tampering, encryption, or lateral movement that erases the defender's easiest recovery route.
Impact: Recovery time increases, restoration options shrink, and the organisation may be forced into slower rebuilds, broader outage windows, or more disruptive incident-response decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1490 — Inhibit System Recovery | Shadow-copy deletion is a recovery inhibition technique used to block restoration. |
| Recommendation — Map the event to recovery-inhibition activity and hunt for follow-on destructive actions. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on process and command-line logging for high-risk administrative actions. |
| Recommendation — Enable detailed process auditing and centralise command-line telemetry for alerting. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Devices, Connections, and Software | Detection relies on continuous monitoring for suspicious process execution and admin activity. |
| PR.IR-03 — Mechanisms to Achieve Resilience Requirements | The subject directly concerns preserving restore capability against destructive actions. | |
| Recommendation — Monitor privileged process activity and alert on unauthorised recovery-point deletion attempts. Protect recovery mechanisms so destructive commands cannot remove restore options without control. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Command-line detection requires generated audit records for process creation and administration. |
| Recommendation — Generate audit records for process creation, command lines, and privileged shell activity. | ||
Practitioner Guidance
What to verify: Confirm whether the command was issued by an approved backup, imaging, or maintenance process. If the account is privileged but the workflow is not a known recovery task, treat the event as suspicious until you can tie it to a valid change ticket or automation source.
What to prioritise: Correlate the command with process lineage, remote logon activity, backup service state, and any subsequent encryption or cleanup actions. The most valuable response question is whether the host still has usable restore points, because that determines whether containment can be followed by rapid recovery or must shift to rebuild planning.
Practitioner takeaway: The key judgement is context, not the executable name alone, alert on the deletion attempt, then immediately test whether the action came from an authorised recovery workflow or from a compromise path that is trying to eliminate rollback options.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org