TL;DR. Yes. A ShimCache entry persists in the registry regardless of whether the file still exists on disk. Deleting the binary does not delete its ShimCache entry — which is why the artifact is so valuable for catching tools an attacker dropped, used, and wiped.
"Does the ShimCache still show a file after it's deleted?" is one of the most common questions in program-execution forensics — and the answer is the entire reason the artifact is worth pulling.
Short answer: yes, it does
The ShimCache stores a path + last-modified timestamp inside a registry value. That record has no link back to the file system. When the executable is deleted, NTFS frees the file — but the registry value is untouched. The entry remains until it is either evicted by newer entries (the cache holds up to 1,024) or the value itself is cleared.
So a binary an attacker dropped into C:\Users\Public\, ran, and deleted ten minutes later can still leave a clean, readable ShimCache entry showing the full path it once occupied.
Why this is forensically powerful
Deleted-file entries are often the only surviving evidence of attacker tooling:
- A renamed
mimikatz.exedeleted after credential theft. - A staging archive removed after exfiltration.
- A dropper that self-deleted after installing a payload.
In each case the file is gone, but the ShimCache path tells you it existed, where, and (via the last-modified timestamp) ties it to a build. This is the backbone of hunting malware with the ShimCache and of ransomware investigations, where attackers routinely wipe their tools.
How long does a deleted-file entry survive?
Two limits apply:
- Eviction. The cache is bounded (up to 1,024 entries). On a busy host, heavy executable activity can push old entries out. On a quiet server it may survive for months.
- Flush timing. New entries only persist to the hive at clean shutdown. If the host hasn't been shut down since the deletion, the surviving entry may still be in memory only — pull it from a memory image (how to). The storage/flush model is covered in where the ShimCache is stored.
What it does not prove
A deleted-file entry proves the file existed and was examined on that host. It does not, by itself, prove the file executed, and it does not tell you when it was deleted (the timestamp is the file's mtime, not a deletion time). Treat it as a strong existence witness and corroborate execution with Prefetch/AmCache — see does the ShimCache prove execution.
To check which entries on a hive point at files that no longer exist, parse it with the Shimcache Parser and cross-reference the paths — everything runs locally in your browser.
Further reading
- Mandiant: leveraging the ShimCache — the case for ShimCache as a deleted-tool witness.
- SANS DFIR: program execution artifacts — where ShimCache sits among execution evidence.