Most analysts think of Volume Shadow Copies as Windows's backup mechanism. They are also a forensic gold mine, because each snapshot contains a complete, frozen copy of $MFT from the moment the snapshot was taken. A workstation with five snapshots gives you six independent observations of the filesystem (today plus five historical ones). Each one is signed by a different code path. Each one was written at a different time. The diffs between them are the closest thing you get to a continuous record of how the volume changed.
This post is what to do with that.
What VSS captures
Volume Shadow Copy Service takes point-in-time snapshots of an NTFS volume. Each snapshot is a copy-on-write delta: when a block is about to be modified on the live volume, the original is preserved in the shadow copy first. The snapshot reflects the volume exactly as it was at the moment of creation, including:
$MFT(the entire table at snapshot time, with every record's state as it was then)$UsnJrnl:$J(the journal up to that point)$LogFile- Every user file (modulo VSS exclusions, which by default include
pagefile.sys,hiberfil.sys, and the contents of%TMP%)
On a typical Windows endpoint snapshots get taken automatically:
- Before Windows Update installations.
- By System Restore on configuration changes (driver installs, certain software installs).
- By third-party backup software (Veeam, Acronis, MSP RMM tools).
- By specific applications that request snapshots before bulk operations.
A workstation with regular updates can easily have five to ten snapshots going back several months. A server with backup software can have far more.
Why this matters for forensics
The live MFT is one observation. With snapshots, you get a series. Each historical MFT records the state of the volume at that moment, including:
- Files that existed then and have since been deleted. Recoverable in full from the snapshot, including the cluster data if it was in scope.
- Files that exist now but were absent then. Proves when they were introduced. Pin "this file appeared between snapshot N and snapshot N+1" and you have a creation window.
- Records whose timestamps differ from today. Exposes renames, moves, and timestomping that happened in the interval.
- VSS-independent verification. The snapshot is written by a separate code path from the live volume. Forging both consistently is hard.
Snapshots are especially useful in ransomware cases. Most families try to delete VSS first, but they sometimes miss snapshots taken by third-party backup software that uses a different VSS writer ID, or they fail to find snapshots on attached external drives. One surviving pre-encryption snapshot gives you the original files. See ransomware patterns in MFT.
Listing snapshots
From an elevated PowerShell or cmd:
vssadmin list shadows
Each entry shows a Shadow Copy Volume path that looks like \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7. That path is mountable as a separate volume with the same NTFS structure.
For more detail (snapshot ID, creation time, VSS writer):
vssadmin list shadows /for=C:
From a forensic image, use libvshadow:
vshadowinfo disk.dd
vshadowmount disk.dd /mnt/shadows
vshadowinfo enumerates snapshots inside a .dd or .E01 image. vshadowmount exposes them as individual virtual volumes (vss1, vss2, ...). Each one is then parseable as an NTFS volume. This is the standard tool for offline VSS extraction; no Windows machine required.
Extracting $MFT from a snapshot
Once a snapshot is mounted (live system or via vshadowmount), $MFT lives at the same offset as on the parent volume, the root of the snapshot. Pull it with the same tools that pull the live one:
fsutil(live system):fsutil file queryextents \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\$Mftreturns the extents; a raw read assembles the file.- FTK Imager: add the shadow copy device as evidence, navigate to
$MFT, export. - Sleuth Kit's
icat(image):icat -o <offset> vss1 0 > mft_vss1.bin. Inode 0 is always$MFT. - KAPE with the
MFTtarget and--vssflag. KAPE runs the target against each enumerated snapshot in turn and produces per-snapshot extracts in subdirectories.
See extracting $MFT for the live-system mechanics.
Comparing two MFTs
The cheapest useful analysis is a diff. Parse both $MFT files to CSV (one row per record), sort by record number, and diff:
mft_dump -o csv mft_today.bin > today.csv
mft_dump -o csv mft_vss3.bin > vss3.csv
diff <(sort today.csv) <(sort vss3.csv) > changes.diff
What you are looking for:
- Records present in
vss3but missing or marked deleted intoday. Files deleted in the interval. The snapshot has the pre-deletion record; recover the metadata and (often) the data. - Records present in
todaybut absent invss3. Files introduced in the interval. Their creation falls between the snapshot and now. - Records whose SI timestamps moved backward. Possible timestomping; the snapshot is the ground truth.
- Records whose
$FILE_NAMEparent reference changed. File moved to a different directory. - Records where the sequence number jumped by more than 1. The slot was reused multiple times in the interval. Heavy churn or deliberate slot reuse.
The same diff at the $UsnJrnl level is even richer; pair it with the MFT diff for a full picture. Some snapshots will have USN journal contents that have rotated out of the live journal. Combining multiple snapshots' USN journals reconstructs a longer activity history than the live journal alone preserves.
Cases that have justified the effort
A few concrete cases from past engagements that VSS-MFT diffing solved:
- A "deleted by mistake" claim. User said they accidentally deleted a file last Tuesday. The MFT diff between the snapshot of Monday and today showed the file was actually renamed, then opened by a non-user process, then deleted three days later. Different story.
- Persistent backdoor that lived in
\Windows\Temp\. Live MFT had no trace; the cleanup script ran. Snapshot from two weeks earlier had the binary in resident$DATA. Hash matched a known malware family. - Pre-ransomware MFT. A ransomware run encrypted everything on the C: drive.
vssadmin delete shadowshad run but a Veeam-triggered snapshot on a different writer ID survived. Pre-encryption MFT recovered, originals restored, no payment.
VSS is the artifact that turns single-point-in-time triage into a series. It pays back the effort to acquire properly.
Limits
Snapshots can be deleted. vssadmin delete shadows /all is a one-line wipe and is in every modern ransomware playbook. Snapshots already evicted are gone. VSS keeps a fixed maximum (default 64 per volume, often lower in practice based on disk space).
Snapshots are not arbitrary points in time. You get what was scheduled or what an installer triggered. There is rarely a snapshot at exactly the moment of an incident. Closest is usually within a day for a regularly-patched workstation, within hours for a server with backup software.
Resident data in older $MFT is not preserved beyond the snapshot. If a file existed in a snapshot and was small enough to be resident, that snapshot has the bytes. Do not expect to recover them from any snapshot taken after the deletion.
Excluded paths are not in snapshots. %TMP%, pagefile.sys, certain volume shadow copy exclusions in the registry mean some forensic artifacts are not preserved. The pagefile and RAM dump artifacts cover what VSS does not.
Snapshots are not crash-consistent across processes. A snapshot captures the volume at one moment, but it does not coordinate with applications. Open files (databases especially) may be in inconsistent states in the snapshot. NTFS itself is journalled and consistent; what is in the files is whatever the application had flushed at that moment.
Frequently asked questions
Can I read a VSS snapshot from Linux?
Yes. libvshadow is cross-platform. Mount the image with vshadowmount, then any NTFS-aware tool reads the snapshot volumes as plain files.
Do snapshots include system files like $MFT?
Yes. A VSS snapshot captures every block on the volume at snapshot time, including the metadata files at the start of $MFT. That is precisely why snapshots are useful.
How many snapshots does Windows keep?
Up to 64 per volume by default. The setting is MaxShadowCopies in the registry and is rarely customized. On servers with backup software, the effective limit is usually whatever the backup software keeps.
Is shadow copy data resilient to wiping?
Resilient to deleting individual files on the live volume, that is the point. Not resilient to vssadmin delete shadows, full-disk wipe, physical media damage, or hostile actor with admin privileges.
What about snapshots on external drives?
Less common but they exist. External drives configured for File History or with their own backup software can have snapshots. Look for \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN paths for any volume in vssadmin list shadows /for=<drive>:.
Further reading
- Microsoft, Volume Shadow Copy Service. The architectural reference.
- libyal, libvshadow documentation. Mount, parse, and enumerate snapshots from any platform.
- Joachim Metz, Volume Shadow Snapshot (VSS) format specifications. On-disk layout for the snapshot store itself.