Volume Shadow Copies (VSS)

What it is

The Volume Shadow Copy Service (VSS) creates point-in-time snapshots of a volume. On Windows client versions the built-in system provider uses copy-on-write: when a block of the live volume is about to be overwritten, the original content is first copied into a diff area (shadow copy storage). Combining the preserved blocks with the unchanged blocks of the live volume rebuilds the volume as it was when the snapshot was taken.

A shadow copy is therefore a time machine for everything on the volume: earlier versions of registry hives, event logs, $MFT, $UsnJrnl, user documents and even files deleted since. Deleting shadow copies is one of the most common ransomware and anti-forensics steps.

Location

{3808876b-c176-4e48-b7ae-04046e6cc752} is the identifier VSS uses for its metadata files. The diff area must be on an NTFS volume and is normally on the same volume. Windows XP has the VSS service but does not keep persistent client snapshots; its System Restore used a different format.

What it proves

• Earlier state of any file on the volume at snapshot time, including files later modified, encrypted or deleted.
• Historical artifacts: older copies of registry hives, EVTX logs, the $MFT and the $J stream extend every other timeline backwards.
• Snapshot creation time: when each restore point or backup snapshot was taken.
• Tampering: missing or recently deleted snapshots, a shrunken storage limit, and matching commands or events.
• A snapshot does not contain every block ever written: only the blocks changed after it was taken are preserved, and unchanged data is read from the live volume. It says nothing about who used the files.

Key fields

Timestamps

Retention and clearing

• Snapshots are created by System Restore (before updates, driver or application installs, and on schedule), by Windows backup features, and by third-party backup tools. Whether System Protection is enabled at all varies by build, disk size and image, so check before assuming snapshots exist.
• The diff area has a maximum size. When it is full, the oldest snapshots are deleted; the system provider supports up to 512 snapshots per volume.
• Attackers and ransomware delete them: vssadmin delete shadows /all /quiet, wmic shadowcopy delete, PowerShell Win32_ShadowCopy deletion, or vssadmin resize shadowstorage to a tiny size so Windows purges them itself.
• The System event log records volsnap events such as 33 (oldest shadow copy deleted to stay under the storage limit) and 25 (shadow copies deleted because storage could not grow in time).
• Files listed under HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot are removed from new snapshots on a best-effort basis; paging files are always excluded.

Collection

• KAPE target: none dedicated. Add --vss to any target run (for example KapeTriage or RegistryHives) to collect the same files from every shadow copy, deduplicated by SHA-1.
• Velociraptor (Windows.Triage.Targets): no dedicated target. Set the VSS_MAX_AGE_DAYS parameter to also search shadow copies newer than that many days; Windows.Search.VSS finds a given file across all snapshots.
• Built-in: list snapshots and link one as a folder (note the trailing backslash):

vssadmin list shadows
vssadmin list shadowstorage
mklink /d C:\vsc1 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\
robocopy C:\vsc1\Windows\System32\config E:\case\vsc1\config SYSTEM SOFTWARE SAM SECURITY /COPY:DAT
rmdir C:\vsc1

For a full image, snapshots live inside the image: process them offline rather than on the live host.

Parsing tools

• libvshadow (Joachim Metz, open source): vshadowinfo lists snapshots with creation times; vshadowmount exposes each one as a raw volume image on Linux or macOS.
• Arsenal Image Mounter (free mode): mounts a disk image as a real disk so Windows itself exposes its shadow copies; direct snapshot mounting is part of the paid mode.
• VSCMount (Eric Zimmerman): mounts all shadow copies of a volume as folders for review.
• dfir_ntfs (Maxim Suhanov): vsc_mount --list and --mount on raw images; ntfs_parser can read metadata files from shadow copies.
• Plaso: log2timeline.py --vss_stores all adds every snapshot to the super timeline.
• MFTECmd (Eric Zimmerman): --vss (with --dedupe) processes the $MFT or $J of every shadow copy on a live drive.

Investigation tips

• Compare the snapshot list with System Restore expectations: a machine with regular restore points that suddenly has none, plus vssadmin.exe or wmic.exe in Prefetch, points to deliberate deletion.
• Search process-creation logs and PowerShell logs for delete shadows, shadowcopy delete and resize shadowstorage; correlate with volsnap events in the event logs.
• Pull older registry hives from each snapshot to see persistence keys, services and user activity as they were days or weeks earlier.
• Parse $MFT and $J from every snapshot to extend the USN journal and recover names of files deleted before the live journal rolled over.
• After a ransomware incident, check every volume: attackers sometimes miss shadow copies on data drives, and unencrypted originals may still be there.