VSS — Volume Shadow Copies

Volume Shadow Copies are point-in-time snapshots of entire NTFS volumes, created automatically by Windows Update, System Restore, and backup operations. When an adversary deletes configuration files, clears registry hives, or removes exfiltration tool artifacts from the live filesystem, the previous versions preserved in shadow copies frequently survive — providing forensic access to files that no longer exist anywhere else on the system.

What Is VSS?

The Volume Shadow Copy Service (VSS) is a Windows framework for creating consistent, point-in-time snapshots of volume data. Introduced in Windows XP (2001) and significantly enhanced in Windows Server 2003 and Vista, VSS operates using a copy-on-write (COW) differential storage model: when a snapshot is created, the system does not duplicate the entire volume. Instead, it tracks which disk blocks have changed since the snapshot was taken, preserving the original blocks in a dedicated shadow storage area. This means shadow copies are space-efficient — a snapshot of a 200 GB volume might consume only 3–10 GB of differential storage, depending on the rate of change.

Shadow copies are created automatically by multiple Windows subsystems. System Restore creates them before significant system changes (driver installations, Windows Updates). Windows Backup creates them as part of scheduled backup operations. System Center and group policy can schedule automatic snapshots on managed endpoints. The result is that most Windows systems have multiple shadow copies spanning days, weeks, or even months of history — each one a complete, mountable snapshot of the volume at the moment it was created.

From a forensic perspective, each shadow copy is a time machine. An investigator can mount a shadow copy and browse the filesystem as it existed at the snapshot time. Files that have been deleted, modified, or encrypted on the live volume may exist in their original form within an older shadow. Registry hives (SAM, SYSTEM, SOFTWARE, NTUSER.DAT) from previous states can be extracted and compared to the current hives, revealing configuration changes made by malware or an adversary. Browser profiles, application configuration files, and database files that have been cleaned up on the live system may persist untouched in shadow copies.

Location & Format

Shadow Copy Storage

How Copy-on-Write Works

When a shadow copy is created, VSS records the current state of all disk blocks on the volume. No data is copied at creation time — the snapshot is instantaneous. Subsequently, whenever a block is about to be overwritten by a write operation, VSS first copies the original block to the differential storage area before allowing the write to proceed. This means the shadow copy always contains the original version of every block that has changed since the snapshot was created. Blocks that have not been modified are read directly from the live volume. The result is a complete, read-only view of the volume as it existed at the snapshot time.

The differential storage grows proportionally to the rate of change on the volume. High-churn volumes (databases, build servers, heavily used workstations) consume differential storage rapidly and may cause older shadow copies to be automatically purged when the allocated space limit is reached. Low-churn volumes (relatively static servers, archive systems) may retain shadow copies spanning months.

What It Reveals

Volume Shadow Copies answer the following investigative questions:

• What did a deleted or modified file contain before the change? — Mount a shadow copy created before the deletion/modification and extract the original file. Configuration files, documents, executables, and databases can be recovered in their pre-change state.
• What were the registry hive contents before malware modified them? — Extract SAM, SYSTEM, SOFTWARE, SECURITY, and NTUSER.DAT from a shadow copy predating the compromise. Compare with current hives to identify persistence mechanisms, service installations, and configuration changes made by the adversary.
• Did an exfiltration tool’s configuration file exist on the system? — Files like rclone.conf, SSH keys, VPN configurations, and cloud storage tokens may have been deleted from the live filesystem but persist in shadow copies. A single recovered configuration file can reveal cloud storage endpoints, credentials, and exfiltration targets.
• What was the state of browser profiles before cleanup? — Browser history databases (Chrome’s History, Firefox’s places.sqlite), cookies, and saved passwords may exist in shadow copies created before the user ran a browser cleanup tool.
• Were files encrypted by ransomware recoverable? — If shadow copies were created before the ransomware executed (and if the ransomware failed to delete them), original unencrypted files can be recovered from the shadow volume.
• What changed between two points in time? — By comparing files across two shadow copies (or a shadow copy and the live volume), an investigator can identify exactly which files were added, modified, or deleted during a specific time window.
• What user activity occurred before anti-forensics cleanup? — LNK files (recent document shortcuts), Jump Lists, Prefetch files, and other user activity artifacts may survive in shadow copies even after being deleted from the live filesystem.

Forensic Use Cases

1. Configuration File Recovery (Exfiltration Tool Config)

