How can security teams detect Volume Shadow Copy Service (VSS) activity?

What VSS activity usually looks like in telemetry

volume shadow copy service activity is easiest to spot when you look for the sequence, not just the command. Normal backup workflows create, mount, query, and sometimes prune snapshots in predictable windows. Suspicious activity often breaks that pattern: ad hoc snapshot creation, rapid enumeration of copies, abrupt deletion, or access to protected files from processes that do not normally touch backup infrastructure.

Process context matters. A legitimate backup agent will usually run from a known path, under a known account, and with a stable schedule. By contrast, attacker use of VSS often appears through administrative shells, scripted tooling, or recovery-oriented utilities running outside the usual maintenance window. That makes parent process, command line, account, host role, and timing the most useful fields for triage.

Security teams should also treat VSS as part of a broader file-access and recovery-control pattern. The event is rarely meaningful in isolation if it sits inside a normal backup job, but it becomes much more important when it appears alongside privilege escalation, lateral movement, or signs that recovery points are being removed before encryption starts.

Which behaviors are most worth hunting

The strongest hunting focus is on shadow copy creation, deletion, and access. Watch for unusual use of diskshadow, vssadmin, wmic, powershell-based deletion logic, or backup-abuse behavior that touches volumes shortly before ransomware-style encryption. Sudden removal of multiple shadow copies is especially important because it can be a pre-encryption step designed to reduce recovery options.

Look for access to locked or sensitive files through the shadow copy path, not just obvious deletion commands. Attackers often use VSS to copy data that is otherwise open by another process, which means the malicious action can look like normal administrative access unless you correlate it with the account, host purpose, and surrounding activity. That correlation is what turns a benign-looking utility into an indicator.

On Windows environments, VSS hunting is stronger when paired with registry, process, and event log evidence. A single command line is weak evidence. A command line plus an unusual parent process, recent privilege gain, and an uncommon execution time is much more persuasive. That is the difference between general backup noise and an actionable security signal.

How to confirm whether the activity is malicious

Confirm the host role first. Backup servers, patching systems, and disaster recovery tooling will naturally generate VSS activity, so those machines need a different threshold than user endpoints or application servers. Then validate whether the account and process are allowed to manage snapshots. If the activity came from an interactive admin session on a system that normally has no reason to manipulate backups, the burden of proof is much higher.

From there, correlate the VSS event with surrounding compromise indicators: privilege escalation, remote administration, credential theft, lateral movement, staging of archives, or large-scale file access. If the same host also shows backup-service tampering, suspicious script execution, or broad file enumeration, treat the shadow copy activity as part of an intrusion path rather than an isolated maintenance task.

When you need a stronger detection baseline, compare the event against known file-system and execution artefacts. The Windows Forensic Artefacts Guide is useful here because VSS often becomes meaningful only when it is joined to process, registry, and event-log evidence. For a ransomware-oriented lens on shadow copy deletion and backup abuse, see the Ransomware Prevention Guide.

Risk and Threat Considerations

VSS abuse is dangerous because it targets recovery, not just availability. If an attacker can delete shadow copies or use them to extract locked files, they can weaken both containment and restoration options, which raises the impact of encryption, exfiltration, or destructive activity.

Failure mechanism: Attackers exploit administrative access or backup tooling to enumerate, copy, or delete shadow copies before defenders notice the pattern. That creates a false sense of resilience while quietly removing recovery options.

Impact: Recovery time increases, endpoint remediation becomes harder, and ransomware incidents become more severe because one of the fastest local rollback paths has been removed.

Practitioner Guidance

What to verify: Build detections around a short list of high-value signals: shadow copy deletion, abnormal snapshot creation, unusual use of diskshadow or vssadmin, and access from accounts that do not normally perform backup operations. Then verify whether each event matches a known backup window or a known administrative workflow before suppressing it.

What practitioners underestimate: VSS is often a supporting step, not the main action. The important question is usually whether the activity appears immediately before data theft, privilege escalation, or ransomware deployment. If it does, the VSS event should be treated as part of an active intrusion chain, not as a standalone administrative anomaly.

Practitioner takeaway: The best detections do not just alert on VSS commands, they identify when recovery control is being deliberately bent or removed as part of a broader compromise.

Related resources from NHI Mgmt Group

• Guide: Backup Security and Immutable Backup Guide
• How should security teams detect ransomware activity from file creation and shadow copy deletion on Windows endpoints?
• What steps should security teams take to prevent Shadow AI risks?
• How should security teams detect cloud activity that is trying to hide in normal volume?
• How should security teams detect shadow AI when employees use personal accounts and copy-paste data into browser-based tools?