How do attackers use vssadmin delete shadows?

How attackers weaponize shadow copy deletion

Attackers use vssadmin delete shadows as a recovery-suppression step. By removing Volume Shadow Copy snapshots, they make local restore points harder to use and increase the pressure to pay or negotiate after encryption, sabotage, or destructive activity. The command is usually part of a wider sequence, not a standalone objective.

The practical meaning is that shadow copy deletion changes the victim’s recovery options before the main impact lands. It does not have to succeed on every host to be useful to the attacker, because even partial removal can reduce confidence in backup-based restoration and slow incident response.

Where this fits in a ransomware or destructive attack chain

This command is most valuable after initial execution, when the attacker has enough privilege to run administrative tooling and wants to reduce rollback paths. It commonly appears alongside other recovery-denial actions such as stopping backup services, deleting backup catalogs, disabling protective tooling, or targeting ESXi and file servers where restoration speed matters most.

Shadow copy deletion is best understood as an impact enabler. It supports later encryption or wiper-style activity by making the victim’s built-in recovery mechanism less reliable. In many environments, that matters as much as the encryption step itself, because the attacker is trying to convert a single host compromise into broader operational paralysis.

Defenders should treat this as a sign that the adversary is moving from access to impact preparation. The command is often a strong indicator that the attacker has already achieved enough trust or privilege to work on the endpoint locally, which is why it should be correlated with privilege escalation, remote administration use, and unusual scripting or command shells.

What to watch for and what to harden

Detection should focus on endpoint process creation, command-line telemetry, and parent-child process chains. A direct execution of vssadmin, especially with deletion arguments, is the clearest signal, but related activity can also show up through PowerShell, cmd.exe, WMI, PsExec, remote management tools, or other utilities that invoke the same effect indirectly.

Resilience should not rely on shadow copies alone. Immutable or offline backups, separate backup administration, and restore testing matter because snapshot deletion is designed to break the easiest recovery path first. If the environment depends on local volume snapshots as the main fallback, the attacker only needs one successful command to create a disproportionate recovery problem.

When backup suppression is seen, the response should assume broader hostile intent until proven otherwise. That means checking for lateral movement, stolen credentials, backup access misuse, and any follow-on attempts to disable security tools or delete evidence, because shadow copy deletion is typically one part of a staged intrusion rather than an isolated tactic.

Risk and Threat Considerations

Deleting shadow copies creates asymmetric risk: a low-effort command can remove one of the fastest restoration paths on a host. In ransomware cases, that can turn a recoverable event into a much more disruptive one, especially when local snapshots were the main near-term rollback option.

Failure mechanism: The attacker uses administrative execution to remove Volume Shadow Copy snapshots before encryption or destructive actions, reducing the victim’s ability to self-restore and recover quickly.

Impact: Recovery becomes slower, more expensive, and more dependent on external backups or rebuilds. If snapshots were the only recent restore point, outage duration and business interruption can increase materially.

Practitioner Guidance

What to verify: Confirm whether the command ran on a server or endpoint with meaningful restore value, and whether the host had snapshots that were relied on for rollback. A single alert is less important than whether it coincides with privilege escalation, service disruption, or backup tampering.

Decision rule: If snapshot deletion is observed on a production system, prioritize containment and recovery-path protection before normal forensic comfort. Preserve what you can, but do not delay isolation while trying to determine whether the attacker has already used the command for impact.

Practitioner takeaway: Treat shadow copy deletion as a recovery-denial signal, not just a suspicious command. The key judgement is whether the environment can still restore quickly without the compromised host’s local recovery features.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?