TL;DR. Attackers fight ShimCache mostly by avoiding clean shutdowns so the cache never gets flushed. Direct registry edits usually leave the blob malformed. Spot tampering via unusually short caches, missing always-present Windows binaries, malformed entry sizes, or memory-vs-disk divergence.
The cache is harder to tamper with than most Windows artifacts. Not impossible. After a few incidents you stop being surprised by what attackers try and start being surprised by how often they leave fingerprints. Here is the catalog of techniques I have actually seen used, and what each one leaves behind.
What attackers actually try
1. Hard reboot before flush. The cleanest anti-forensic against the cache is to never give Windows the chance to write it. Force a hard power-off, or kill the VM at the hypervisor, and the in-memory ShimCache for that session is simply lost. The on-disk hive still holds whatever was flushed at the previous clean shutdown. This is by far the most common pattern in ransomware engagements. See when the cache is written for the mechanism.
2. Direct registry edits to the value blob. A SYSTEM-level attacker can overwrite HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. In theory this removes specific entries. In practice the binary layout is non-trivial enough that hand edits usually leave the blob malformed or the entry count nonsensical.
3. Offline hive replacement. If the attacker can take the system down, they can swap the SYSTEM hive entirely. Rare outside nation-state work but it happens. The registry parser can show you whether the SYSTEM hive timestamps and structure are consistent with the rest of the host's artifacts.
4. Timestomping the binary. Because the cache stores the file's $STANDARD_INFORMATION mtime, an attacker who time-stomps the binary before Windows examines it shifts the cached timestamp. The cache is not lying; the file metadata it captured was already tampered with. Cross-reference with the MFT $FILE_NAME attribute, which is harder to stomp.
5. Wiping corroborating artifacts. Attackers who learn what ShimCache does often also clear AmCache, Prefetch, EVTX, and the recycle bin, leaving the ShimCache as the lone witness and hoping it gets dismissed for the reasons in the proof-of-execution post.
Detection tells
When you suspect tampering, look for:
- Unusually short cache. Windows fills the cache to roughly 1,024 entries over normal use. A blob with a handful of entries on a system that has been running for days is a strong tampering signal.
- Missing always-present entries. Several Windows binaries reliably appear in nearly every ShimCache, depending on version: shell components, scheduled-task helpers, OS update tooling. Their absence on a workstation that has been used is suspicious.
- Malformed entry sizes. A blob that fails parsing partway through, with the rest of the buffer zeroed or filled with garbage, is a classic indicator of clumsy editing. The Shimcache Parser surfaces this as an explicit error.
- In-memory and on-disk divergence. Compare the cache extracted from a RAM dump with the on-disk hive (extraction guide). Entries present in memory but absent on disk may mean a hard reboot. Entries present on disk that contradict memory (different paths or mtimes for the same slot) suggest someone wrote to the hive.
- AmCache and ShimCache mismatch. AmCache shows a binary executed but the ShimCache is empty for that file. Ask why. Attackers who wipe ShimCache often forget AmCache exists.
- Anti-forensic tool footprints. Look in Prefetch, Sysmon Event ID 1, and the USN journal for evidence of
reg.exe, PowerShellRemove-ItemProperty, or third-party hive editors running in the relevant window.
What this tells investigators
A few practical rules I enforce on every report:
- Treat an empty or near-empty ShimCache as evidence. Not as the absence of evidence. Document it explicitly.
- Pull a RAM dump when you can. It frequently catches what the hive lost.
- Always corroborate with AmCache and Prefetch. See the artifacts reference. Three artifacts is much harder to wipe consistently than one.
- Do not claim "the attacker wiped the ShimCache" unless you can show what was wiped. Point at gaps in entry count, missing baseline binaries, or memory-vs-disk divergence.
Further reading
- Velociraptor's
Windows.Registry.AppCompatCache— collection at scale to spot anomalies. - Windows 10/11 AppCompatCache deep dive on Ø Security — useful for understanding which fields a tampered blob would have to fake.
- Mehrnoush's ShimCache & AmCache forensic analysis — case studies including tampering scenarios.
- MITRE ATT&CK T1070 Indicator Removal — context for what well-resourced attackers do about artifacts like this.