Volume Shadow Copies in Windows Forensics: Recovering Deleted and Wiped Artifacts in Incident Response

In numerous intrusion scenarios, sophisticated adversaries and suspects routinely employ anti-forensic techniques to obfuscate or eradicate their digital footprint. Prominent among these are file and free-space wipers, frequently leveraged by advanced persistent threat (APT) groups and technically proficient actors to conceal tools, artifacts, and operational capabilities. Following local privilege escalation, for instance, operators may proactively sanitize associated binaries to thwart detection during incident response (IR) triage. Similarly, post-exfiltration, adversaries commonly purge source archive files—such as RAR containers—from the compromised host to impede identification of stolen data, assuming successful decryption by responders remains feasible.

Nevertheless, such eradication is rarely absolute. Windows systems retain substantial evidentiary potential through historical snapshots. In Windows XP and earlier versions, System Restore points—triggered by events including application installations, Windows Updates, and unsigned driver loads—preserve snapshots of critical system components, encompassing executables, dynamic-link libraries (DLLs), drivers, and registry hives. Malware artifacts are routinely captured within these restore points, a fact that has long been exploited in remediation workflows, which historically advised temporarily disabling System Restore to facilitate full antivirus (AV) scanning of backed-up instances.

From a digital forensics and IR perspective, these mechanisms offer exceptional recovery value. Beginning with Windows Vista and Server 2008, System Restore and Previous Versions functionality evolved to leverage the Volume Shadow Copy Service (VSS), enabling persistent, block-level snapshots of nearly entire volumes through an efficient copy-on-write (COW) paradigm. By default, exclusions are limited and enumerated under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot. While the hibernation file (hiberfil.sys) and page file (pagefile.sys) are frequently omitted from VSS tracking by the associated driver, empirical observations by analysts indicate inconsistent exclusion; therefore, their absence should not be presupposed.

VSS operates by intercepting writes to monitored filesystems, preserving original data blocks (typically in 16 KB increments) within the protected System Volume Information directory prior to committing modifications. Metadata is maintained in a catalog file, commonly identified by the GUID {3808876b-c176-4e48-b7ae-04046e6cc752}, while differential stores utilize concatenated GUID naming conventions (e.g., {unique-GUID}{catalog-GUID}). This architecture facilitates comprehensive temporal reconstruction—enabling forensic examiners to restore prior states of individual files, directories, or substantial portions of a volume.

In addition to the aforementioned exclusions, forensic examiners must account for a significant behavioral change introduced in Windows 8: the ScopeSnapshots feature. This capability is enabled by default in all modern Windows client operating systems (Windows 8, 8.1, 10, and 11). When active, ScopeSnapshots restricts volume shadow copies to monitoring and preserving only those files on the boot volume that are deemed relevant for System Restore operations.

Consequently, VSS snapshots on client systems more closely resemble the limited restore points of Windows XP rather than the comprehensive, near full-volume captures available in Windows 7 and earlier VSS implementations. This scoping substantially diminishes the forensic recoverability of user-generated files, application data, and arbitrary directories that fall outside System Restore’s narrow scope—precisely the artifacts most valuable during intrusion investigations involving deleted or wiped evidence.

Detailed analysis in the white paper “VSS Does Not Protect User Data” by Mamoru Saito (IIJ) illustrates this limitation, documenting cases where files recovered from user desktops and similar locations were present but often corrupted or partially intact due to the scoping mechanism.

Mitigating Factors and Caveats

Windows Server platforms (2012 and later) continue to utilize the full, unscoped Volume Shadow Copy Service functionality, preserving near-complete volume snapshots and maintaining high forensic utility.
On client systems, ScopeSnapshots can be disabled by creating a DWORD registry value named ScopeSnapshots under HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore and setting it to 0, followed by a system reboot.
Even with ScopeSnapshots enabled, partial recovery of user data blocks may still occur in some instances due to imperfect scoping controls; however, recovered content should be treated with caution and rigorously validated for integrity.

