en

Extracting the ShimCache from a memory dump

3 min read

TL;DR. ShimCache lives in memory. The on-disk SYSTEM hive only contains entries flushed at the last clean shutdown. To recover the active session's entries from a running or crashed host, run Volatility 3's windows.shimcachemem against a RAM dump, or pull live with Velociraptor's Windows.Registry.AppCompatCache artifact.

The cache lives in volatile memory while Windows runs. It only gets written to the SYSTEM hive at clean shutdown. That means a memory image is often the only place to find ShimCache entries from the current session, which are exactly the entries most likely to matter to an active incident. The storage timing post covers why.

When the memory copy matters more than disk

You want the in-memory cache when:

  • The host has not been cleanly shut down since the incident. Most hard reboots, BSODs, and forced power-offs leave the on-disk ShimCache stale.
  • You suspect anti-forensics. An attacker who edited the on-disk hive may not have touched the in-memory copy, which gets rebuilt each session. See anti-forensics detection.
  • You need entries that were evicted from the on-disk hive at the last flush. The 1,024-entry cap rotates old entries out, but they may still be in memory under specific conditions.

With Volatility 2

The classic plugin is shimcachemem. Against an XP through Win10 memory image:

vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem

Walks the AppCompatCache structures inside the SYSTEM hive's in-memory representation and prints (mtime, path) rows the same way an offline parser would. Plugin source lives in the Volatility 2 repo.

With Volatility 3

Volatility 3 ships this as windows.shimcachemem:

vol -f memory.raw windows.shimcachemem

No more profile selection. Vol 3 figures out the OS automatically. The Volatility 3 docs document the plugin alongside the rest of the Windows artifact set. While you have the dump open, you may as well also pull processes, network connections, and module lists. The RAM parser covers the broader memory-forensics workflow.

With Velociraptor

For collecting at scale rather than analyzing a single dump, Velociraptor's Windows.Registry.AppCompatCache artifact reads the in-memory ShimCache directly from a running endpoint via the live registry view. Same cache the OS would have flushed at shutdown, without waiting for shutdown.

Combining the two views

In practice you will often have both:

  • The in-memory cache from Volatility or Velociraptor.
  • The on-disk cache from the SYSTEM hive on the same host.

The memory copy is a superset of the disk copy at any moment a clean shutdown has not happened. But the disk copy may include entries that were already evicted from memory after a long uptime. Pull both, dedupe by (path, mtime), and feed the union into your hunting workflow.

If the two views disagree on paths or timestamps for the same slot, that is a tampering indicator. See anti-forensics.

Useful next steps

Once you have the entries:

  • Use the Shimcache Parser for quick offline triage of an extracted hive. Runs in your browser, no upload.
  • See the binary format reference if you are decoding the raw blob yourself.
  • See proof of execution before claiming a memory-recovered entry means a program ran.
  • Carve pagefile.sys if you suspect the cache has been partially wiped from both memory and disk; fragments sometimes survive in swap.

Further reading

Related articles