Using the ShimCache in ransomware investigations

4 min read

TL;DR. Ransomware actors routinely delete tools and reboot. ShimCache often survives that, preserving dropper paths and staging tools from before encryption. Pull the SYSTEM hive and a memory image if the host hasn't been clean-rebooted, then corroborate with AmCache for hash-based attribution.

Ransomware investigations are forensic against the wind: encrypted disks, deleted tools, sometimes wiped event logs, and an attacker incentive to reboot. The ShimCache is one of the few artifacts that often still answers basic questions in that environment. This post is a tactical guide to using it.

What ShimCache typically preserves in a ransomware case

In a typical ransomware engagement, by the time you arrive:

  • The encryptor binary is usually gone — wiped by itself or by a cleanup script.
  • The Prefetch directory may have been cleared if the attacker thought of it.
  • Event logs are sometimes truncated (event ID 1102 is the famous tell).
  • AmCache persists (it's continuously written) but only carries entries for binaries Windows had time to register.
  • ShimCache persists for whatever was flushed at the last clean shutdown — and that's frequently the dropper and staging tools that ran early in the intrusion.

Because the ShimCache only flushes at shutdown (details here), the most useful state is often pulled from a memory image of the running compromised system before reboot. If the system already rebooted, the on-disk hive still gives you everything that was persisted at that point.

The three questions ShimCache helps answer

1. What ran before the encryption? Sort the ShimCache by mtime and walk backwards from the suspected encryption window. Dropper paths in \Temp\, \AppData\, or \ProgramData\ show up regularly. Cross-reference with AmCache for hashes (see ShimCache vs AmCache).

2. Where else did they pivot? ShimCache captures executables on attached volumes. Hits on UNC paths (\\?\UNC\) or unusual drive letters point at lateral-movement infrastructure — the file server they staged from, the shared admin tools directory, the backup volume they tried to wipe.

3. What were the staging tools? PSExec, WMIExec, mimikatz, Cobalt Strike beacons, AnyDesk/TeamViewer installers, custom loaders — they all leave ShimCache traces. Many ransomware playbooks reuse the same tool names; a ShimCache scan against your standard ransomware indicator list catches them fast.

A short workflow

  1. Acquire the SYSTEM hive from disk (C:\Windows\System32\config\SYSTEM + transaction logs). On a running host, consider a memory image too — see Extracting the ShimCache from a memory dump.
  2. Parse to a (path, mtime, format) table. The Shimcache Parser keeps the hive offline in your browser.
  3. Filter for the ransomware playbook signatures: encryptor names, RMM installers (AnyDesk, ScreenConnect, Splashtop), credential tools, archive utilities (7z, winrar) used for staging exfiltration.
  4. Triage with the malware-hunting workflow.
  5. Build a timeline combining ShimCache, AmCache, Prefetch, and event logs — the timeline post walks through tooling.
  6. Watch for tampering. A suspiciously short or empty ShimCache on a compromised host can itself be an indicator — see anti-forensics detection.

Don't over-claim what you see

ShimCache evidence in ransomware reports gets scrutinized by insurers, legal counsel, and threat intel teams. Be precise:

  • A ShimCache hit on encryptor.exe proves the file was on disk at some point. It does not prove the file was the one that did the encryption (that's the proof-of-execution caveat).
  • The mtime is the file's last-modified time, not when the ransomware ran.
  • Always corroborate with AmCache SHA-1 for hash-based attribution.

Further reading

Related articles