Registry Parser
← All articles

Amcache.hve forensics: the RegRipper amcache plugin

9 min read

Amcache is the artifact that gives you a SHA-1 hash for a file that no longer exists on disk. That single property — a recorded hash for a binary you cannot recover — is why the RegRipper amcache plugin earns a permanent slot in any Windows triage workflow. Amcache will not, on its own, prove that a program ran. But it will tell you the file was on the system, hand you its hash for pivoting, and give you PE metadata and a first-seen timestamp that no other single artifact bundles together. The trick is knowing exactly what each field means and, just as importantly, what it does not.

A separate hive, not SOFTWARE

The first thing to internalise: Amcache is its own hive. It is not a subkey of SOFTWARE, not part of SYSTEM, and not in any user's NTUSER.DAT. It lives at:

C:\Windows\AppCompat\Programs\Amcache.hve

You acquire it as a standalone file alongside the standard hives. If your collection profile only grabs SOFTWARE, SYSTEM, SAM, SECURITY, and the user hives, you are missing Amcache entirely. (See which registry hive to grab for the full triage list.) Older systems used RecentFileCache.bcf in the same AppCompat\Programs directory; Amcache.hve replaced it and has been the relevant artifact since Windows 8 and across the Windows 10 and 11 line.

Because it is a hive, it carries transaction logs (Amcache.hve.LOG1, Amcache.hve.LOG2) that may hold unflushed changes. Grab those too. As with any hive, the live file may be locked; pull it from a VSS snapshot or via a raw-disk reader if a live copy is dirty.

What the layout looks like

The internal structure of Amcache has shifted across builds, and this is where you should hedge rather than assert. The schema you find depends on the Windows version that wrote the hive. There are two layouts worth knowing.

On Windows 10 builds (1607 and later in the field), file entries live under:

Root\InventoryApplicationFile

Each child key is one file entry. The values inside carry the interesting data. The RegRipper-style reading, and what the amcache_files plugin on this site extracts, pulls these named values from each InventoryApplicationFile subkey:

  • LowerCaseLongPath — the full path of the file, lowercased.
  • ProductName — the product name from PE metadata, when present.
  • Size — file size in bytes.
  • FileId — the SHA-1, stored as a 44-character string.
  • The key's own LastWrite time, which the plugin surfaces as the recorded timestamp.

Installed-program records live separately under:

Root\InventoryApplication

Each subkey is one application known to the system. The amcache_programs plugin reads Name, Version, Publisher, and InstallDate from those keys. This is the inventory of what is installed, distinct from the per-file records.

On older builds the file layout was different. Instead of InventoryApplicationFile, file entries sat under:

Root\File\{VolumeGUID}\{FileReference}

Two levels deep: a volume GUID, then a key per file. The values there were numbered rather than named — 15 for the path, 0 for the product/name, 6 for the size, 101 for the SHA-1. The amcache_files plugin falls back to this older Root\File layout when Root\InventoryApplicationFile is empty, so a parser that handles both will work across the version range. If you are reading the raw hive by hand, do not be surprised to find numeric value names; that is the older schema, not corruption.

The SHA-1, and how it is stored

Amcache records a SHA-1 of the file. This is the field that makes the artifact disproportionately useful, so it is worth understanding its exact encoding.

The hash is not stored as a clean 40-hex-character string. On the layouts seen in the field it is a 44-character value: four leading 0000 characters followed by the 40-hex-digit SHA-1. The amcache_files plugin normalises this — it strips the 0000 prefix when the value matches 0000 followed by 40 hex digits, accepts a bare 40-hex value as-is, and returns an empty string for anything else. If your tool shows a 44-character "hash" with a leading 0000, it has not done that normalisation. Strip the prefix before you pivot.

What do you do with a SHA-1? You pivot on it. Drop it into VirusTotal, into your threat-intel platform, into your YARA-adjacent hash sets. The power here is that Amcache retains the hash even after the file is deleted from disk. An attacker who drops a payload, runs it, and securely wipes the binary leaves the file body unrecoverable — but the SHA-1 may still sit in Amcache, and a hash is enough to identify a known sample. That is the single most valuable thing Amcache does that nothing else does as cleanly.

A normalised file row from the plugin looks like:

Path:      c:\users\jdoe\appdata\local\temp\svchost.exe
Product:   (empty)
Size:      48128
SHA-1:     da39a3ee5e6b4b0d3255bfef95601890afd80709
Recorded:  2026-06-11T08:14:33Z

