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 most common mistake in ShimCache analysis is reading the timestamp column as "when this ran." It is not. I have watched analysts put that interpretation in front of clients and regulators, and I have watched the report get torn apart in review by anyone with a working knowledge of NTFS. Do not be that analyst.
What the timestamp actually is
Each entry stores the file's $STANDARD_INFORMATION last-modified time (SI mtime), as it was on the NTFS volume at the moment Windows recorded the entry. Straight copy of a file-system attribute. Says nothing about process creation, module load, or shutdown.
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 is a property of the file, not of either machine.
Why it is not the execution time
Windows adds a cache entry when it examines a file for application-compatibility reasons. Often, but not always, coincident 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.
If you need an actual execution time, you need Prefetch run times, AmCache first-run, Security 4688, or Sysmon Event ID 1. The cache cannot give that to you.
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 does not match the patch level of the host, that file was replaced. Cross-check against the MFT$FILE_NAMEattribute, which is harder to stomp. - Build correlation. Malware compiled in a campaign often shares an mtime cluster across victims. Useful for grouping incidents to the same actor.
- 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. But order is not time, and the insertion sequence resets at boot.
How attackers abuse it
Because it is just a file-system attribute, it is trivially forgeable. Timestomping (setting an mtime to 2009-07-14, the classic kernel32.dll date) makes a dropper blend into Windows system files. The cache 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.
The MFT's $FILE_NAME attribute usually retains the true creation time even after $STANDARD_INFORMATION is stomped. The MFT parser walks through the comparison. The USN journal also captures the original create event in most cases.
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 Event ID 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's Caching Out the Val — the original write-up that defined the artifact's forensic use.
- Eric Zimmerman's AppCompatCacheParser — reference parser whose output uses the same mtime semantics.