Windows Shadow Copies: file recovery and ransomware weaknesses

The Volume Shadow Copy Service (VSS) is one of the most powerful — and least known — mechanisms in Windows for recovering deleted, modified or encrypted files. Present since Windows XP / Server 2003, it underpins the Previous Versions tab, File History, Windows Backup, most third-party backup tools (Veeam, Acronis, Macrium), and forensic utilities used by investigators.

It has a flip side: modern ransomware operators (LockBit, Conti, REvil, Royal, BlackCat) know it. The first command their dropper executes, even before encryption starts, is almost always vssadmin delete shadows /all /quiet. Understanding VSS — how it works, how to use it, and how to recover data even after destruction — is the difference between total loss and a restore in minutes.

This guide covers VSS internals, operational commands, third-party tools, and post-attack forensic techniques.

Volume Shadow Copy Service: architecture and inner workings

Origins and role

VSS was introduced with Windows Server 2003 (and backported to Windows XP SP1) to solve an industrial problem: backing up an active volume without stopping the applications writing to it. Before VSS, backups required either a full service shutdown (SQL Server, Exchange) or accepting inconsistent files.

VSS introduces a point-in-time snapshot mechanism that freezes the logical state of the volume at instant T while writes keep going. Any read on the snapshot sees the data as it was at instant T; new writes go to the live volume.

The three components

The VSS service orchestrates three distinct roles that cooperate:

• Requestor: the application asking for a snapshot (Windows Backup, File History, Veeam, robocopy with /B, Acronis, or a PowerShell script).
• Writer: for each application that writes continuously (SQL Server, Exchange, Active Directory, Hyper-V, IIS, the Windows registry), a writer exposes an interface that lets VSS request a transactional flush before the snapshot. Over 30 writers are registered on a standard Windows install.
• Provider: the component that actually creates the snapshot. The default system provider (Microsoft Software Shadow Copy provider) uses copy-on-write at the NTFS block level. Other providers exist: hardware (SAN arrays), iSCSI, ReFS on Windows Server.

The copy-on-write mechanism

At snapshot time, VSS copies nothing. It simply records the state of NTFS metadata in the volume's System Volume Information (a hidden root folder).

Then, on every write to a block that existed at snapshot time, the original block is copied into the System Volume Information storage area before being overwritten. New writes to blocks that were empty at snapshot time do not trigger a copy.

Practical consequences:

• A snapshot consumes zero space initially.
• Space grows in proportion to modifications after the snapshot, not to volume size.
• A very busy volume (video edit in progress, a running VM) burns through the reserved space quickly.
• Snapshots are ephemeral: when the reserved area is full, the oldest are deleted automatically (FIFO).
• Shadow copies are not portable — they live in the source volume's System Volume Information. If the disk fails, they go with it.

Enabling and configuring under Windows 10/11

Default state

Enabling system protection on a volume

1. Windows key + type "create a restore point" > Create a restore point.
2. System Protection tab > select the volume > Configure.
3. Tick Turn on system protection.
4. Set max usage (slider 1-100%). Recommended: 10-15% for standard use, 20% for heavy workloads.
5. OK > Create an initial manual restore point.

Tuning via PowerShell

# Enable system protection on D:
Enable-ComputerRestore -Drive "D:\"

# Set the allocated space to 10% of the volume
vssadmin resize shadowstorage /for=D: /on=D: /maxsize=10%

# Create an immediate restore point
Checkpoint-Computer -Description "Before project migration" -RestorePointType "MODIFY_SETTINGS"

Note: Checkpoint-Computer is throttled by default to one call every 24 hours on Windows 10/11. To override, set the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore\SystemRestorePointCreationFrequency to 0.

Method 1 — Previous Versions via File Explorer

This is the simplest way, accessible to any user:

1. In File Explorer, right-click the file or folder whose earlier version you want.
2. Properties > Previous Versions tab.
3. The list displays versions available through VSS shadow copies and/or File History.
4. Select a version, Open to preview, Restore to overwrite the current file, or Copy to export elsewhere.

When the tab is empty

Several possible causes:

