Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
One of the first questions in almost every Windows intrusion is deceptively simple: did a given binary actually run, and when? Windows keeps several independent caches for entirely non-forensic reasons — speeding up application launches and tracking compatibility shims — that happen to answer exactly that question. Prefetch, Shimcache (AppCompatCache), and Amcache are the three most commonly used *execution artifacts* in Windows DFIR, and because they are generated by different subsystems for different purposes, they rarely agree perfectly — which is itself useful forensic information.
No single one of these three is complete or tamper-proof on its own. Prefetch can be disabled or absent on some server builds and SSD-optimized configurations; Shimcache does not reliably prove execution on older Windows versions and evicts old entries; Amcache can retain evidence of files that were deleted before ever running. The standard practice is to correlate all three (and add Sysmon Event ID 1 or Security 4688 where available) rather than to rely on any single artifact for an execution determination.
Attack Prerequisites
This is an analysis technique rather than an attack; using it effectively requires:
- Access to a disk image or live host to pull
C:\Windows\Prefetch\*.pffiles, theSYSTEMregistry hive, andC:\Windows\AppCompat\Programs\Amcache.hve. - Parsing tools — Eric Zimmerman’s
PECmd(Prefetch),AppCompatCacheParser(Shimcache), andAmcacheParser(Amcache) are the de facto standard, all free and actively maintained. - Awareness of the target Windows version, since Prefetch and Shimcache behavior (entry count, ordering semantics, and whether Shimcache reflects actual execution) differs meaningfully between Windows 7, 10, and 11 and between workstation and server SKUs.
- Corroborating sources (Security 4688, Sysmon Event ID 1, or the $STANDARD_INFORMATION timestamps of the binary itself) to resolve conflicts between the three caches.
How It Works
Prefetch (C:\Windows\Prefetch\<NAME>-<HASH>.pf) is generated by the Windows Cache Manager to speed up application launch by pre-loading files the application is known to touch early. Each .pf file is named from the executable name and a hash of its path, and internally stores the number of times the program has run, the last run time, and (on Windows 8.1+) up to the last eight run timestamps, plus a list of files and directories referenced during startup — useful for reconstructing what a malicious binary touched on first execution. Prefetch is controlled by the EnablePrefetcher/EnableSuperfetch values under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters, and is disabled by default on some server editions.
Shimcache (Application Compatibility Cache) lives in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache and exists to let the Application Compatibility subsystem quickly check whether a program needs a compatibility shim applied, without re-scanning the file every launch. It records the full file path, file size, and last-modified time (from $STANDARD_INFORMATION) for binaries the shim engine has evaluated. On Windows 10 and later builds, entries include an execution flag, but on many older builds Shimcache entries can exist purely because a file was *inspected* (e.g. right-clicked, or opened by an installer) without ever actually running — a frequent point of confusion. It is also an LRU-style, size-limited cache, so older entries are evicted as new ones are added, and it is only flushed to the registry (and therefore persisted) at shutdown or via a periodic write.
Amcache (C:\Windows\AppCompat\Programs\Amcache.hve), introduced in Windows 8, is a separate registry hive that superseded the older RecentFileCache.bcf and tracks a much richer record per executable: full path, SHA1 hash of the file, file size, PE linker timestamp, publisher (from the Authenticode signature, if present), and first-installation/first-seen time. Because it stores a SHA1, Amcache is uniquely useful for confirming a binary’s identity (e.g. matching against VirusTotal or threat intel) and for catching cases where an attacker renamed a known-bad binary to evade name-based detection.
Practical Example / Configuration
A standard triage sequence parses all three sources to CSV with the Eric Zimmerman tool suite, ready for correlation in Timeline Explorer or a spreadsheet:
# Prefetch -- parse every .pf file in the default location
PECmd.exe -d C:\Windows\Prefetch --csv C:\out -q
# Shimcache -- parse from a live SYSTEM hive or an offline copy
AppCompatCacheParser.exe -f C:\cases\SYSTEM --csv C:\out
# Amcache -- parse the hive, -i also pulls the inventory/driver subkeys
AmcacheParser.exe -f C:\cases\Amcache.hve --csv C:\out -i
Key CSV fields to correlate across the three outputs: Prefetch gives RunCount and up to 8 LastRun timestamps per executable name; Shimcache gives LastModifiedTimeUTC and full path with no run count; Amcache gives SHA1, FileKeyLastWriteTimestamp (first-seen), and Publisher. A binary present in Amcache with a SHA1 that resolves to a known-malicious hash, a matching Prefetch entry with a non-zero RunCount, and a Shimcache entry with a path that does not match its apparent legitimate location (e.g. C:\Windows\Temp\svchost.exe) is a high-confidence execution finding.
Walkthrough / Exploitation
Given a suspected malicious binary named update.exe, the investigative sequence is to establish presence, then execution, then identity:
# 1. Does Amcache know about it at all, and what is its hash/publisher?
AmcacheParser.exe -f Amcache.hve --csv out -i
# -> filter out.csv for 'update.exe', note SHA1 and FileKeyLastWriteTimestamp
# 2. Was it ever flagged by the compatibility engine (implies presence,
# not necessarily execution, on many builds)?
AppCompatCacheParser.exe -f SYSTEM --csv out
# -> filter for the same path, compare LastModifiedTimeUTC to the file's own MFT dates
# 3. Did it actually run, how many times, and when?
PECmd.exe -f 'C:\Windows\Prefetch\UPDATE.EXE-3F2A1B9C.pf' --csv out -q
# -> RunCount and up to 8 LastRun timestamps confirm execution history
Pivot the recovered SHA1 from Amcache against VirusTotal or internal threat intel to establish whether the binary is known-malicious, and cross-reference the Prefetch ‘files referenced’ list (also parsed by PECmd) to see what other files and DLLs the binary touched at first launch — frequently revealing dropped second-stage payloads.
Note: Shimcache’s insertion-order/LRU eviction means a busy system can roll an entry out of the cache within days; Amcache retains first-seen history for much longer and does not require the binary to have executed — it records files merely present on disk during a periodic inventory scan, so an Amcache hit alone is not proof of execution, only of presence.
Opsec / Analyst tip: A file renamed after being dropped (e.g.
mimikatz.exerenamed tosvchost.exe) still carries its original SHA1 in Amcache — always pivot on the hash, not the filename, when hunting for known tools across a fleet of Amcache exports.
Detection and Defense
These artifacts are read-only evidence sources rather than controls themselves, but they inform both hunting and hardening:
- Preserve Prefetch, the SYSTEM hive, and Amcache.hve in every triage collection — they are small and extremely high-value.
- Hunt for Amcache/Shimcache path-SHA1 mismatches at scale (a known-good filename with an unexpected hash, or vice versa) to catch binary renaming and replacement.
- Do not rely on Prefetch alone on servers where it may be disabled by default — check
EnablePrefetcherbefore treating its absence as evidence of non-execution. - Layer with Sysmon Event ID 1 / Security 4688 wherever possible — these are contemporaneous, execution-confirmed records that resolve ambiguity in the compatibility-cache artifacts.
- Centrally collect Amcache SHA1 hashes across the fleet for retroactive hunting the moment new threat intelligence identifies a malicious hash.
Real-World Impact
Execution-artifact analysis is a routine, almost universal step in Windows IR and is frequently the deciding factor in scoping how many hosts were actually compromised versus merely touched. Ransomware affiliates and post-exploitation frameworks that rename tools to blend in (a very common evasion pattern) are regularly unmasked by an Amcache SHA1 that matches a known-malicious file despite an innocuous file name, which is why Amcache hash pivoting is a standard technique in enterprise-scale compromise assessments.
Conclusion
Prefetch, Shimcache, and Amcache were never designed as forensic tools, but their overlapping, imperfect records of what has run and what has merely been seen on a Windows host make them indispensable for answering the execution question in an investigation. None is authoritative alone; correlating all three, and hashing everything through Amcache’s SHA1 field, is what turns them into a defensible finding.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments