Shimcache / AppCompatCache

Every time Windows shuts down, it writes the Application Compatibility Cache — commonly called Shimcache — to the SYSTEM registry hive. This artifact records metadata about executables the operating system evaluated for compatibility shims, and its entries persist even after the original files are deleted from disk. For investigators, Shimcache is often the only proof that a specific tool ever existed on the system.

What Is Shimcache?

The Application Compatibility Cache, known in the forensic community as Shimcache or AppCompatCache, is a Windows subsystem that records metadata about executable files the operating system evaluates for application compatibility. When an executable is accessed (opened, executed, or in some cases merely traversed during directory enumeration), Windows checks it against the Application Compatibility Database (sysmain.sdb) to determine if any compatibility shims — small patches that modify API behavior — need to be applied. The cache stores the results of these lookups to avoid repeated disk reads on subsequent accesses.

The cache is maintained in memory during system operation and flushed to the SYSTEM registry hive only during an orderly shutdown. This means the on-disk version of Shimcache represents the state of the cache at the last clean shutdown. If a system crashes or loses power unexpectedly, the most recent entries will be lost. Conversely, entries from weeks or months ago may persist if the system has not been rebooted frequently, because older entries are only evicted when the cache reaches its maximum capacity of approximately 1,024 entries.

The forensic value of Shimcache lies in its ability to prove that a specific file, at a specific path, with a specific last-modified timestamp, existed on the system at some point. Even if the file has been securely deleted, even if Prefetch has been cleared, even if the MFT entry has been overwritten — the Shimcache entry persists in the registry until it is pushed out by newer entries or the registry hive is tampered with.

Location & Format

Registry Path

Binary Format by OS Version

The binary structure of the AppCompatCache value has changed across every major Windows release. Each version uses a different header signature, entry size, and field layout. Parsing tools must identify the OS version from the header magic bytes before interpreting the data.

What It Reveals

Shimcache entries contain a limited but highly valuable set of metadata about each file the operating system evaluated. The following investigative questions are directly answerable from Shimcache data:

• Did a specific file ever exist at a specific path? — The full file path is recorded, including the drive letter, directory structure, and filename. This proves placement even after deletion.
• What was the file’s last modification timestamp? — The $STANDARD_INFORMATION last-modified time is captured at the moment of cache insertion. This is the timestamp from the NTFS metadata, not the Shimcache insertion time.
• Was the file executed (Windows 7 only)? — The InsertFlag bit on Windows 7 and earlier distinguishes between files that were merely evaluated and files that were actually launched.
• What is the approximate order of file access? — Shimcache entries are ordered: the most recently accessed file is at the top (position 0), and older entries are pushed down. Position in the cache provides relative temporal ordering.
• Were tools staged in suspicious directories? — Paths like C:\Users\Public\, C:\ProgramData\, C:\Windows\Temp\, or C:\Perflogs\ for unexpected executables are immediately suspicious.
• Were files renamed to masquerade as legitimate tools? — An entry for C:\Windows\System32\svchost.exe with a last-modified timestamp that does not match the legitimate OS file suggests binary replacement or masquerading (T1036).

Forensic Use Cases

1. Proving Deleted Malware Existed

An attacker deploys a credential harvesting tool to C:\Windows\Temp\svc_update.exe, uses it to dump LSASS, then deletes the binary and clears Prefetch. The MFT entry is overwritten by subsequent file operations. However, Shimcache retains the full path and the file’s last-modified timestamp. The investigator can prove the file existed, determine approximately when it was placed relative to other executables, and correlate the last-modified time with known malware build timestamps from threat intelligence feeds.

2. Lateral Movement Reconstruction

During a network intrusion, the attacker uses PsExec to execute tools on remote hosts. Each target machine’s Shimcache records the PsExec service binary (PSEXESVC.exe) along with whatever payload was deployed. By collecting Shimcache from every endpoint and comparing entry positions, the investigator can reconstruct the order in which machines were compromised and identify the lateral movement path through the network.

3. Insider Threat Tool Usage

A departing employee brings a USB drive containing data collection utilities. They run robocopy.exe with specific flags to copy proprietary data, then remove the USB and delete any evidence of the tool. Shimcache records the path E:\Tools\robocopy.exe (or the path it was copied to locally), proving the tool was present on the system even though the USB is no longer connected and the file no longer exists on any local drive.

4. Timestomping Detection

Shimcache records the $STANDARD_INFORMATION last-modified timestamp at the time of cache insertion. If an attacker timestomps a binary after it has been cached, the Shimcache entry retains the original timestamp. Comparing the Shimcache timestamp against the current $SI timestamps in the MFT can reveal timestomping activity — a discrepancy between the two is strong evidence of anti-forensics (T1070.006).

5. Validating Timeline Gaps

When other artifacts (Prefetch, Event Logs, USN Journal) have gaps due to retention limits or cleanup, Shimcache can fill in the blanks. Because it retains up to 1,024 entries and is only flushed on shutdown, a system that reboots infrequently may have Shimcache entries spanning weeks or months — far beyond the typical 128-entry Prefetch limit or the 7-day default Event Log retention.

