What the Amcache actually tells you in a DFIR investigation

Most write-ups about the Amcache treat it as a clean record of "every program that ran on this host". It isn't. After a few hundred incidents you stop trusting that framing and start treating the hive as what it actually is: a noisy, asynchronous side effect of the Program Compatibility Assistant doing its job, which happens to be very useful in DFIR because it survives uninstalls, file deletions and registry tampering far better than most people expect.

This post is the version of the conversation I would have with a new analyst on my team. What the hive proves, what it does not, and the specific places where I have watched investigations go sideways.

Where the hive lives, and why that already matters#

C:\Windows\AppCompat\Programs\Amcache.hve on Windows 7 SP1 and later. It is a registry hive in the regular regf format, which means every parser that can read NTUSER.DAT can in principle read it. What makes it forensically interesting is that it gets transparently written by compattelrunner.exe whenever the Program Compatibility Assistant inventories the system, which happens on schedule (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) and on certain installer/uninstaller events.

A few practical consequences of that:

• The hive lives outside the user profile, so it is per-machine, not per-user. You cannot attribute an entry to a specific account from the hive alone.
• The Appraiser task can be disabled by group policy, by certain "telemetry remover" scripts, and by some EDR baseline configurations. On those hosts the hive may be stale for weeks. I have inherited investigations where the IR team assumed the Amcache was a smoking gun before checking that the task had actually been running.
• Because it is a regular hive, it has a transaction log pair (Amcache.hve.LOG1 / Amcache.hve.LOG2). Always acquire those alongside the main file. Replaying them recovers entries that were in flight at the time of acquisition and occasionally surfaces records that never reached the live hive at all.

What an entry actually proves#

The honest answer is: a file was present on disk at a moment the Appraiser walked the filesystem. Nothing more.

This is where the most common mistakes start. The hive does not prove execution. It proves existence at scan time. Operationally, that distinction matters for three reasons:

1. Files dropped and deleted between Appraiser runs leave nothing behind. A red team operator who knows what they are doing can stage and remove a tool inside a single scan window. The Amcache will never mention it. Pair the hive with Prefetch and Sysmon / Security event logs before claiming "no evidence of execution".
2. Inventory of an installer is not execution of the payload. When Setup ran, Appraiser indexed everything it copied into Program Files. That includes shellcode launchers and bundled exfil tools that were never invoked. The presence of evil.exe under InventoryApplicationFile is interesting, not damning.
3. Network-share binaries show up too. UNC paths get inventoried when Appraiser sees them mounted. If a user double-clicked a file off \\fileserver\public\, the entry can look indistinguishable from a locally installed binary. Read the path carefully.

What the hive does prove, and reliably, is that the file existed with a particular SHA-1 hash at a particular point in time. That is enough to pivot — to threat intel, to VirusTotal, to other hosts in the estate — even if the on-disk file is long gone. This is the single most useful thing the Amcache gives you, and it is the reason I always grab the hive before anything else on a host where I suspect file deletion.

The timestamps will mislead you if you let them#

There are at least five timestamp-shaped fields scattered across the keys you care about, and they do not all mean the same thing. The names are not self-explanatory, the documentation is thin, and the values reflect different events depending on the Windows build.

A short field guide that has held up across Win7, Win10 and Win11:

• FileId is not a timestamp. It is a SHA-1 hash prefixed with 0000. People keep tripping on this in scripts.
• LinkDate (where present) is the PE header's compile timestamp. It is attacker-controlled. Treat it as metadata about the binary, not about when it touched the machine.
• The key's LastWrite time on InventoryApplicationFile\<id> is, in practice, the most useful proxy for "Appraiser noticed this file". It is not file creation or file execution.
• InstallDate under InventoryApplication is what the installer reported. MSI installers usually fill it in honestly. Loosely-packaged installers and many malware droppers do not, so do not rely on it for adversary timelines.
• Build a super-timeline pivoting through the MFT and the USN journal before you commit to any narrative built on Amcache timestamps alone. Cross-validation is cheap; being wrong in the final report is not.

The fields that earn their keep#

