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. That is exactly why the artifact is so useful for catching tools an attacker dropped, used, and wiped.
The cache stores a path and a timestamp in a registry value. That value has no link back to the filesystem. When NTFS frees the executable, the registry data does not move. Which is the entire reason the artifact is worth pulling, and the entire reason it is sometimes the only surviving evidence of an intrusion.
Short answer: yes, it does
The ShimCache stores a path plus the file's $STANDARD_INFORMATION mtime inside the value at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. That record has no link back to the file system. When the executable is deleted, NTFS frees the file. 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.
- A
7z.execopy used to bundle data before transfer.
The file is gone. The cache 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.
Cross-reference with the MFT and USN journal. If the journal still carries the create-then-delete sequence, you have a clean timeline anchor. The recycle bin almost never holds these (they bypass it) but check anyway.
How long does a deleted-file entry survive?
Two limits apply:
- Eviction. The cache is bounded at roughly 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 has not been shut down since the deletion, the surviving entry may still be in memory only. Pull it from a RAM dump, see the memory extraction guide. The storage and 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 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 or 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 against the live filesystem (or a forensic image). Everything runs locally in your browser.
Further reading
- Mandiant's Caching Out the Val — the case for ShimCache as a deleted-tool witness.
- SANS DFIR program execution poster — where ShimCache sits among execution evidence.