How do attackers use Volume Shadow Copy Service (VSS)?

Why VSS Becomes Useful to an Attacker

volume shadow copy service is a Windows recovery feature, but attackers value it because it can expose files that are normally in use, preserve copies of data before defenders react, and interfere with recovery. That makes VSS attractive in both pre-ransomware theft and destructive ransomware workflows, especially when local administrative rights are available.

Shadow copies are not a magic bypass, they are a storage and recovery mechanism. The security question is whether the attacker can enumerate, copy, or remove those snapshots without being noticed, and whether backup and recovery controls are isolated enough to survive that activity.

Common Ways Attackers Abuse Shadow Copies

One common pattern is to use VSS to access locked files or volume contents that would be difficult to read directly. That can help with theft of documents, configuration files, or credential material stored on disk, and it can also support reconnaissance by letting an attacker review system state without changing live files.

A second pattern is destructive. Attackers may delete shadow copies before encrypting systems so victims have fewer local recovery options. In ransomware cases, that is often paired with backup tampering and attempts to weaken restore paths, which is why defenders should treat snapshot deletion as a high-signal event. NHIMG’s Ransomware Prevention Guide covers why shadow copy protection and resilient backups matter together.

A third pattern is post-compromise cleanup. If an attacker has obtained privileged execution, they may remove snapshots, erase recovery points, or stage data theft before defenders can restore affected systems. That is especially relevant when backup administration and endpoint administration are not separated. Backup Security and Immutable Backup Guide explains the recovery design choices that limit this abuse.

What Defenders Should Watch and Harden First

Monitor creation, enumeration, mounting, and deletion of shadow copies as distinct events, not just general file activity. The most useful signal is unusual activity around recovery points from accounts that do not normally manage backups, especially when that activity occurs shortly before mass file changes or encryption behavior.

Limit who can administer volumes, backups, and recovery tooling, and separate those privileges from ordinary server administration. If the same account can manage live systems and remove restore paths, the attacker only needs one compromise to reduce both operational availability and recovery options. Service Account Security Guide is relevant where backup jobs or recovery workflows rely on privileged non-human accounts.

Protect backup systems separately from the production estate. If defenders can only restore from the same trust boundary that the attacker already reached, the backup layer becomes part of the blast radius rather than a recovery control. That is why immutable storage, off-host backup administration, and restore testing are central, not optional. Windows Forensic Artefacts Guide is useful when you need to triage whether snapshot abuse occurred during the intrusion.

Risk and Threat Considerations

VSS abuse is dangerous because it turns a recovery feature into an attacker convenience. If shadow copies are accessible to the same local privilege level that an intruder can often reach after initial compromise, they can become a path to data exposure, faster exfiltration, or reduced recovery resilience.

Failure mechanism: An attacker with sufficient rights can enumerate or delete shadow copies, then combine that with file theft or ransomware to remove local rollback options and make restoration slower or impossible.

Impact: Organisations can lose both confidentiality and recoverability at the same time, which increases downtime, raises ransom pressure, and makes incident response depend more heavily on offline or immutable backups.

Practitioner Guidance

What to prioritise: Treat snapshot creation and deletion as a backup-integrity control, not just an operational convenience. If you can only instrument one area, start with privileged activity around recovery points and backup administration accounts.

What to verify: Confirm that backup and restore roles are separated from day-to-day admin roles, that restore testing is occurring, and that production operators cannot silently destroy the organisation's only usable recovery path.

Common mistake: Assuming “we have backups” is enough. If those backups are reachable from the same compromised host, domain, or admin tier, VSS abuse can still leave you with no clean recovery option.

Practitioner takeaway: The key judgement is not whether VSS exists, but whether an attacker who reaches administrative execution can also erase your practical ability to recover from it.

Related resources from NHI Mgmt Group

• How does Volume Shadow Copy Service (VSS) work?
• Volume Shadow Copy Service
• What breaks when ransomware attackers use a Ransomware as a Service model?
• How should security teams secure service accounts before attackers use them for lateral movement?