After ProgramId and SHA-1, the field I touch most often is OriginalFileName under InventoryApplicationFile. It is taken from the PE's version resource and is harder for sloppy attackers to scrub than LowerCaseLongPath. I have used it to tie a renamed svchost.exe dropped in \AppData\Local\Temp\ back to its real identity (mimikatz.exe) because the resource block was never edited.

BinaryType is also worth reading — pe32_file versus pe64_file versus xbox_one_pkg_file (yes, really). Mismatches between BinaryType and the path can be a tell on packed or repackaged samples.

The InventoryApplicationShortcut and InventoryDeviceContainer keys are easy to overlook. The shortcut subkey records .lnk files Windows examined, including those for removable media — sometimes the only surviving evidence that a user opened a file from a USB stick that has since walked out of the building. Pair these with the LNK parser and the shim cache for the strongest claim.

Anti-forensics: what attackers can and cannot quietly do#

The hive is a regular registry file. Anyone with SYSTEM can write to it. In practice, three patterns show up:

• Wholesale deletion. Amcache.hve is locked while Windows is running, so attackers either kill compattelrunner and the registry process before deleting, or queue a Pending File Rename. Deletion is easy to detect — the file should always be there on a healthy host — but you lose the historical content. Hope you have a recent backup or shadow copy.
• Targeted key deletion. Removing specific subkeys under InventoryApplicationFile to scrub a particular binary. Possible, but: the operation itself updates the parent key's LastWrite, and the transaction logs may still hold the old record. I have recovered ~30% of "deleted" entries from .LOG1/.LOG2 in cases where the attacker did not also clear those.
• Trusted-vendor masquerade. Setting the PE version resources on a dropped tool to mimic a Microsoft component. This survives into the Amcache, but it does not change the SHA-1. Hash lookup beats string lookup every time.

The category attackers do reach for, when they are competent, is disabling the Compatibility Appraiser task in the first place. On a host where the Amcache is suspiciously empty for the period of interest, check the Task Scheduler history in Microsoft-Windows-TaskScheduler%4Operational.evtx before assuming the absence of evidence is evidence of absence.

A workflow that actually survives review#

What I do, in order, on a host where the Amcache matters:

1. Acquire Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 together. If on a live system, use a VSS snapshot or a tool that handles the lock correctly. Do not copy the live file with xcopy.
2. Replay the logs. Most parsers do this automatically; verify by checking the recovered hive opens without warnings.
3. Pull SHA-1, OriginalFileName, LowerCaseLongPath and the key's LastWrite for every InventoryApplicationFile entry. That is the working set.
4. Filter for paths in user-writable directories (\Users\*\AppData\, \Users\Public\, \ProgramData\ outside known-vendor subdirs, C:\Windows\Temp\, C:\PerfLogs\). Most adversary activity lands there.
5. Hash-pivot the survivors. Anything that is not signed by a known vendor or known to VirusTotal goes onto the list to corroborate elsewhere.
6. Corroborate. The strongest claims pair an Amcache row with a Prefetch hit, a Sysmon process create, or a Security 4688. Anything based on the hive alone gets the caveat "evidence of file presence; execution not corroborated".

That last bullet is the one I find myself enforcing on every report.

Reading the hive without leaving the browser#

The parser on this site reads Amcache.hve entirely in your browser, including transaction-log replay. Drop the hive in and it returns a flat table of InventoryApplicationFile entries with the fields above, ranked by LastWrite. Filter, hash-pivot, export. No upload, which matters when the hive came from a regulated environment.

Further reading#

• Yogesh Khatri's Amcache.hve in Windows 8 — the original public reverse engineering. Still the best single reference for the field layout.
• Eric Zimmerman's AmcacheParser — gold-standard offline tool. The output schema is essentially the de-facto industry standard.
• MITRE ATT&CK T1070.009 Clear Persistence — for context on what well-resourced attackers do about hives like this.

If you take one thing away: hash first, path second, time third. The Amcache is at its best when you treat it as a hash index that happens to know which files Windows saw, and at its worst when you treat the timestamps as ground truth.