Chapter 15

Volume Shadow Copies

Volume Shadow Copies (VSS) are point-in-time disk snapshots created automatically by Windows backup and restore. For forensics, they provide historical versions of every artifact — registry hives, event logs, prefetch, and user data — letting you travel back in time to before the attacker cleaned up.

Scenario

An attacker spent three weeks in the environment. Before leaving they deleted the scheduled tasks they'd created, cleared the event logs, deleted their malware, and scrubbed the Prefetch directory. The live system looks surprisingly clean. But the backup administrator has Windows Backup running weekly. Three VSS snapshots from the past month still exist on the C: drive. The snapshot from two weeks ago predates the cleanup — it contains the original event logs, the Prefetch files for the attacker's tools, the registry run keys they used for persistence, and the malware files themselves. The VSS snapshots are the investigator's time machine.

VSS Concepts

  How Volume Shadow Copies Work
  ═══════════════════════════════════════════════════════════════════

  Snapshot principle: Copy-on-Write
    When a VSS snapshot exists and a file on the volume is modified:
      1. Windows copies the original blocks to the "shadow storage" area
      2. The new data is written to the original location
      3. The snapshot now references the shadow storage blocks
         → The snapshot shows the file as it was BEFORE the change

  VSS storage location:
    System Volume Information\{GUID}\ on the same volume
    (hidden directory, only accessible by SYSTEM by default)

  Listing snapshots:
    vssadmin list shadows            (cmd, requires admin)
    Get-WmiObject Win32_ShadowCopy   (PowerShell)

  Snapshot types:
    Automatic (System Restore, backup): created by Windows
    Manual: created by administrators or backup software
    App-consistent: created with VSS writer support (Exchange, SQL)

  Forensic access methods:
    1. Mount via mklink (symbolic link to snapshot path)
    2. Mount via Autopsy VSS plugin
    3. Mount via third-party tools (Arsenal Image Mounter, ShadowExplorer)
    4. Access via VSS API with custom tools

Accessing VSS Snapshots

PowerShelllist-and-mount-vss.ps1

# List all VSS snapshots on the system
$snapshots = Get-WmiObject Win32_ShadowCopy | Sort-Object InstallDate -Descending

$snapshots | Select-Object @{
    n="ID"; e={$_.ID}
}, @{
    n="Created"; e={[datetime]::ParseExact($_.InstallDate.Substring(0,14), "yyyyMMddHHmmss", $null)}
}, @{
    n="Volume"; e={$_.VolumeName}
}, @{
    n="DeviceName"; e={$_.DeviceObject}
} | Format-Table -AutoSize

# Output example:
# ID                                    Created              Volume DeviceName
# {abc...}                              2026-09-10 03:00:00  C:\    \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

# Mount a snapshot as a drive letter for investigation
# Replace {SNAPSHOT-GUID} with actual GUID from above listing
$snapshot = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq "{abc...}" }
$devicePath = $snapshot.DeviceObject + "\"

# Create a symbolic link to access it as a path
cmd /c "mklink /d C:\vss_mount `"$devicePath`""

# Now browse C:\vss_mount\ as if it were the old filesystem state
# The snapshot from 2026-09-10 shows the filesystem as it was on that date

# Run artifact analysis tools against the snapshot:
PECmd.exe -d "C:\vss_mount\Windows\Prefetch" --csv "D:\analysis\vss-prefetch"
EvtxECmd.exe -d "C:\vss_mount\Windows\System32\winevt\Logs" --csv "D:\analysis\vss-evtx"

# Clean up
cmd /c "rmdir C:\vss_mount"

VSS Analysis in Autopsy

  Autopsy VSS Workflow
  ═══════════════════════════════════════════════════════════════════

  1. Open disk image in Autopsy (E01 or raw dd)
  2. Autopsy automatically detects VSS snapshots (Ingest Module)
  3. In the Data Sources panel, expand the image:
     ├── vol1/ (current filesystem state)
     └── vol1 - Shadow Copy 1/ (VSS snapshot 1)
         └── vol1 - Shadow Copy 2/ (VSS snapshot 2)
  4. Navigate to any snapshot and browse it exactly like the live volume
  5. Run keyword searches against all snapshots simultaneously
  6. Timeline includes events from all snapshots — compare states over time

  Comparison workflow:
    - Find suspicious file in current state
    - Check same path in each snapshot
    - Was the file present? What were its timestamps?
    - When did the file first appear? (earlier in a snapshot = earlier compromise)

What VSS Enables in Investigations

Investigative question	VSS approach
Attacker deleted their malware — can you get the binary?	Mount VSS snapshots predating deletion. If the binary was present at snapshot time, it's in the VSS. Extract and analyze (hash, VT, Ghidra).
Attacker cleared event logs — can you get the original logs?	If a VSS snapshot predates the clearing, mount it and extract the EVTX files. Events present at snapshot time are preserved.
When did the attacker first appear? (time of initial access)	Compare artifact state across all snapshots chronologically. The snapshot where the attacker's persistence mechanism first appears establishes an upper bound on initial access time.
What did the registry look like before the attacker modified it?	Load the SYSTEM/SOFTWARE/NTUSER.DAT hives from a pre-attack VSS snapshot and compare with the current state. Differences reveal attacker changes.
Has an MFT record been overwritten?	Mount the VSS and check if the MFT record was present in the snapshot. If the file existed at snapshot time, MFT metadata is available there even if overwritten in the current volume.

Why attackers delete VSS and why that deletion is evidence

Ransomware groups routinely delete VSS snapshots as part of their attack: vssadmin delete shadows /all /quiet prevents VSS-based recovery. But this deletion is itself recorded: (1) Windows Security Event Log records the vssadmin process creation (4688) and the VSS deletion in the Volume Shadow Copy Management events (though this is often in the cleared log). (2) The VSS deletion leaves traces in the filesystem timestamps — if you have a full disk image, the deletion of the shadow storage files appears in MFT. (3) More importantly, if you have a SIEM, the vssadmin command appears in 4688 events forwarded before the log clearing. A system that arrives at forensic investigation with no VSS snapshots and recent vssadmin process activity is an active indicator of ransomware or attacker cleanup — document it explicitly in your report.

Q & A

Q: How do you access VSS snapshots from a disk image (not a live system)?

Mount the disk image and access the shadow copy device objects within it. On Linux: (1) Use ewfmount or affuse to mount the E01 image as a raw device. (2) Use vshadowinfo (part of libvshadow) to enumerate shadows: vshadowinfo /dev/loop0p1. (3) Mount individual shadows with vshadowmount: vshadowmount /dev/loop0p1 /mnt/vshadow/ then mount -o ro /mnt/vshadow/vss1 /mnt/snapshot1/. On Windows: Arsenal Image Mounter can mount E01 images and automatically exposes VSS snapshots as separate volume entries that you can browse directly with File Explorer or any forensic tool. Autopsy handles this automatically when you add a disk image as a data source.