Forensic practitioners are strongly advised to enumerate available shadow copies (vssadmin list shadows) and inspect snapshot contents directly when analyzing modern Windows client systems, rather than assuming full-volume historical fidelity.

Volume shadow copies can fundamentally transform the scope and depth of a digital forensics investigation. They frequently preserve critical historical artifacts that adversaries attempt to destroy, including wiped files and free space, deleted event log entries, and file system journal records reflecting renaming, relocation, or deletion operations. These remnants often provide compelling evidence of attacker activity across an extended temporal window. Accessing this data during incident response and forensic analysis can be accomplished through multiple methodologies, each suited to different operational constraints.

Live-System Triage

Several leading incident response and digital forensics triage utilities support direct enumeration and extraction from Volume Shadow Copies (VSCs) on live systems. This capability is particularly valuable when time constraints preclude full disk imaging. Tools such as KAPE (with its built-in deduplication features) and Velociraptor (which scales effectively across thousands of endpoints) enable rapid collection of high-value artifacts from historical snapshots, significantly extending the investigative timeframe without requiring offline analysis.

Full Disk Image Analysis (Offline/Deep Dive)

For high-priority systems—such as patient zero hosts or executive workstations targeted in a compromise—acquiring a complete forensic disk image remains the gold standard to preserve all potential evidence. Once imaged, VSS content can be accessed via two primary techniques:

Windows-Native Mounting with Arsenal Image Mounter: This approach mounts the forensic disk image as a virtual physical drive using a kernel driver, causing Windows to recognize it as live media. The operating system then automatically enumerates and exposes available Volume Shadow Copies. The free version of Arsenal Image Mounter performs this emulation reliably via SCSI drive presentation. If a mounted volume is BitLocker-protected, Windows will prompt for unlock the same way it would for a physical disk — AIM itself doesn't decrypt BitLocker, it simply presents the volume in a state Windows can recognize and act on. Once mounted (and unlocked, if applicable), utilities like Shadow Explorer provide a user-friendly interface for browsing and recovering previous file versions.
Platform-Independent Parsing with libvshadow: For environments where reliance on the Windows operating system is undesirable or impractical, Joachim Metz’s open-source libvshadow library (including the companion tools vshadowinfo and vshadowmount) offers robust, cross-platform capabilities. These utilities parse VSS metadata directly from the disk image and expose individual shadow copies as additional raw disk images or mount points, enabling detailed examination with standard forensic suites.

Caveats: Availability and completeness of VSCs remain dependent on system configuration, ScopeSnapshots settings (on client OSes), available shadow storage space, and whether the adversary has purged snapshots (e.g., via vssadmin). Always validate the existence and integrity of snapshots early in the analysis workflow. Recovered data should be rigorously validated for consistency and potential corruption, particularly on modern Windows client systems.

The first utility from the libvshadow toolset, vshadowinfo, provides functionality directly analogous to the native Windows command vssadmin list shadows (which requires local Administrator privileges). When executed against a target volume, vshadowinfo enumerates all persistent Volume Shadow Copies (VSCs), reporting key metadata for each—including the snapshot identifier (GUID), creation timestamp, and associated store details.

To leverage this capability in an offline forensic workflow, supply vshadowinfo with a raw disk image (.raw, .dd, or equivalent). It does not natively support proprietary forensic formats such as EnCase E01 files. For logical volume images (e.g., a standalone C: drive export from SRL or similar acquisition tools), the utility can typically operate without additional parameters, as the volume starts at offset zero.

When processing a physical disk image containing multiple partitions, the -o (offset) option is required. Specify the byte offset to the start of the target NTFS volume—commonly derived from tools such as mmls (Sleuth Kit) or fdisk. This ensures vshadowinfo correctly locates the VSS catalog and stores it within the disk layout.

Example Usage

Logical volume:
```
vshadowinfo image_c.raw
```
Physical disk with offset:
```
vshadowinfo -o 1048576 disk_image.raw
```

Caveats

Accurate offset determination is critical; misalignment will result in failure to detect VSS structures.
Output includes creation times in UTC, enabling precise temporal correlation with other artifacts.
Always run these tools in a controlled analysis environment to avoid any unintended modification of the source image.
For comprehensive examination, pair vshadowinfo output with subsequent use of vshadowmount to expose individual snapshots.