A departing employee used rclone to exfiltrate data to a personal MEGA account, then deleted the tool and its configuration file. The live filesystem shows no trace of rclone. However, a shadow copy created five days earlier — triggered by a scheduled Windows Update — contains C:\Users\jdoe\AppData\Roaming\rclone\rclone.conf in its original state. The configuration file reveals the remote name ([mega-personal]), the storage type (mega), and the encrypted credentials. Decrypting the rclone password with the known rclone encryption key recovers the MEGA account email and password.

2. Registry Hive Comparison (Malware Persistence)

An APT operator installs a backdoor with registry-based persistence. The current SYSTEM hive shows a suspicious service (WinSvcUpdate) pointing to C:\ProgramData\svchost.exe. Extracting the SYSTEM hive from a shadow copy created two weeks earlier reveals that this service did not exist. The comparison pinpoints the exact creation window for the persistence mechanism, narrowing the compromise timeline from “sometime in the last six months” to “between March 12 and March 14.”

3. Deleted File Recovery

A malware dropper (stage2.dll) was executed, performed its function, and was deleted by the command-and-control framework. The MFT entry has been reallocated. However, a shadow copy created before the execution preserves the directory listing of the staging folder. While the dropper did not exist at the time of the shadow copy (it was deployed afterward), the directory itself existed — and other staging artifacts (scripts, configuration files) present at snapshot time are recoverable. Additionally, shadow copies created after the dropper was placed but before it was deleted will contain the actual malware binary.

4. Ransomware Recovery

Ransomware encrypts all user documents and changes extensions to .locked. The ransomware’s first action is typically to delete shadow copies via vssadmin delete shadows /all /quiet. However, if the ransomware runs with insufficient privileges, if group policy blocks shadow deletion, or if the deletion command fails for any reason, the shadow copies survive. Mounting a pre-encryption shadow copy allows recovery of original files without paying the ransom. Even partial shadow copies (where some differential blocks have been purged due to space constraints) may allow partial file recovery.

5. Browser Profile Recovery

A user clears all browser history, cookies, and cached data using Chrome’s built-in cleanup tool. On the live filesystem, the History SQLite database has been recreated with no entries. However, a shadow copy from three days ago contains the previous History database with full browsing records. Extracting and querying this database reveals the user’s browsing activity up to the point of the snapshot — including visits to file-sharing services, personal email providers, and cloud storage platforms used for data exfiltration.

Acquisition Methods

Live System — Enumerate and Access

:: List all shadow copies on the C: volume
vssadmin list shadows /for=C:

:: Output shows each shadow copy with:
::   Shadow Copy ID, Creation Time, Shadow Copy Volume
::   e.g.: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

:: Create a symbolic link to browse the shadow copy as a directory
mklink /d C:\ShadowMount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

:: Browse the mounted shadow copy
dir C:\ShadowMount\Users\jdoe\AppData\Roaming\rclone\

:: Copy a specific file from the shadow
copy C:\ShadowMount\Users\jdoe\AppData\Roaming\rclone\rclone.conf C:\Evidence\

:: Copy registry hives from the shadow
copy C:\ShadowMount\Windows\System32\config\SYSTEM C:\Evidence\SYSTEM_shadow
copy C:\ShadowMount\Windows\System32\config\SOFTWARE C:\Evidence\SOFTWARE_shadow
copy C:\ShadowMount\Windows\System32\config\SAM C:\Evidence\SAM_shadow

:: Remove the symbolic link when done
rmdir C:\ShadowMount

Live System — PowerShell Enumeration

