Amcache vs Shimcache: which artifact answers which question
Every analyst learns the Amcache and the Shimcache (AppCompatCache) as a pair, usually badly, usually as "two registry artifacts that record execution". Both halves of that sentence are wrong. They are not both registry artifacts in any useful sense, they do not both record execution, and treating them as interchangeable is the fastest route to a report that does not survive peer review.
This post is the comparison I run through with new hires after they have written their first "evidence of execution" claim based on a Shimcache row.
What each one is, briefly#
The Shimcache lives in SYSTEM\ControlSet001\Control\Session Manager\AppCompatCache (the value name varies slightly across Windows versions; the data structure is AppCompatCache's binary blob). It is maintained by the Application Compatibility infrastructure to decide whether a shim database lookup is needed for a binary. It records up to ~1024 entries on modern Windows, FIFO, in memory, flushed to the registry at shutdown.
The Amcache lives in C:\Windows\AppCompat\Programs\Amcache.hve, a separate hive file. It is written by compattelrunner.exe on a schedule (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) and on installer events. It carries a much richer field set per entry, including SHA-1, PE version metadata, and (for some keys) install dates.
The first practical consequence: the Shimcache exists only in memory during normal operation. Pull SYSTEM from a running host without forcing a flush and you will get the entries from the last clean shutdown, not from "right now". The Amcache, by contrast, is written through to disk regularly. If you want the most recent activity on a live host, the Amcache will have it and the Shimcache will not.
What each one proves#
This is where most write-ups conflate the two, and most reports get wrong.
The Shimcache records that the kernel performed a compatibility check on a file path. On Windows XP and Windows 7, that check happened at process launch, so a Shimcache entry was a strong proxy for execution. On Windows 8 and later, the check happens at any point Windows examines the file metadata, which includes operations like file listings in Explorer, certain installer paths, antivirus on-access scans, and (depending on build) just having the file sit in a watched directory.
Read that paragraph again. On modern Windows, a Shimcache entry is not evidence of execution. It is evidence that Windows looked at the file. Mandiant called this out in 2015 and most of the community is still using the old framing. Stop doing that.
The Amcache records that the file existed at a moment Appraiser scanned the filesystem. Also not evidence of execution. But Appraiser hashes the contents, so the Amcache gives you a SHA-1 that the Shimcache cannot.
Neither artifact proves a process was created. For that you need Prefetch, Security event 4688, or Sysmon event 1, and you should be reaching for at least one of those before you write the words "the binary was executed".
Timestamps that mean different things#
The Shimcache stores a per-entry timestamp that is the file's $STANDARD_INFORMATION last-modified time on NTFS, as the kernel saw it at cache-write time. It is filesystem-truthful by default and trivially tampered with via timestomping. It is not the time the file was loaded or executed, which is the single most common misreading.
The Amcache scatters several timestamp fields across its keys. The key's LastWrite on InventoryApplicationFile\<id> is the most useful proxy for "Appraiser noticed this file". LinkDate is the PE header compile time, attacker-controlled. InstallDate under InventoryApplication is what the installer reported. There are at least two more depending on the Windows build.
Neither artifact gives you a "first executed" timestamp. Both can be made to mislead with about ten lines of attacker code. Cross-validate against the MFT, the USN journal, Prefetch, and the Security log before you commit to a timeline.
Persistence across deletion#
The Shimcache's path field will outlive the file on disk. The 4-byte size and the timestamp will outlive it too. None of those are content fingerprints, so all you have is "Windows once looked at a file by this path". If the path is in a user-writable directory and is something like \AppData\Local\Temp\update.exe, you have a lead, not a finding.
The Amcache's FileId (SHA-1) survives file deletion. That is the artifact's killer feature. If evil.exe was dropped, hashed by Appraiser, executed, and deleted, the on-disk binary is gone and the Shimcache only knows the path. The Amcache knows the path and the hash. The hash pivots to threat intel; the path does not.
If you are deciding which one to acquire first on a live system where you fear destruction of evidence, take the Amcache hive. The Shimcache will still be there in SYSTEM after a clean shutdown, but the Shimcache also gives you less, so the priority is right.
Anti-forensics: what attackers reach for#
The Shimcache is overwritten on shutdown. An attacker who triggers a reboot can flush in-memory entries and force the new write to overflow the FIFO with a thousand junk path lookups. Crude but effective. The Shimcache also lives in SYSTEM, which means it is locked tight on a running host. Acquisition requires VSS or a raw NTFS reader, not reg save.
The Amcache lives in its own hive file, which is also locked on a running host but accessible via VSS, Velociraptor's hive collector, KAPE, FTK Imager, or any tool that does the right thing with file locks. It is more straightforward to acquire and, paradoxically, more straightforward for attackers to tamper with. SYSTEM-level deletion of Amcache.hve is a one-liner. So is targeted subkey deletion. The .LOG1 / .LOG2 transaction logs often retain "deleted" entries; in my own casework I have recovered a non-trivial fraction of attacker-pruned rows from the logs.
The Compatibility Appraiser task is also the obvious anti-forensics target. Disable the scheduled task and the Amcache simply stops getting written. The Shimcache keeps running because it is a kernel-managed in-memory structure that the attacker has fewer levers against. On a host where the Amcache is suspiciously empty for the period of interest, check Microsoft-Windows-TaskScheduler%4Operational.evtx before assuming the host is clean.
What each one is best at#
The Shimcache earns its keep on:
- Older Windows (XP through 7) where the entry-on-execution semantics still held.
- Long historical reach, since the cache stores up to ~1024 entries and they persist across reboots.
- Cases where the Amcache is missing, disabled or wiped and you need a fallback list of file paths Windows has touched.
The Amcache earns its keep on:
- Modern Windows (8 onward), where it is the only built-in artifact giving you content hashes for arbitrary executables.
- Hash-pivoting to threat intel and across the estate.
- Driver investigations, where
InventoryDriverBinaryrecords.sysfiles that may have been deleted as part of a BYOVD attack. - Investigations where the binary was deleted before acquisition.
Decision table#
| Question | Use |
|---|---|
| Did this specific file's content match a known-bad hash? | Amcache (FileId) |
| Has Windows ever seen a file by this path? | Shimcache or Amcache (Shimcache for breadth, Amcache for hash) |
| Was a file present on this host yesterday, even if it is gone now? | Amcache (FileId persists) |
| Did a specific binary actually execute? | Neither alone. Prefetch + Security 4688 + Sysmon 1 |
| What kernel driver was loaded last week? | Amcache (InventoryDriverBinary) |
| What USB device was attached on this host? | SYSTEM\Enum\USBSTOR primarily; Amcache (InventoryDeviceContainer) for corroboration |
| What was the file's NTFS last-modified time when Windows looked at it? | Shimcache entry timestamp |
| When did the Compatibility Appraiser first hash this file? | Amcache InventoryApplicationFile key LastWrite |
| Did the attacker tamper with the artifact? | Both are tamperable. Check transaction logs (Amcache) and Mandiant's Shimcache analysis approach |
A working rule#
Use both, weight the Amcache higher for content and the Shimcache higher for path-only historical reach, and never let either one carry an "execution" claim by itself. The Amcache tells you Windows saw a file. The Shimcache tells you Windows looked at a file. Execution is a third question, and you need a third artifact to answer it.
Further reading#
- Mandiant's original Leveraging the Application Compatibility Cache in Forensic Investigations and the subsequent corrections about execution semantics on Windows 8+.
- Eric Zimmerman's AppCompatCacheParser and AmcacheParser.
- Andrea Fortuna's writeups on Shimcache parsing pitfalls, still readable on his blog.
- MITRE ATT&CK T1112 Modify Registry for the attacker techniques that target both artifacts.
Related posts
- What the Amcache actually tells you in a DFIR investigation
A practitioner's view on the Amcache.hve hive: what each entry really proves, where the timestamps lie to you, and the mistakes that keep showing up in incident reports.
- The Amcache timestamps, decoded
Every FILETIME and DateTime-as-string field across the Amcache keys, what each really tracks, and how Win7, Win10 and Win11 disagree about the same artifact.
- The Amcache.hve binary format, in practice
A walkthrough of the Amcache.hve on-disk structure: the regf hive layout, the subkeys that matter in DFIR, and the tools that read them without lying to you.
- SHA-1 in the Amcache: pivoting from disk to threat intel
How the Amcache FileId field becomes the most useful pivot in a DFIR investigation, why hashes beat paths, and the workflow for hash-pivoting at scale.