A binary named svchost.exe living in \AppData\Local\Temp\ with no product name is a masquerade pattern. The hash gives you the means to confirm it.

What the timestamps mean — and do not

This is the part that catches analysts who treat Amcache as an execution log. It is not one. Be precise about what the timestamps prove.

The timestamp the amcache_files plugin reports is the key's LastWrite time. The plugin labels it "Recorded (UTC)" and notes in its output that this is approximately first-seen or installed time. That framing is deliberate. The LastWrite of an InventoryApplicationFile key tracks when the system's inventory process wrote or updated that entry — broadly, when the file was first catalogued. It is a presence/first-seen indicator, not a run time.

Amcache entries are populated largely by the Microsoft Compatibility Appraiser, a scheduled task (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) that runs periodically. That has two consequences you must account for:

  1. A file can be inventoried because it exists on disk, independent of whether it was ever executed. Across builds, the precise trigger for an Amcache entry has varied, and the safe modern reading is "the file was present and seen by the appraiser," not "the file ran." Do not state in a report that an Amcache entry proves execution.
  2. The timestamps cluster around appraiser run times, not around the moments of user activity. You will see batches of entries written at the same time because the appraiser processed them together. Do not read those clusters as simultaneous activity.

So Amcache answers "was this file present, and what was its hash and metadata" with high confidence. It answers "did it run, and when" only weakly. For execution proof, you go elsewhere — and that is the next section.

How Amcache complements Shimcache and Prefetch

No single artifact carries the whole story. Amcache's role is to supply the hash and the PE metadata; the execution evidence comes from neighbours.

Shimcache (the AppCompatCache in SYSTEM) records file paths and a file-modified timestamp for binaries the system encountered, but it carries no hash and its entries are likewise about presence, not confirmed execution. Where Shimcache and Amcache both list a path, you have two independent registry sources agreeing the file was there. Shimcache also preserves ordering information within its structure that Amcache does not.

Prefetch is the actual execution artifact. A .pf file in C:\Windows\Prefetch\ means the binary ran — with run counts and the last eight (or fewer) run times. Prefetch carries no SHA-1. So the canonical pivot is: find a suspicious binary's hash in Amcache, confirm presence in Shimcache, and confirm execution in Prefetch. Three artifacts, three different guarantees, one coherent timeline.

When the binary is deleted and Prefetch has rolled over, Amcache may be all you have left — and the hash it preserves is still enough to identify the sample even when you cannot prove it ran.

Tools

  • The RegRipper amcache plugin. The canonical extractor. Read the plugin source to see exactly which keys and values it walks; the layout it targets has tracked the Windows builds described above. Output is one block per entry with path, hash, and timestamps.
  • Eric Zimmerman's AmcacheParser. A dedicated tool that handles the file and program records and emits clean CSV, with the SHA-1 already normalised. If you only want Amcache and want it in a spreadsheet, this is the fastest path.
  • The parser on this site reads Amcache.hve directly in your browser — no upload, no install — and surfaces both the file inventory (path, product, size, SHA-1, recorded time) and the program inventory (name, version, publisher, install date). See the RegRipper plugins reference for the full plugin set.

Whatever you use, check that it strips the 0000 prefix from the hash and that it labels the timestamp as a recorded/first-seen time rather than a run time. A tool that calls the LastWrite an "execution time" will lead you to overstate your findings.

Edge cases worth knowing

The transaction logs hold recent entries. Because the hive is written by a scheduled task, the most recent changes may sit unflushed in Amcache.hve.LOG1/LOG2. A parser that ignores the logs may miss the newest entries — exactly the ones that matter in a fresh-intrusion case. Acquire and replay the logs.

Empty product/publisher fields are normal. Custom-compiled malware and renamed binaries frequently carry no ProductName or Publisher. The absence is itself a weak signal: legitimate signed software usually populates these PE-derived fields. Do not discard a row because the metadata columns are blank.

Version drift is real. The schema discussion above is intentionally hedged. Microsoft has reorganised Amcache more than once, and a hive from an unusual build may use keys not covered by either layout. If a parser returns nothing from Root\InventoryApplicationFile and nothing from Root\File, open the hive in a tree view and look at what Root actually contains before concluding the hive is empty.

Amcache will not close your case alone. It hands you a hash when the file is gone, PE metadata when you need to characterise a binary, and a first-seen timestamp when you are building a timeline. Pair it with Shimcache for corroborated presence and Prefetch for execution, and remember the one rule that keeps you honest: an Amcache entry proves presence, not that the program ran.