Acquisition Methods

Live System — Registry Export

:: Export the SYSTEM hive using reg.exe (requires elevation)
reg save HKLM\SYSTEM C:\Evidence\SYSTEM_hive /y

:: Alternative: Use KAPE for targeted collection
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target RegistryHives

:: Alternative: Volume Shadow Copy for locked hive access
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\config\SYSTEM C:\Evidence\SYSTEM

Live System — Memory-Based Collection

# Volatility 3: Extract Shimcache from memory image
# This captures the LIVE in-memory cache, not the stale on-disk version
vol -f memory.raw windows.shimcachemem

# Velociraptor: Remote live collection via VQL
# Artifact: Windows.Registry.AppCompatCache
# This parses the registry directly from the live system

Forensic Image — Direct Extraction

# Mount the forensic image read-only
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy the SYSTEM hive
cp /mnt/evidence/Windows/System32/config/SYSTEM /analysis/shimcache/

# Also collect transaction logs for dirty-hive recovery
cp /mnt/evidence/Windows/System32/config/SYSTEM.LOG* /analysis/shimcache/

Parsing Tools & Analysis

Parsing with AppCompatCacheParser

:: Parse Shimcache from an offline SYSTEM hive
AppCompatCacheParser.exe -f C:\Evidence\SYSTEM --csv C:\Analysis\Shimcache_Output

:: Output columns: ControlSet, CacheEntryPosition, Path,
:: LastModifiedTimeUTC, Executed (Win7 only), Duplicate

:: Parse with specific ControlSet
AppCompatCacheParser.exe -f C:\Evidence\SYSTEM --csv C:\Analysis\ -t --cs 1

Parsing with ShimCacheParser.py (Mandiant)

# Clone the Mandiant ShimCacheParser repository
git clone https://github.com/mandiant/ShimCacheParser.git

# Parse a SYSTEM hive
python ShimCacheParser.py -i /analysis/shimcache/SYSTEM -o /analysis/shimcache/output.csv

# Output in bodyfile format for timeline integration
python ShimCacheParser.py -i /analysis/shimcache/SYSTEM -t -o /analysis/shimcache/bodyfile.txt

Analysis Script — Suspicious Path Detection

# Identify executables in suspicious staging directories

import pandas as pd

df = pd.read_csv('/analysis/shimcache/AppCompatCache.csv')

# Define suspicious path patterns
suspicious_paths = [
    r'\\Windows\\Temp\\',
    r'\\ProgramData\\',
    r'\\Users\\Public\\',
    r'\\Perflogs\\',
    r'\\Recycle',
    r'\\AppData\\Local\\Temp\\',
]

import re
pattern = '|'.join(suspicious_paths)
hits = df[df['Path'].str.contains(pattern, case=False, regex=True)]

print(f"Suspicious entries: {len(hits)}")
print(hits[['CacheEntryPosition', 'Path', 'LastModifiedTimeUTC']].to_string())

Sample Output

Suspicious entries: 4
   CacheEntryPosition  Path                                                           LastModifiedTimeUTC
   3                   C:\Windows\Temp\svc_update.exe                                 2026-02-14 03:22:18
   7                   C:\ProgramData\Microsoft\Crypto\RSA\beacon.exe                 2026-02-13 22:15:41
   12                  C:\Users\Public\Documents\mimikatz.exe                          2026-02-13 18:30:02
   45                  C:\Perflogs\procdump64.exe                                      2026-01-28 11:44:19

Retention & Persistence

Anti-Forensics Resilience

Shimcache is stored within the SYSTEM registry hive — a critical operating system file that is locked and protected during normal operation. This makes it resistant to most standard cleanup operations, though not immune to deliberate registry manipulation.

MITRE ATT&CK Detection Mapping

Shimcache data provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Cross-Correlation

Corroborating Artifacts

References

1. Andrew Davis (Mandiant), “Caching Out the Val — Leveraging the Application Compatibility Cache in Forensic Investigations” — https://www.mandiant.com/resources/blog/caching-out-the-val
2. Eric Zimmerman, “AppCompatCacheParser” — https://ericzimmerman.github.io/
3. SANS Institute, “Application Compatibility Cache (ShimCache) Forensics” — https://www.sans.org/blog/
4. Harlan Carvey, “RegRipper — Windows Registry Forensics” — https://github.com/keydet89/RegRipper3.0
5. 13Cubed, “Shimcache Analysis for DFIR” — https://www.13cubed.com/blog
6. Microsoft, “Application Compatibility Infrastructure” — https://learn.microsoft.com
7. Volatility Foundation, “shimcachemem Plugin” — https://github.com/volatilityfoundation/volatility3
8. ForensicArtifacts.com, “Windows AppCompatCache Definition” — https://github.com/ForensicArtifacts/artifacts