Volume shadow copy

What volume shadow copies do

Volume shadow copy is a Windows recovery feature, not a backup product in itself. It creates point-in-time copies of files or entire volumes so users and administrators can restore earlier states after accidental deletion, corruption, or failed changes. Because those copies are often the fastest restore path, they become a high-value target during destructive intrusions.

The security value of shadow copies is practical rather than abstract: they preserve a rollback option when live systems are altered. That makes them especially important on endpoints and servers where restore speed matters, but it also means defenders should treat their availability as part of resilience, not as a convenience feature.

How shadow copies are used in Windows recovery

Shadow copies are commonly exposed through the Windows Previous Versions experience, volume restore workflows, and forensic collection paths. They can preserve file versions, registry hives, and other artefacts that help with recovery or investigation, depending on how the system and its backup tooling are configured.

In incident response, shadow copies can support triage when live data is missing or partially encrypted. They are also useful to collect evidence of prior system state, which is why defenders often preserve them during containment, before any cleanup activity can overwrite the point-in-time data they contain.

Because they are volume-level snapshots rather than a full business continuity strategy, shadow copies should be seen as one layer in a broader recovery design. They help with rapid restoration on the same host, but they do not replace offline backups, immutable storage, or tested recovery procedures.

Why attackers target shadow copies

Attackers frequently delete shadow copies to remove easy rollback paths and increase the pressure to pay ransoms or accept operational downtime. That behaviour is especially common in ransomware and destructive operations, where the goal is to make local recovery difficult before encryption or wiper activity takes effect.

Deletion is often paired with other recovery inhibition steps, such as disabling built-in restore tooling, tampering with backup catalogues, or targeting snapshot systems in virtualised and cloud environments. The pattern is simple: if defenders lose their fastest recovery point, the blast radius of the intrusion grows.

Shadow copy abuse is also valuable as an operational signal. Commands and behaviours associated with deletion or tampering can indicate pre-encryption staging, anti-forensics, or broader attempts to neutralise recovery controls.

How organisations protect and verify recovery points

Protection starts with knowing where shadow copies exist, who can manage them, and whether those settings are consistent across critical systems. Recovery points should be monitored as assets, not assumed to exist just because a feature is enabled.

Defenders should also separate snapshot administration from routine user and endpoint access, and should validate that recovery points cannot be casually removed by compromised administrator sessions or embedded management tooling. The more tightly the restore path is controlled, the less useful it is to an attacker who already has execution on the host.

For broader context on recovery-targeted attacks, see T1490 Inhibit System Recovery Defensive Guide, which explains how shadow copy deletion fits into ransomware tradecraft, and Ransomware Prevention Guide, which covers the wider control set around resilient backups and shadow copy protection.

Detection and recovery after compromise

Detection should focus on both the deletion action and the loss of restore capability. Sudden absence of shadow copies, unusual use of recovery-related commands, or changes to backup visibility can all be signs that an intrusion is moving from access into impact.

After an incident, organisations should verify whether shadow copies were deleted, whether the deletion was local or remote, and whether the host has any additional restore points left intact. This review matters because post-patch or post-containment cleanup can miss persistence or secondary damage if recovery evidence is not checked early.

Forensics teams can compare host artefacts, event logs, and backup telemetry to understand when recovery points disappeared and whether the attacker also touched related configuration or backup tooling. Windows Forensic Artefacts Guide and Anti-Forensics Detection Guide are useful references for that work.

Risk and Threat Considerations

Shadow copies create a resilience benefit, but they also create a clear target for destructive operators. If an attacker can delete or suppress them before encryption or wiping begins, the organisation loses a low-friction recovery path and may discover the compromise only after restoration becomes expensive.

Failure mechanism: An adversary with sufficient local execution, administrative access, or backup-control reach removes the point-in-time copies and any supporting restore metadata, then proceeds with encryption, deletion, or anti-forensics so the victim cannot easily roll back.

Impact: Recovery time increases, incident containment becomes harder, and the organisation may have to rely on slower or older backups, rebuild systems manually, or accept prolonged outage and data loss.

Practitioner Guidance

Why practitioners should care: Volume shadow copy is only valuable if it survives the incident that makes recovery necessary. Treat it as a controlled recovery dependency and validate that its deletion would be visible, investigated, and recoverable from alternative sources.

What to watch for: Sudden loss of snapshots, unexpected changes to restore settings, or administrative activity that touches both recovery tooling and backup configuration deserve immediate attention. Those signals often appear before or alongside the main payload in ransomware cases.

Practitioner takeaway: If shadow copies are part of your recovery story, assume they will be targeted and design the rest of your backup and detection stack so the loss of one restore path does not become the loss of recovery itself.

Related resources from NHI Mgmt Group

• How does Volume Shadow Copy Service (VSS) work?
• How do attackers use Volume Shadow Copy Service (VSS)?
• How can security teams detect Volume Shadow Copy Service (VSS) activity?
• How do you detect volume shadow copy abuse for credential theft on Windows?