Limit who can run administrative command-line tools, because attackers use vssadmin delete shadows to remove Volume Shadow Copy backups and hinder recovery. Alert on shadow copy deletion commands, protect backup systems from endpoint compromise, and keep offline or immutable backups. Application control and least privilege reduce the chance of destructive execution.
How attackers turn shadow copy deletion into a recovery problem
The core issue is not just that the command deletes backups. It is that it attacks the recovery path after the initial compromise, which makes incident response slower and increases the chance that encryption or destructive activity becomes unrecoverable. Treat it as a post-compromise impact step, not a standalone nuisance command.
The practical defence is to reduce who can execute administrative tools, especially on endpoints that can reach backup workflows or storage. Pair that with monitoring for shadow-copy deletion activity and with controls that keep backup copies outside the attacker’s normal endpoint control path, so one compromised host cannot remove the organisation’s last good restore point.
Application control and least privilege matter here because they constrain the execution path itself. If the attacker cannot launch the tool, elevate into the necessary context, or reach the backup layer from the compromised endpoint, the destructive action becomes much harder to complete.
What to harden before the command can do damage
Start with the systems and accounts that can actually issue destructive administrative commands. Restrict local admin rights, remove unnecessary command-line execution paths, and segment backup infrastructure so ordinary user workstations, and ideally even standard server admin sessions, cannot directly tamper with recovery assets.
Backups should also be designed for tamper resistance, not just availability. Offline or immutable backup copies reduce the value of a successful deletion attempt, and separating backup credentials and management planes limits how far one compromise can spread. If the backup tier shares too much trust with the endpoint tier, the command becomes a recovery-kill switch rather than a local cleanup action.
Alerting should focus on the observable behaviour that precedes failed recovery. A deletion command, a burst of privilege use, or attempts to interfere with volume shadow copies are all signals that deserve rapid triage because they often appear alongside broader ransomware preparation or impact activity.
How to recover when shadow copies may already be gone
When patching or hardening cannot happen immediately, the next best move is to preserve evidence and narrow the blast radius. Isolate the affected host, verify whether backup repositories are still intact, and confirm whether the command was executed manually, through automation, or as part of a broader intrusion chain.
If there is any sign that the attacker reached backup credentials, management consoles, or restore tooling, rotate the relevant access material and review sessions or delegated access that could still allow deletion or sabotage. Restoration planning should assume that the compromised endpoint is untrusted until proven otherwise, even if the shadow copies appear untouched.
For broader recovery strategy, Ransomware Prevention Guide is the most directly relevant internal reference because it ties shadow-copy protection, immutable backups, endpoint hardening, and recovery resilience into one control set. For incident context and defensive alerts, CISA cyber threat advisories is the authoritative place to track current threat activity and response guidance.
Risk and Threat Considerations
Shadow copy deletion is dangerous because it converts a recoverable compromise into a higher-consequence event. Once the attacker can erase local rollback options, the organisation’s recovery time, ransom leverage, and confidence in clean restoration all worsen at the same time.
Failure mechanism: Attackers use administrative command execution, or equivalent privilege abuse, to remove Volume Shadow Copy backups and eliminate one of the easiest restore paths before or after encryption, exfiltration, or destructive impact.
Impact: Recovery becomes slower and more uncertain, backup trust is reduced, and the organisation may have to rely on slower offline restores or incomplete incident reconstruction if the compromise is not caught early.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Restricts who can run destructive admin commands and reach recovery assets. |
| Recommendation — Limit privileged command execution and remove unnecessary administrative access. | ||
| NIST CSF 2.0 | PR.AA-04 — Access Permissions and Authorizations | Applies least privilege to reduce abuse of admin tools and backup access. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Supports monitoring for shadow-copy deletion and related suspicious execution. | |
| Recommendation — Constrain permissions so only authorized roles can delete shadow copies or alter backups. Monitor for destructive command execution and alert on shadow-copy deletion activity. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly reduces the ability to execute destructive backup-deletion commands. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports detection and review of shadow-copy deletion events. | |
| SI-4 — System Monitoring | Covers detection of malicious command-line activity and recovery sabotage. | |
| Recommendation — Enforce least privilege for administrative tooling and recovery paths. Review audit logs for backup deletion commands and suspicious privilege use. Detect and alert on suspicious administrative commands that target shadow copies. | ||
Practitioner Guidance
What to prioritise: Treat the restore path as a protected asset. If a host can both reach production data and delete recovery data, it has too much operational authority and should be segmented or re-profiled before the next incident.
What to verify: Confirm that shadow-copy deletion attempts generate alerts, that backup repositories are not writable from ordinary endpoints, and that immutable or offline copies can still restore a representative system without using the compromised host.
Decision rule: If a system can run administrative command-line tools and also touches backup or recovery infrastructure, reduce that authority first, then improve detection. If the system is already suspected compromised, assume the local recovery layer may be unreliable until independently validated.
Practitioner takeaway: The best mitigation is not a single control, but a layered assumption that any endpoint can be lost while recovery still remains trustworthy.
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