Volume Shadow Copy and $MFT: recovering older MFTs

Short answer: Every Volume Shadow Copy snapshot contains a frozen copy of $MFT from the moment the snapshot was taken. Mounting an older snapshot and exporting its $MFT lets you compare today's filesystem with one from a week ago, recover files deleted between snapshots, and watch metadata change over time.

What VSS captures

Volume Shadow Copy Service (VSS) 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, the original is preserved in the shadow copy first. The snapshot therefore reflects the volume exactly as it was at the moment of creation, including the Master File Table.

On a typical Windows endpoint snapshots are taken automatically — usually before a Windows Update, sometimes by System Restore, often by third-party backup software. A workstation can easily have a half-dozen snapshots going back weeks.

Why this matters for forensics

The live $MFT is one observation. A volume with five snapshots gives you six observations: today plus five historical ones. 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.
• Files that exist now but were absent then — proving when they were introduced.
• Records whose timestamps differ from today, exposing renames, moves, and timestomping that happened between snapshots.

Snapshots are especially useful in ransomware cases: if VSS has not been deleted (some ransomware tries — see ransomware patterns in MFT), one of the older snapshots will contain the pre-encryption $MFT and, often, the original file data.

Listing snapshots

From an elevated PowerShell:

vssadmin list shadows

Each entry shows a Shadow Copy Volume path that looks like \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7. That path is mountable.

From a forensic image, use libvshadow. The vshadowinfo tool enumerates snapshots inside a .dd or .E01 image; vshadowmount exposes them as individual virtual volumes.

vshadowinfo disk.dd
vshadowmount disk.dd /mnt/shadows

After mounting you get vss1, vss2, ... as separate files, each parseable as an NTFS volume.

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\$Mft
• FTK Imager: add the shadow copy device as evidence, navigate to $MFT, export.
• icat from The Sleuth Kit (image): icat -o <offset> vss1 0 > mft_vss1.bin (inode 0 is always $MFT).
• KAPE with the MFT target run against each mounted snapshot.

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 vss3 but missing or marked deleted in today — files deleted in the interval.
• Records present in today but absent in vss3 — files introduced in the interval.
• Records whose $STANDARD_INFORMATION timestamps moved backwards — possible timestomping (the snapshot is the ground truth).
• Records whose $FILE_NAME parent reference changed — file moved to a different directory.

The same diff at the $UsnJrnl level is even richer; pair it with the MFT diff for a full picture.

Limits

• Snapshots can be deleted. vssadmin delete shadows /all is a one-line wipe and is in every ransomware playbook. Snapshots already evicted are gone — VSS keeps a fixed maximum (64 by default).
• 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.
• Resident data in older $MFT is not preserved beyond the snapshot. If the file existed in a snapshot and was small, that snapshot has the resident bytes. Don't expect to recover the data from any snapshot that was taken after the deletion.

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.

How many snapshots does Windows keep?

Up to 64 per volume by default. The setting is MaxShadowCopies in the registry and is rarely customised. On servers with backup software, the effective limit is usually whatever the backup software keeps.

Is shadow copy data resilient to wiping?

It is resilient to deleting individual files on the live volume — that is the point. It is not resilient to vssadmin delete shadows, full-disk wipe, or physical media damage.