The next utility in the libvshadow toolset, vshadowmount, enables forensic examiners to expose all available Volume Shadow Copies (VSCs) from a disk image as independent raw disk images. This allows seamless analysis within Linux-based forensic environments. The workflow typically begins with a preliminary step to convert a compressed forensic image (e.g., EnCase E01 format) into a raw representation using ewfmount—another open-source utility authored by Joachim Metz. This creates a virtual raw disk file (ewf1) in the specified mount directory without physically decompressing the source evidence.

Once the raw image is accessible, vshadowmount is executed against it. The tool parses the VSS catalog and presents each shadow copy as a separate virtual raw disk image (e.g., vss1, vss2). These can then be mounted as read-only NTFS filesystems for detailed examination.

In the example workflow, a preliminary step is performed to expose the compressed EnCase E01 forensic image as a raw disk representation mounted at /mnt/ewf_mount/. This is achieved using the ewfmount utility, a component of the libewf project authored by Joachim Metz—the same developer responsible for the libvshadow toolset, though ewfmount remains a distinct utility.

This step is required because the libvshadow suite operates exclusively on raw disk images. Upon execution, ewfmount creates a virtual file named ewf1 within the mount directory. This is not a physical file on disk but a FUSE-based virtual representation that provides transparent access to the underlying raw disk content encapsulated in the compressed E01 forensic image.

The partition of forensic interest—highlighted in the partition table above—resides at a starting offset of 1,259,520 sectors, corresponding to 644,874,240 bytes. This precise byte offset is used with the -o parameter to enable vshadowinfo to correctly locate and parse the Volume Shadow Copy Service structures within the target NTFS volume on the physical disk image.

The output of vshadowinfo confirms the presence of two persistent Volume Shadow Copies (VSCs), consistent with prior expectations. This validates the accuracy of the identified partition offset and indicates that historical snapshots remain available for further examination within the target NTFS volume.

The vshadowmount utility is then applied to the virtual raw disk file (ewf1) to expose the contained Volume Shadow Copies (VSCs) as individual virtual raw disk images. In the example shown above, the two persistent VSCs identified are presented as vss1 and vss2 within the target /mnt/vss mount point. The final step consists of mounting a selected shadow copy image (e.g., vss2) as a read-only NTFS filesystem using the native Linux mount command.

Mounting multiple Volume Shadow Copies (VSCs) can be efficiently automated using a Bash 'for loop.' This approach allows the simultaneous mounting of all available snapshots as read-only NTFS filesystems. To prepare for the loop, the base directory /mnt/shadow_mount/ must first be populated with a corresponding subdirectory for each expected shadow copy (e.g., /mnt/shadow_mount/vss1/, /mnt/shadow_mount/vss2/, etc.). These subdirectories serve as dedicated mount points for the individual virtual disk images exposed by vshadowmount.

Step 1: Mount the Forensic Disk Image

sudo ewfmount LoneWolf.E01 /mnt/ewf_mount/

Step 2: Expose Volume Shadow Copies

sudo vshadowmount -o [offset] /mnt/ewf_mount/ewf1 /mnt/vss/

Step 3: Mount All Available Snapshots as Logical Filesystems

Use a Bash for loop to automatically mount every exposed Volume Shadow Copy (VSC) as a read-only NTFS volume:

cd /mnt/vss
for i in vss*; do 
    sudo mount -o ro,show_sys_files,streams_interface=windows "$i" /mnt/shadow_mount/"$i"; 
done

Step 4: Search Across Mounted Snapshots

cd /mnt/shadow_mount
find . -type f | grep -i <search_term>

This workflow enables efficient, systematic access to multiple historical Volume Shadow Copies. The for loop automates the mounting process across all available snapshots (vss1, vss2, etc.), while the final find command facilitates rapid keyword or pattern-based searches across the entire temporal dataset recovered from the shadow copies.

Recommended Enhancements

