Does a Shimcache entry for a binary prove that the binary executed on that host?
answer
- compatibility engine, not the loader
- existence at a path, not a run
- Windows 8 dropped the execution flag
- the only timestamp belongs to the file
- pair it with Prefetch or a process-create record
basics
~20 sNo. A Shimcache (AppCompatCache) entry records that Windows' application-compatibility engine saw that file at that path with that last-modified time. Windows 8 and later store no execution flag at all, so an entry is evidence of existence, not of a run.
solid answer
~50 sNo, and treating it as proof is the classic overreach on this artefact. Shimcache lives in `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache` and holds, per entry, the full file path, the file's NTFS `$STANDARD_INFORMATION` last-modified time, and the entry's position in the cache. Windows XP and 7 carried an insert flag that parsers render as `Executed`; Windows 8 and later dropped it, so on any modern host you cannot separate an execution from another interaction that made the shim engine look at the file. What the artefact is genuinely good for is different and still valuable: it proves a file with that name and that modified time existed at that path even after the file is deleted, and the entries are held in most-recently-inserted-first order, which gives you relative sequence. To claim execution you need an execution artefact next to it: a Prefetch file, or a Sysmon Event ID 1 or Security 4688 process-creation record.
go deeper
Be ready to state plainly that a Shimcache entry means the file existed at that path, and that the timestamp in it is the file's modified time. Know that Prefetch and process-creation records are where execution evidence comes from.
Explain the mechanics: where the cache lives, that it is flushed to the registry at shutdown, that the Windows 7 execution flag is gone on Windows 8 and later, and that entries sit in insertion order.
Show how you word a finding so it survives challenge: the artefact claim and the execution claim kept as separate sentences, with the corroborating artefact named or its absence stated.
Own the standard your team writes to. Decide what an analyst is allowed to assert from a presence artefact alone in a report that may be read by a customer, a regulator or opposing counsel.
### What Shimcache actually is The Application Compatibility Cache, universally called **Shimcache**, is a lookup Windows maintains so it can decide cheaply whether an executable needs a compatibility shim applied before it is loaded. It is stored as a single binary registry value at `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache` and is parsed into rows by forensic tooling. On the Windows versions examiners meet, the live cache is maintained in memory and serialised into that registry value at shutdown. That has a direct practical consequence: on a host that has been running for three weeks, the registry copy can be three weeks stale, and the entry you are looking for may exist only in RAM or in a previous `ControlSet`, an older hive backup, or a volume shadow copy. ### What one entry contains Each entry is small and fixed: | Field | Meaning | | --- | --- | | Path | Full path of the file as the shim engine saw it | | Last-modified time | The file's `$STANDARD_INFORMATION` modified timestamp, copied from the filesystem | | Cache position | Where the entry sits in insertion order | | Executed flag | Present on Windows XP / 7 only; **absent on Windows 8 and later** | There is no hash, no user, no parent process, no command line, and — this is the part candidates miss — **no timestamp for when the entry itself was created**. The only time in the record belongs to the file, not to the event. ### Why it is presence evidence, not execution evidence An entry means the compatibility engine examined that path. Executing the file is one way that happens; it is not the only one, and on Windows 8 and later there is no field left that would let you tell which. So the honest claim is bounded: *a file named X, at path Y, with modified time Z, existed on this host at some point before the cache was last written*. The direction of the claim matters in both directions. The presence of an entry does not prove a run. The absence of one does not prove the file was never there — the cache is capped and rolls over, and on a live host recent activity may simply not have been flushed to the hive yet. ### Amcache sits in the same category `C:\Windows\AppCompat\Programs\Amcache.hve` is a separate hive whose `InventoryApplicationFile` entries carry the file path, size, publisher and — uniquely — the **SHA-1 hash** of the binary. That hash is the reason Amcache is so useful: you can hash-match a file that has already been deleted from disk against threat intelligence or a known-good build. But Amcache is populated largely by the Microsoft Compatibility Appraiser scheduled task, so an entry's key write time reflects when the inventory task got around to the file, which may lag execution by hours or days — or exist without any execution at all. Amcache, like Shimcache, is presence evidence. ### What proves execution - **Prefetch** (`C:\Windows\Prefetch\NAME-HASH.pf`) is created when a program is run. It carries a run count, the most recent run time (up to the last eight run times on Windows 8 and later), and the files referenced in roughly the first ten seconds of execution. - **Sysmon Event ID 1** and **Windows Security 4688** are process-creation records. They are direct evidence that a process started — but only where the logging was configured before the fact, and only as far back as retention goes. ### Writing the finding so it survives challenge Split the sentence in two. First the artefact claim: *"AppCompatCache contains an entry for `C:\ProgramData\upd\svc.exe` with modified time 2026-03-04T11:02Z, positioned near the top of the cache."* Then, separately, the execution question: *"No Prefetch file, no 4688 and no Sysmon 1 record for that path was found within the available window; execution is unproven."* An examiner who blends the two into "the binary ran on 4 March" has asserted two things the artefact does not support — that it ran at all, and that the file's modified time is a run time. This is also why Shimcache is a *scoping* tool rather than a *verdict* tool. Sweeping four hundred hosts for a path and finding it on nine of them tells you where to look for real execution evidence. It does not tell you those nine hosts ran anything.
- If it does not prove execution, what is Shimcache genuinely good for?Two things. It proves a file with that name, path and last-modified time existed on the host even after the file has been deleted, which is often the only surviving trace. And entries are held in insertion order, most recent first, so it gives you relative sequence between paths when you have no absolute times. It is a scoping and existence artefact, not a verdict artefact.
- Where does an Amcache entry stand on the same question?The same place: presence, not execution. Its unique value is the SHA-1 hash of the file, which lets you identify or hash-match a binary that is already gone from disk. But Amcache is populated largely by the Microsoft Compatibility Appraiser scheduled task, so the entry's write time reflects when the inventory ran, not when anything executed, and an entry can exist for a file that never ran.
- You triaged a live host and the Shimcache lacks an entry you expected. What explains it?On the versions you will meet, the cache is maintained in memory and written to the registry value at shutdown, so the hive on a long-uptime host can be badly stale. Parse it from a memory image or a live-response collection instead, and check previous ControlSets and shadow copies. The cache is also capped and rolls over, so an old entry may simply have been evicted.
It is like a door camera that logged a face and a badge photo at the entrance. It tells you the person was there; it does not tell you they went inside and did anything.
saying these in an interview costs you the question
- Says a Shimcache entry proves the binary ran
- Reads the entry's timestamp as the execution time
- Treats Amcache entries as execution records like Prefetch
- Claims no Shimcache entry means the file was never present
- Assumes the registry copy is current on a running host