TL;DR. The ShimCache timestamp is the executable's $STANDARD_INFORMATION last-modified time copied off the file system — not the time it executed, not the time it was cached. Treat it as a property of the file, never as an event on a timeline.
The single most common mistake in ShimCache analysis is reading the timestamp column as "when this ran." It isn't. Misreading it has put wrong times in real incident reports. This post explains precisely what the value is and how to use it without drawing a false conclusion.
What the timestamp actually is
Each ShimCache entry stores the last-modified time ($STANDARD_INFORMATION mtime) of the executable, as it was on the NTFS volume at the moment Windows recorded the entry. It is a straight copy of a file-system attribute. It says nothing about process creation, module load, or shutdown.
That has three immediate consequences:
- A binary built last year and run today shows last year's date.
- A file copied with a tool that preserves timestamps keeps its original mtime, not the copy time.
- Two hosts running the same signed binary will show the same timestamp — because it's a property of the file, not of either machine.
Why it is not the execution time
Windows adds a ShimCache entry when it examines a file for application-compatibility reasons — which often, but not always, coincides with execution. Even when it does coincide, the cache stores the file's mtime, not the moment of examination. So the timestamp answers "when was this file last modified?" and never "when did it run?". The execution-vs-existence distinction is covered in depth in Does the ShimCache prove a program was executed?.
When the timestamp is still valuable
It is weak as an event time but strong as an identity anchor:
- Tamper detection. If a system binary like
svchost.exeshows an mtime that doesn't match the patch level of the host, that file was replaced. - Build correlation. Malware compiled in a campaign often shares an mtime cluster across victims — useful for grouping.
- Ordering, with care. Within one host, entries are stored in rough order of insertion. The order is more reliable than the absolute timestamps for sequencing activity.
How attackers abuse it
Because it's just a file-system attribute, it is trivially forgeable. Timestomping (e.g. setting an mtime to 2009-07-14, the classic kernel32.dll date) makes a dropper blend into Windows system files. The ShimCache faithfully records the stomped value — so a "clean" 2009 timestamp on a path in C:\Users\Public\ is itself a red flag. Anti-forensic patterns are catalogued in Can attackers clear the ShimCache?.
Using it correctly in a timeline
Put the ShimCache mtime in a separate column from event times — never merge it into the main timeline as if it were an action. Corroborate sequencing with artifacts that do carry event times: Prefetch run times, AmCache install/first-run, Security 4688, Sysmon 1. The full cross-reference is in Prefetch, AmCache, ShimCache: a quick reference.
To inspect the raw values yourself, drop a SYSTEM hive into the Shimcache Parser — it shows the exact stored mtime per entry, in your browser, with nothing uploaded.
Further reading
- Mandiant: leveraging the ShimCache — the original write-up that defined the artifact's forensic use.
- Eric Zimmerman's AppCompatCacheParser — reference parser whose output uses the same mtime semantics.