Add error handling and logging to the loop for production forensic use.
Always verify successful mounts with mount | grep shadow_mount before searching.

Shadow Copy Destruction as an Anti-Forensic Vector

The preceding sections address VSS as a recovery mechanism, but a mature IR narrative must equally address VSS as an attacker target. Enumeration and eradication of shadow copies constitute a well-established recovery-inhibition technique, formally cataloged under MITRE ATT&CK T1490 (Inhibit System Recovery), and are near-ubiquitous in ransomware pre-encryption staging as well as in general anti-forensic tradecraft aimed at foreclosing rollback and impeding examiner access to historical snapshots.

Execution Vectors

Adversaries destroy shadow copies through several mechanisms, presented here in ascending order of stealth:

vssadmin.exe — the canonical and most heavily instrumented method: vssadmin delete shadows /all /quiet. Trivially detected via command-line logging.
wmic.exe — wmic shadowcopy delete, invoked via the Win32_ShadowCopy WMI class, functionally equivalent but traverses a distinct telemetry path.
diskshadow.exe — a native, less-monitored utility scriptable for the same effect, frequently substituted by operators specifically to evade vssadmin/wmic-keyed detection logic.
Direct VSS API invocation — the most evasive vector, in which the adversary links against VssApi.dll and calls IVssBackupComponents::DeleteSnapshots directly from a custom binary or reflectively loaded payload, entirely bypassing command-line telemetry. This requires SeBackupPrivilege/SeRestorePrivilege and elevation, but generates no process command-line artifact whatsoever — examiners must pivot to image-load and API-level telemetry to catch it.

Detection and Reconstruction Artifacts

Process creation telemetry: Security Event ID 4688 or Sysmon Event ID 1, filtered on vssadmin.exe/wmic.exe process names with command-line arguments matching *delete*shadow* or *resize*shadowstorage*. Parent-process lineage is critical here — legitimate backup agents and deployment tooling will match the same string pattern, so the analyst must correlate parent.process, user.id, and timing against known-good VSS-management workflows before attributing malicious intent.
WMI-Activity Operational log: Event ID 5857 (operation invoked) and 5858 (operation failure) when the WMI path is used, keyed on ProviderName: MSVSS__PROVIDER and Win32_ShadowCopy operations — this is the only reliable artifact when the adversary avoids wmic.exe itself and drives the WMI provider through an alternate host process (e.g., PowerShell, scripting engines).
VSS provider event log (Application): Event ID 8222 records shadow copy deletion at the provider level and persists independent of command-line auditing configuration, making it a valuable fallback when process-creation logging was disabled or was itself a casualty of the same anti-forensic pass.
Image-load telemetry: Sysmon Event ID 7, flagging VssApi.dll (and associated ResUtils.dll) loaded by a process with no legitimate backup or imaging lineage — the primary detection surface for the direct-API vector described above, where command-line and even standard VSS event logging are absent entirely.
USN Journal and $LogFile correlation: Differential store files reside within System Volume Information; their deletion, even where no corresponding entry persists in the MFT, is recorded as a $DELETE reason code in the USN Journal, with a corroborating transaction in $LogFile. Cross-referencing these against the timestamped event-log artifacts above yields a tightly bounded window for the deletion event, independent of whether the adversary subsequently cleared the event logs themselves.
VSS diagnostic artifacts: C:\Windows\Logs\Vss\ retains operational error/warning detail from the VSS service, and HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag may retain residual timestamp data from the last shadow-copy operation — both worth enumerating even when primary event-log evidence has been tampered with.

Shadow-copy deletion should rarely be assessed in isolation. Its evidentiary weight comes from temporal correlation: pairing the deletion timestamp against subsequent file encryption, service termination, or event-log clearing (T1070.001) establishes a causal sequence consistent with recovery-inhibition preceding an impact-stage action, and materially strengthens the incident timeline beyond what any single artifact class can support on its own.

MITRE ATT&CK mapping: T1490 (Inhibit System Recovery); T1070.001 (Indicator Removal: Clear Windows Event Logs) where paired with log clearing.

Facebook SDK