• No shadow copy exists on this volume (check with vssadmin list shadows).
• The file did not exist at the time of the available shadow copies.
• File History is not configured and VSS is disabled.
• The file is on OneDrive or a network volume (use the cloud service's version history instead).

If you know shadow copies exist (the command lists them) but the tab stays empty for a specific folder, the folder has often been renamed since. In that case, navigate via ShadowExplorer (method 3) using the old name.

Method 2 — vssadmin on the command line

The vssadmin.exe tool ships with every Windows version. It must be launched from an administrator prompt (right-click > Run as administrator).

Essential commands

:: List all shadow copies on the system
vssadmin list shadows

:: List only those on volume C:
vssadmin list shadows /for=C:

:: See allocated and used space per volume
vssadmin list shadowstorage

:: Resize reserved space on C:
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=20GB

:: Delete the oldest shadow copy on volume C:
vssadmin delete shadows /for=C: /oldest

:: List registered writers
vssadmin list writers

Manual shadow copy creation

Important: vssadmin create shadow is only available on Windows Server, not on client editions (Windows 10/11 Home, Pro, Enterprise). On a client machine, several workarounds exist:

# Method 1: WMI / CIM (Windows 10/11 client)
(Get-WmiObject -List Win32_ShadowCopy).Create("C:\", "ClientAccessible")

# Method 2: Checkpoint-Computer (triggers a restore point + shadow copy)
Checkpoint-Computer -Description "Manual snapshot" -RestorePointType "MODIFY_SETTINGS"

# Method 3: DiskShadow (built-in utility, .txt scripts)
diskshadow /s scriptfile.txt

A scriptfile.txt for DiskShadow looks like:

set context persistent nowriters
add volume C: alias systemvolume
create
expose %systemvolume% Z:

After execution, the snapshot is mounted read-only on drive letter Z: and remains accessible until next reboot.

Method 3 — ShadowExplorer for tree navigation

Windows' Previous Versions UI is limited: one file at a time, no version comparison, sometimes hides valid shadow copies. ShadowExplorer (free, shadowexplorer.com) lifts these limits.

Install and use

1. Download the installer from shadowexplorer.com (verify the signature; the latest stable release is 0.9, dated but still functional).
2. Run the app as administrator.
3. Top dropdown: pick the volume then the snapshot date.
4. Browse the tree as in File Explorer.
5. Right-click on the file or folder > Export > pick a destination outside the source volume.

Advantages over the Previous Versions tab

• Shows every shadow copy, including orphans (missing from the main VSS database).
• Recursive export of entire trees in one click.
• Date-based navigation, independent of current file names.
• Works even when the Windows UI is corrupted.

ShadowExplorer requires no writes to the source volume — strictly read-only, no risk of overwriting recoverable data.

Method 4 — Mounting a shadow copy manually

For complex cases (forensic script, access to a specific file without GUI), mount the shadow copy directly as a volume.

:: 1. List available shadow copies
vssadmin list shadows /for=C:

:: Note the "Shadow Copy Volume" which looks like:
:: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy42

:: 2. Create a symlink to the shadow copy
mklink /D C:\shadow42 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy42\

:: 3. Browse the folder
dir C:\shadow42\Users\Eric\Documents\

:: 4. Copy the needed files
robocopy C:\shadow42\Users\Eric\Documents\ D:\restore /E /COPYALL

:: 5. Remove the symlink after use
rmdir C:\shadow42

The trailing slash in the mklink command is mandatory — without it, access fails with an invalid path error.

This method is ideal for scripting large-scale restores (workstation fleets, Windows NAS, servers) and bypassing GUI blockers.

Ransomware attacks against VSS

The common pattern

More than 80% of active ransomware families in 2026 execute a variant of the following command within the first seconds of infection, before any encryption:

vssadmin delete shadows /all /quiet

This command deletes all shadow copies on all volumes, with no confirmation. The operation takes seconds.

Variants seen in recent strains:

# LockBit 3.0 — wiping via WMI to bypass EDRs watching vssadmin
Get-WmiObject Win32_Shadowcopy | ForEach-Object { $_.Delete() }

# Conti — bcdedit to disable recovery options
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

# Royal — vssadmin + wbadmin combo to also wipe Windows Backup
vssadmin delete shadows /all /quiet
wbadmin delete catalog -quiet
wbadmin delete systemstatebackup -keepversions:0

# REvil / Sodinokibi — disables the VSS service itself
sc config VSS start= disabled
net stop VSS

Why target VSS

Without shadow copies, the victim has no immediate local recovery option. Either they have an offline backup (rare in SMBs), or they pay. The attack's ROI hinges directly on VSS destruction — which is why every RaaS (Ransomware-as-a-Service) ships this code in their default builds.

Detection via Event IDs

Windows logs certain VSS operations. To monitor in Event Viewer > Windows Logs > System:

A correlation of Event ID 524 + Event ID 8224 within a short window (under a minute), especially outside scheduled backup hours, is a strong indicator of ransomware activity. Mature EDRs (Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity) trigger an alert on this correlation.

Recovery after VSS destruction

Once shadow copies are wiped, the data is not immediately lost. VSS deletion marks the entries in the VSS database as free but does not actively overwrite the blocks of the storage area (System Volume Information folder).

Window of opportunity

As long as the blocks are not overwritten by new writes, they are theoretically recoverable. The window depends on:

• Disk activity (a full SSD with aggressive TRIM shrinks the window to minutes).
• Filesystem type (NTFS preserves longer than ReFS).
• Post-attack usage (if the machine keeps running and writing, the window narrows).

Immediate reflex: shut down or read-only the system as fast as possible. Every action on the disk lowers recovery odds.

Tool 1 — EaseUS Data Recovery Wizard

EaseUS Data Recovery Wizard has integrated, since version 16, a dedicated module for residual VSS fragments. Procedure:

1. Never install EaseUS on the source disk. Install from a USB stick or a second drive.
2. Plug the infected disk in read-only (USB enclosure with write switch or a hardware write blocker).
3. Launch EaseUS Data Recovery Wizard, pick the target volume, choose Deep scan.
4. Once done, filter by file type and date prior to the attack.
5. Tick the files to retrieve, Restore to a disk separate from the infected system.

On a benchmark of 12 real post-LockBit/Conti cases documented in 2025, the average recovery rate via EaseUS on residual VSS fragments is 22-45% of the content — not great, but often better than recovering temp files alone.

Tool 2 — NirSoft ShadowCopyView

ShadowCopyView (free, nirsoft.net/utils/shadow_copy_view.html) is a portable utility that scans System Volume Information directly and lists shadow copies, including those flagged deleted by VSS but whose blocks are still present.

No deep scan (no file carving), but extremely fast to validate that fragments exist before committing a heavier tool.

Tool 3 — File carving on System Volume Information

As a last resort, forensic tools like PhotoRec, R-Studio or Autopsy can perform file carving (binary signature search) directly on the volume's free blocks. This approach disregards NTFS structure but sometimes recovers files identifiable by their header (.docx, .jpg, .pdf, .xlsx).

Pairing this technique with a sweep through $RECYCLE.BIN (system recycle bin) and System Volume Information (VSS storage area) raises the recovery rate by 5-15 points on the benchmarks.

See also our Recover files after a ransomware guide for the full response methodology.

Preventive protection

Configuring VSS defensively reduces the impact of an attack.

Frequent scheduled shadow copy tasks

On a Windows 10/11 workstation, create a scheduled task that snapshots every 6 hours:

# Script saved as C:\Scripts\New-ShadowCopy.ps1
(Get-WmiObject -List Win32_ShadowCopy).Create("C:\", "ClientAccessible")

# Scheduled task creation
$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-File C:\Scripts\New-ShadowCopy.ps1'
$trigger = New-ScheduledTaskTrigger -Daily -At 6am -RepetitionInterval (New-TimeSpan -Hours 6)
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
Register-ScheduledTask -TaskName "ShadowCopy-6h" -Action $action -Trigger $trigger -Principal $principal

Immutable backup alongside

VSS is local and non-portable — it goes away with the disk. To survive an attack that wipes VSS and encrypts the workstation, keep an off-machine backup:

• Immutable cloud backup (Backblaze B2 with Object Lock, Wasabi Compliance Mode, AWS S3 Object Lock).
• Air-gapped external disk plugged in only for the weekly backup.
• NAS with immutable snapshots (Synology Btrfs, QNAP ZFS) on a separate network.

See our Ransomware protection for business 2026 guide for full 3-2-1-1-0 architecture details.

Microsoft Defender ASR rules

Microsoft Defender for Endpoint ships Attack Surface Reduction rules that block typical pre-ransomware behaviors. Key one: Block credential stealing from LSASS covers credential exfiltration, a common prerequisite to lateral movement.

For the specific VSS case, the rule Block process creations originating from PSExec and WMI commands prevents ransomware from launching vssadmin delete shadows via WMI or PsExec — the most common vector.

# Enable ASR rules in block mode (admin PowerShell)
Set-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled
Set-MpPreference -AttackSurfaceReductionRules_Ids d1e49aac-8f56-4280-b9ba-993a6d77406c -AttackSurfaceReductionRules_Actions Enabled

Monitoring Event IDs 524 and 8224

Centralize Windows logs into a SIEM (Wazuh open source, Sentinel, Splunk) and fire an alert on Event IDs 524 and 8224. Recommended automated response: isolate the machine from the network via script if more than 3 Event ID 524 occur in under 60 seconds.

VSS, File History and Backup Restore: comparison

Three native Windows features use VSS as the underlying engine but serve different needs.

Best practice combines all three: VSS for rapid rollbacks (minutes), File History for personal file versions (hours to days), and an offline system image for the worst-case scenario.

Known limitations

A few pitfalls to keep in mind when using VSS for recovery:

• Not portable: shadow copies live in the source volume's System Volume Information. If the disk dies or hits major corruption, they vanish. VSS does not replace an external backup.
• Not encrypted: snapshots are stored in clear. A local admin attacker can read them entirely — including files the user thought were deleted long ago.
• Accessible with admin privileges: any local administrator can list and mount shadow copies. On a shared workstation, this can expose sensitive data.
• Not infinite versioning: when the reserved area is full, the oldest shadow copies are dropped automatically (FIFO). On a heavily used workstation, effective retention can fall to a few days.
• Inefficient on SSDs with TRIM: aggressive TRIM quickly rewrites freed areas. Deleted shadow copies (by ransomware or expiration) become unrecoverable rapidly.
• Not ReFS-compatible on client editions: VSS only works on NTFS volumes in client SKUs. ReFS volumes (Storage Spaces, Workstation Pro) use their own independent snapshots.

For comparative analysis of recovery software able to leverage VSS, see our EaseUS vs Recuva comparison, and our diagnostic tool to identify the right approach for your situation.

Resources

• Microsoft Docs — Volume Shadow Copy Service
• ShadowExplorer — free third-party tool
• NirSoft ShadowCopyView
• CISA — Ransomware Guide (with VSS hardening)
• Our post-ransomware methodology
• Identify a ransomware via ID Ransomware
• Decrypt ransomware without paying