# List all shadow copies with detailed metadata
Get-WmiObject Win32_ShadowCopy | Select-Object `
    ID, InstallDate, DeviceObject, VolumeName, `
    @{N='CreationTime';E={$_.ConvertToDateTime($_.InstallDate)}}, `
    @{N='SizeMB';E={[math]::Round($_.MaxSpace/1MB,0)}} |
    Format-Table -AutoSize

# Export all shadow copy metadata to CSV for documentation
Get-WmiObject Win32_ShadowCopy | Export-Csv C:\Evidence\vss_inventory.csv -NoTypeInformation

# Access a specific shadow copy via WMI
$shadow = (Get-WmiObject Win32_ShadowCopy)[0]
cmd /c mklink /d C:\ShadowMount "$($shadow.DeviceObject)\"

Forensic Image — libvshadow (Linux)

# Install libvshadow (part of Joachim Metz's forensic toolset)
apt-get install libvshadow-utils

# List shadow copies in a forensic image
vshadowinfo /path/to/image.E01

# Mount all shadow copies as separate volumes
vshadowmount /path/to/image.E01 /mnt/vss/

# Each shadow copy appears as a device file:
# /mnt/vss/vss1, /mnt/vss/vss2, /mnt/vss/vss3, ...

# Mount a specific shadow copy as a filesystem
mount -o ro,loop,show_sys_files /mnt/vss/vss1 /mnt/shadow1/

# Browse and extract files from the mounted shadow
cp /mnt/shadow1/Users/jdoe/AppData/Roaming/rclone/rclone.conf /analysis/vss/

Forensic Image — Arsenal Image Mounter

:: Arsenal Image Mounter (GUI workflow)
:: 1. Mount the forensic image as a virtual disk (read-only)
:: 2. Arsenal automatically detects shadow copies within the image
:: 3. Right-click the mounted volume > "Mount Shadow Copies"
:: 4. Each shadow copy is mounted as a separate drive letter
:: 5. Browse each shadow as a standard Windows filesystem

:: Arsenal CLI (command-line alternative)
ArsenalImageMounter.exe /mount /readonly /filename=C:\Evidence\image.E01
:: Shadow copies are automatically enumerable via vssadmin on the mounted volume

Parsing Tools & Analysis

Shadow Copy Comparison Script

# Compare files between a shadow copy and the live filesystem
# Identifies files that were deleted, modified, or added between snapshots

import os
import hashlib
from pathlib import Path

def hash_file(path):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        while chunk := f.read(8192):
            h.update(chunk)
    return h.hexdigest()

shadow_path = Path('/mnt/shadow1/Users/jdoe')
live_path = Path('/mnt/evidence/Users/jdoe')

# Build file inventories
shadow_files = {str(p.relative_to(shadow_path)): p for p in shadow_path.rglob('*') if p.is_file()}
live_files = {str(p.relative_to(live_path)): p for p in live_path.rglob('*') if p.is_file()}

# Files in shadow but not on live = DELETED since snapshot
deleted = set(shadow_files.keys()) - set(live_files.keys())
print(f"\nDELETED since shadow ({len(deleted)} files):")
for f in sorted(deleted)[:20]:
    print(f"  [-] {f}")

# Files in both locations with different hashes = MODIFIED
common = set(shadow_files.keys()) & set(live_files.keys())
modified = []
for f in common:
    if hash_file(shadow_files[f]) != hash_file(live_files[f]):
        modified.append(f)

print(f"\nMODIFIED since shadow ({len(modified)} files):")
for f in sorted(modified)[:20]:
    print(f"  [~] {f}")

Sample Output

DELETED since shadow (47 files):
  [-] AppData/Local/Temp/rc.exe
  [-] AppData/Roaming/rclone/rclone.conf
  [-] AppData/Local/Google/Chrome/User Data/Default/History
  [-] Documents/backup_temp/Q4_Revenue_Final.xlsx
  [-] Documents/backup_temp/Customer_List.csv
  [-] Documents/backup_temp/Board_Deck_2026.pptx
  ...

MODIFIED since shadow (12 files):
  [~] NTUSER.DAT
  [~] AppData/Local/Google/Chrome/User Data/Default/Preferences
  [~] AppData/Local/Microsoft/Windows/UsrClass.dat
  ...

Retention & Persistence

Anti-Forensics Resilience

Volume Shadow Copies are the most frequently targeted forensic artifact in ransomware attacks. Nearly every modern ransomware family includes shadow copy deletion as an early-stage action, because shadow copies provide the most straightforward path to recovering encrypted files without paying the ransom. This makes VSS the least resilient artifact against sophisticated adversaries — but the most valuable when it survives.

MITRE ATT&CK Detection Mapping

VSS analysis provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Joachim Metz, “libvshadow — Library and tools to access VSS” — https://github.com/libyal/libvshadow
2. Arsenal Recon, “Arsenal Image Mounter” — https://arsenalrecon.com
3. Microsoft, “Volume Shadow Copy Service (VSS)” — https://learn.microsoft.com
4. SANS Institute, “Volume Shadow Copy Forensics” — https://www.sans.org/blog/
5. 13Cubed, “Shadow Copy Analysis for DFIR” — https://www.13cubed.com/blog
6. Microsoft, “vssadmin command reference” — https://learn.microsoft.com
7. ForensicArtifacts.com, “Windows VSS Artifact Definitions” — https://github.com/ForensicArtifacts/artifacts
8. ShadowExplorer, “ShadowExplorer — Browse Shadow Copies” — https://www.shadowexplorer.com