Can attackers clear the ShimCache? Anti-forensics and detection

4 min read

TL;DR. Attackers fight ShimCache mostly by avoiding clean shutdowns (so it 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 ShimCache is harder to tamper with than most Windows artifacts, but it's not untouchable. This post walks through what attackers actually attempt, why most of those attempts leave fingerprints, and how to detect tampering during analysis.

The tampering toolkit attackers reach for

1. Hard reboot before flush. The cleanest "anti-forensic" against the ShimCache is to never give Windows the chance to write it. If the attacker forces a hard power-off (or kills a VM at the hypervisor), the in-memory ShimCache for that session is simply lost. The on-disk hive still holds whatever was flushed at the previous clean shutdown. See when the cache is written for the mechanism.

2. Direct registry edits to the value blob. A privileged attacker can overwrite the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache value. In theory, this lets them remove specific entries — in practice, the binary layout is non-trivial enough that bad edits usually leave the blob malformed.

3. Replacing the SYSTEM hive offline. If the attacker can take the system offline, they can swap the hive file. This is rare in opportunistic intrusions but appears in nation-state cases.

4. Time stomping the binary. Because the ShimCache stores the file's $STANDARD_INFORMATION mtime, an attacker who time-stomps the binary before Windows examines it shifts the cached timestamp. The ShimCache itself isn't lying — the file metadata it captured was already tampered with.

5. Wiping AmCache and Prefetch. Attackers who learn the corroborating artifacts often clear those too, leaving the ShimCache as the lone witness and hoping it's dismissed for the reasons in our proof-of-execution post.

Detection tells

When you suspect tampering, look for:

  • Unusually short ShimCache. Windows fills the cache to ~1,024 entries over normal use. A blob with only a handful of entries on a system that's 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, scheduled-task helpers, OS update tooling). Their absence on a workstation that's 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 will surface this as an explicit error.
  • In-memory / on-disk divergence. Compare ShimCache extracted from memory (guide) with the on-disk hive. Entries present in memory but absent on disk can mean a hard reboot — but entries present on disk that contradict memory (different paths or mtimes for the same slot) suggest someone wrote to the hive.
  • Mismatched AmCache and ShimCache. If AmCache shows a binary executed but the ShimCache that should also have the entry is empty, ask why. ShimCache wipes that didn't touch AmCache are common because attackers don't always realize AmCache exists.

What this tells investigators

A few practical rules:

  • Treat an empty or near-empty ShimCache as evidence, not as the absence of evidence. Document it.
  • Pull the memory image when you can. It frequently catches what the hive lost.
  • Always corroborate with AmCache and Prefetch (reference). Three artifacts is much harder to wipe consistently than one.
  • Don't claim "the attacker wiped the ShimCache" unless you can show what was wiped — point at gaps in the entry count, missing baseline binaries, or in-memory/disk divergence.

Further reading

Related articles