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 current session's entries from a running or crashed host, run Volatility 3's windows.shimcachemem (or Velociraptor's Windows.Registry.AppCompatCache artifact) against a memory image.

The ShimCache lives in volatile memory while Windows runs, and only gets written to the SYSTEM hive at a clean shutdown (more on the timing). That means a memory image of a running host is often the only place to find ShimCache entries from the last session — exactly the entries most likely to be relevant to an active incident.

When the memory copy matters more than the disk copy

You want the in-memory ShimCache when:

  • The host hasn't been cleanly shut down since the incident. Most hard reboots, BSODs, and forced power-offs leave the SYSTEM hive's 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–Win10 memory image:

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

It 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 and usage notes live in the Volatility 2 repo.

With Volatility 3

Volatility 3 carries this forward 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 artefact set.

With Velociraptor

If you're 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. That's the same ShimCache the OS would have flushed at shutdown — without waiting for shutdown.

Combining the two views

In practice you'll often have:

  • the in-memory ShimCache from a Volatility plugin or Velociraptor collection,
  • the on-disk ShimCache from the SYSTEM hive on the same host.

The memory copy is a superset of the disk copy at any moment a clean shutdown hasn't 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.

Useful next steps

Once you have the entries:

Further reading

Related articles