System Restore Points

System Restore Points are forensic time capsules — they capture registry hives, driver files, and system configuration at specific moments before significant changes. When an attacker modifies the registry, replaces system binaries, or tampers with security policy, the original state often survives in a restore point the adversary never knew existed.

What Are System Restore Points?

System Restore is a Windows feature introduced in Windows ME and substantially redesigned in Windows Vista to use the Volume Shadow Copy Service (VSS). It creates automatic snapshots of critical system files before events such as driver installations, Windows updates, and application installs. These snapshots contain copies of registry hives, system-protected files, COM+ databases, and WMI repositories — everything needed to roll the system back to a known-good state.

From a forensic perspective, restore points provide historical copies of registry hives and system files that may have since been modified by attackers, malware, or anti-forensics tools. If an adversary modifies HKLM\SYSTEM to install a malicious service, the pre-compromise version of the SYSTEM hive may still exist in a restore point created before the attack. Similarly, if a threat actor replaces sethc.exe with cmd.exe for sticky-key backdoor access, the original binary may survive in the restore point’s file store.

On modern Windows (Vista+), restore points are implemented as VSS snapshots stored in C:\System Volume Information\. The VSS framework maintains block-level differential snapshots of the volume, allowing the entire volume to be viewed as it existed at the snapshot time. Older Windows XP restore points used a file-copy mechanism that stored individual file backups in numbered RP### directories.

Location & Format

File Paths

VSS Architecture (Vista+)

On Vista and later, System Restore uses VSS snapshots rather than file copies. The VSS provider maintains a copy-on-write differential store: when a block on the volume is about to be overwritten, the original block is saved to the diff area before the write proceeds. This means each snapshot represents the complete volume state at a point in time, accessible by mounting the shadow copy. The diff store grows as more blocks are modified between snapshots; Windows automatically purges the oldest snapshots when the allocated space (typically 5–10% of volume) is exceeded.

What It Reveals

System Restore Points answer forensic questions that cannot be answered by examining only the current system state:

• What did the registry look like before the compromise? — Comparing current hives to restore-point copies reveals every modification made by the attacker: new services, Run keys, firewall exceptions, scheduled tasks.
• Were system binaries replaced? — Hash comparison of critical executables (sethc.exe, utilman.exe, osk.exe) between the current state and the restore point detects binary replacement attacks.
• What drivers were installed? — The SYSTEM\CurrentControlSet\Services key in the restore-point SYSTEM hive shows which drivers existed before the attack.
• When was the system last known-good? — The restore point creation timestamp establishes the latest point at which the system was in an uncompromised state.
• What Group Policy was in effect? — Registry-based policy settings captured in the SOFTWARE hive show pre-attack security configuration.
• Were security tools disabled? — Comparing Defender/AV registry keys between restore point and current state proves an attacker disabled protections.
• What user accounts existed? — The SAM hive in a restore point shows user accounts that existed at that time, revealing account creation/deletion activity.
• What network configuration was active? — TCP/IP parameters, DNS settings, and interface configurations are stored in the SYSTEM hive.

Forensic Use Cases

1. Persistence Mechanism Discovery

An incident response engagement discovers a compromised host with no obvious persistence mechanism. The attacker has modified registry keys to install a service that loads a DLL from C:\Windows\Temp\. By mounting the most recent VSS snapshot and extracting the SYSTEM hive, the investigator compares the Services key tree and identifies the exact service entry that was added post-compromise, including the service name, DLL path, and start type.

2. Ransomware Pre-Encryption State Recovery

Ransomware typically deletes VSS snapshots as one of its first actions. However, if the ransomware execution was interrupted or if the vssadmin delete shadows command failed (e.g., due to insufficient privileges on the shadow copy provider), surviving snapshots contain the pre-encryption file system. Entire directories of unencrypted files can be recovered by mounting the surviving shadow copy.

3. Security Tool Tampering Timeline

An attacker disables Windows Defender by modifying HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware. The restore-point SOFTWARE hive shows this value did not exist before the attack, proving the attacker explicitly disabled endpoint protection. The restore point timestamp establishes the latest known-good configuration.

4. Backdoor Binary Detection

An attacker replaces C:\Windows\System32\utilman.exe with a copy of cmd.exe to enable unauthenticated command-line access at the login screen. The restore-point copy of utilman.exe has a different hash than the current file, proving the replacement. The legitimate file can be recovered from the shadow copy for hash verification against Microsoft’s catalog.

5. Deleted File Recovery

Files deleted after a restore point was created may still exist in the shadow copy. If the restore point was taken at 14:00 and the attacker deleted their tooling at 16:00, mounting the 14:00 shadow copy provides access to the original files. This is particularly valuable for recovering malware samples that the attacker cleaned up.

Acquisition Methods

Live System — VSS Enumeration

:: List all available shadow copies
vssadmin list shadows

:: Create a symbolic link to access a specific shadow copy
mklink /d C:\ShadowMount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

:: Extract registry hives from the shadow copy
copy C:\ShadowMount\Windows\System32\config\SYSTEM C:\Evidence\VSS_SYSTEM
copy C:\ShadowMount\Windows\System32\config\SOFTWARE C:\Evidence\VSS_SOFTWARE
copy C:\ShadowMount\Windows\System32\config\SAM C:\Evidence\VSS_SAM

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

Forensic Image — VSS Extraction

# Use libvshadow to enumerate shadow copies in a forensic image
vshadowinfo /path/to/image.E01

# Mount a specific shadow copy
vshadowmount /path/to/image.E01 /mnt/vss

# List available shadow copies (appear as vss1, vss2, etc.)
ls /mnt/vss/

# Mount a specific VSS volume
mount -o ro,loop /mnt/vss/vss1 /mnt/shadow1

# Extract registry hives from the shadow copy
cp /mnt/shadow1/Windows/System32/config/SYSTEM /analysis/vss/
cp /mnt/shadow1/Windows/System32/config/SOFTWARE /analysis/vss/

Parsing Tools & Analysis

Registry Diff Analysis

# Mount VSS hive and current hive, then compare Services keys
reg load HKLM\VSS_SYSTEM C:\Evidence\VSS_SYSTEM
reg load HKLM\CURRENT_SYSTEM C:\Evidence\CURRENT_SYSTEM

# Export both Services trees
reg export HKLM\VSS_SYSTEM\ControlSet001\Services C:\Analysis\vss_services.reg
reg export HKLM\CURRENT_SYSTEM\ControlSet001\Services C:\Analysis\current_services.reg

# Diff the exports to find new/modified services
fc /N C:\Analysis\vss_services.reg C:\Analysis\current_services.reg > C:\Analysis\services_diff.txt

Retention & Persistence

Version Differences

Anti-Forensics Resilience

System Restore and VSS snapshots are commonly targeted by ransomware and sophisticated attackers, making them a moderate-resilience artifact.

MITRE ATT&CK Detection Mapping

System Restore analysis supports detection of the following techniques:

Related Artifacts & Cross-References

References

1. Microsoft, “Volume Shadow Copy Service” — https://learn.microsoft.com
2. libvshadow, “Library and tools to access VSS” — https://github.com/libyal/libvshadow
3. Arsenal Recon, “Arsenal Image Mounter” — https://arsenalrecon.com
4. SANS Institute, “VSS Forensics” — https://www.sans.org/blog/
5. Harlan Carvey, “RegRipper” — https://github.com/keydet89/RegRipper3.0
6. Eric Zimmerman, “Registry Explorer” — https://ericzimmerman.github.io/
7. 13Cubed, “Volume Shadow Copy Forensics” — https://www.13cubed.com/