shimcache proves a file existed, not that it ran

the file that shouldn't be there

you're digging through a windows box that got popped, and you find a binary sitting in a temp folder with a name like svch0st.exe. your gut says "gotcha." but before you write that up in a report, you need to understand what your evidence actually proves. this is where shimcache comes in, and it's one of those artifacts that gets misquoted constantly in dfir writeups, so let's fix that.

what shimcache actually is

shimcache, officially the application compatibility cache, is a windows feature built for a boring reason: compatibility. when microsoft changes something under the hood, older apps sometimes break. shimcache lets windows track executables it has "seen" so it can apply compatibility shims if needed. it's not a security feature. it just happens to leave behind a really useful breadcrumb trail for anyone doing forensics.

what gets recorded is simple: the full file path, and the last-modified timestamp pulled from the file's metadata at the time it was cached. that's basically it. no execution flag baked in for most windows versions, no user context, no parent process. just "this path existed with this timestamp."

pulling the data

the standard tool for this is eric zimmerman's AppCompatCacheParser. it reads the shimcache data straight out of the registry and dumps it to something you can actually work with.

AppCompatCacheParser.exe --csv . -c 1

breaking that down: --csv . tells it to write output as a csv file into the current directory. -c 1 sets the number of days of computer time to adjust for time zone conversion, since shimcache timestamps can be stored in a way that needs correction depending on your system's setup. run it, open the csv, and you get a clean list of paths and timestamps sorted by cache order.

you'll usually see legitimate system binaries mixed in with anything unusual, like that temp folder executable. the list itself doesn't scream "malware," it just shows you what windows noticed.

the distinction that actually matters

here's the part people get wrong constantly: an entry in shimcache means the file was present on disk at some point. it does not mean the file executed. windows can populate shimcache entries just from a file being touched by certain processes, like being copied, scanned by an app that enumerates executables, or in some cases just existing on the filesystem when a cache rebuild happens.

this is not a footnote, it's a legal and analytical landmine. if you're building a timeline for an incident report, or worse, testifying about it, saying "shimcache proves execution" is the kind of statement that gets torn apart by anyone who knows the artifact. what you can defensibly say is "this binary existed at this path, with this last-modified time, and windows recorded it." to actually prove execution you need corroboration: prefetch, amcache combined with other evidence, event logs showing process creation (event id 4688), or edr telemetry that logs actual execution.

why this matters for the defender

if you're on the blue team side reviewing your own environment, shimcache is a great low-cost signal for "what unusual binaries have touched this machine," even if you can't yet say they ran. that temp folder exe is still worth investigating even if it never executed, because an attacker or a piece of malware dropping payloads it never got to run is still a compromise indicator. the goal isn't just "did this run," it's "why is this here at all."

pair shimcache with amcache (which does track more execution-adjacent detail) and with your process creation logs if you have them enabled. none of these artifacts alone tells the full story, but stacked together they get you a lot closer to the truth.

the takeaway

shimcache is a solid, free source of "what existed here," not "what ran here." mixing those up in an investigation is an easy way to make a wrong call or lose credibility in a report. on your own systems, turn on process creation auditing, keep prefetch enabled, and don't rely on a single artifact to tell you the whole story. the strongest forensic conclusions come from multiple weak signals agreeing with each other, not one artifact doing all the talking.