Lion Cipher Lab
Prove a program was on the machine even after it was deleted — Amcache and ShimCache (AppCompatCache)
- Digital Forensics & IR (DFIR)
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Attackers delete their tools. They run a loader, dump credentials, move on, then `del` the binary to erase the evidence — and if all you had was the file system, the tool would be gone and the story with it. But Windows keeps two quiet registers of what executables have been on a machine, and both are maintained by a feature that has nothing to do with security: the application-compatibility (shim) engine, the machinery that lets old programs keep running on new Windows by quietly patching their behaviour. To do that job Windows records metadata about the executables it sees. Two of those…
What you'll learn
- explaining the Windows application-compatibility (shim) engine in plain words, and why two of its side-effects — Amcache.hve and the AppCompatCache (ShimCache) — became prized DFIR artifacts
- knowing exactly where each lives: ShimCache in the SYSTEM registry hive (…\Control\Session Manager\AppCompatCache), Amcache in C:\Windows\AppCompat\Programs\Amcache.hve
- manufacturing ground truth: copying a known EXE to a known path, running it, noting the time, then DELETING the binary — and proving the artifacts survive the deletion
- parsing ShimCache with Eric Zimmerman's AppCompatCacheParser (against the live SYSTEM hive or an exported copy) and reading the path, the $StandardInformation last-modified time, and the Executed flag
- parsing Amcache.hve with AmcacheParser -i and reading the full path, the file SHA1, and the first-run/compile timestamps from the CSVs
- reconstructing 'this now-deleted binary was present at this path' and correlating the Amcache SHA1 + path with the matching ShimCache entry
- the single biggest DFIR misconception, stated plainly: ShimCache proves PRESENCE, not execution; its timestamp is the file's last-modified time, not a run time; and the cache is written on shutdown so it can be stale
- the judgment: when each artifact earns its place in a triage, the classic examiner mistake (reporting 'ShimCache = it ran'), and how a pro corroborates across Prefetch, Amcache and ShimCache instead of trusting one
Steps in this lab
- The shim engine, and the two artifacts it leaves behind
- Locate the hives on your own machine
- Manufacture ground truth: plant a binary, run it, note it, then DELETE it
- Get Eric Zimmerman's parsers
- Parse ShimCache: read the path, the last-modified time, the Executed flag
- Parse Amcache with -i: read the full path, the SHA1, the timestamps
- The payoff: 'this deleted binary was present here' — correlate SHA1 + path
- The honest negative: ShimCache is NOT proof of execution (and the timestamp traps)
- Judgment: when each artifact earns its place, and how a pro corroborates