BIPI
BIPI

Volume Shadow Copy Forensics: Evidence Recovery and Ransomware Destruction

Cybersecurity

Volume Shadow Copies preserve point-in-time snapshots of NTFS volumes, acting as an independent evidence store. Ransomware groups delete them first for a reason: they are your most reliable path to pre-encryption artifact recovery.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 27, 2024 · 10 min read

#dfir#forensics#vss#ransomware#evidence-recovery

Volume Shadow Copy Service (VSS) creates copy-on-write snapshots of NTFS volumes, storing the original block data before any modification. Shadow copies accumulate under \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ and are managed by the vssadmin, wmic shadowcopy, and PowerShell Get-WmiObject Win32_ShadowCopy interfaces. For forensic examiners, shadow copies provide access to historical versions of the file system without requiring a backup restore: registry hives, event logs, and file system metadata from days or weeks before an incident are often accessible through VSS.

VSS Architecture and What It Preserves

VSS operates at the block level. When a block on the original volume is about to be overwritten, the VSS driver copies the original block to the shadow storage area before allowing the write. The shadow copy therefore contains the original state of every block that has been changed since the shadow was created. Forensically, this means a shadow copy contains the pre-change versions of: the $MFT, $UsnJrnl, registry hives, event logs, page files, and all user data files that were modified after the snapshot was taken.

  • Default shadow storage: up to 10% of volume size, managed automatically by VSS
  • Creation triggers: Windows Backup, System Restore, Windows Update, and explicit vssadmin create shadow commands
  • Windows 10 automatic shadow copies: created before major system events and on a rolling schedule
  • Retention: oldest shadow copies are deleted automatically when storage space is exhausted
  • Access path: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ (N = shadow copy index)

Accessing Shadow Copies with ShadowExplorer

ShadowExplorer (free tool) provides a Windows Explorer-style interface for browsing shadow copies on a live system. Select the volume and snapshot date from the dropdown, navigate to the file of interest, and right-click to export. For forensic images mounted with Arsenal Image Mounter or FTK Imager, shadow copies are accessible through the VSS-aware mount options that expose each shadow as a separate drive letter.

  1. On a live system: ShadowExplorer or vssadmin list shadows to enumerate available snapshots
  2. On a forensic image: mount with Arsenal Image Mounter using the VSS option to expose shadow copies as drive letters
  3. Alternatively: use mklink to create a symbolic link from a local directory to the shadow path: mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\
  4. Copy target artifacts (hives, EVTX, MFT) from the shadow path to your output directory
  5. Parse the shadow-sourced artifacts with the same tools used for live artifacts

Ransomware VSS Deletion: Forensic Artifacts of the Attack

Almost every modern ransomware family deletes shadow copies before encrypting files. The standard commands include: vssadmin delete shadows /all /quiet, wmic shadowcopy delete, and PowerShell Get-WmiObject Win32_ShadowCopy | Remove-WmiObject. Some families use the Windows Backup API directly to avoid command-line detection. The forensic question is: did the ransomware delete shadows before or after encryption began? The answer determines the recovery window.

undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined

Evidence Recovery from Ransomware-Impacted Systems

If shadow copies were deleted, the recovery path shifts to raw VSS block analysis. The VSS catalog and store remain on disk as sparse files even after vssadmin deletion. Specialized tools like vss_carver or the commercial X-Ways VSS module can recover shadow copy blocks from the raw volume image by parsing the VSS catalog structures. This is not guaranteed, but on systems where deletion happened recently and disk churn has been low, partial shadow recovery is feasible.

  • VSS catalog location: \System Volume Information\ directory (requires SYSTEM-level access)
  • VSS store files: {GUID}.dat files within System Volume Information
  • After deletion: catalog entries are marked invalid but block data may persist on disk
  • vss_carver: open-source tool for recovering VSS block data from raw images post-deletion
  • X-Ways Forensics: commercial option with integrated VSS recovery and timeline merging

Pre-Incident Baseline from Shadow Copies

Beyond ransomware cases, shadow copies serve as a pre-incident baseline for any intrusion investigation. Parse the registry hives from the oldest available shadow copy and compare Run keys, service entries, and scheduled task XML files against the current state. Any entry present after the incident but absent in the shadow is a persistence mechanism installed by the attacker, with the shadow creation timestamp providing an upper bound on when the system was clean.

Ransomware operators delete shadow copies first because it removes your rollback option and your forensic baseline simultaneously. Protecting VSS through Group Policy (restrict vssadmin access to SYSTEM only) is one of the highest-ROI preventive controls available at no software cost.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.