en

Using the ShimCache in ransomware investigations

4 min read

TL;DR. Ransomware actors delete tools and reboot. ShimCache often survives that, preserving dropper paths and staging tools from before encryption. Pull the SYSTEM hive plus a RAM dump if the host has not been clean-rebooted, then corroborate with AmCache for hash-based attribution.

Ransomware investigations are forensics 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 still answers basic questions in that environment. This is the tactical playbook I use.

What ShimCache typically preserves

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.
  • EVTX logs are sometimes truncated. Event ID 1102 is the famous tell.
  • AmCache persists. It writes continuously and carries SHA-1 hashes.
  • ShimCache holds whatever was flushed at the last clean shutdown. Frequently the dropper and staging tools that ran early in the intrusion.

Because the cache only flushes at shutdown (details), 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. Memory extraction is covered in extracting the ShimCache from a memory dump.

The three questions ShimCache helps answer

1. What ran before the encryption? Sort 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 SHA-1 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. The USN journal and MFT often confirm the writes.

3. What were the staging tools? PsExec, WMIExec, mimikatz, Cobalt Strike beacons, AnyDesk and TeamViewer installers, custom loaders. They all leave ShimCache traces. Most ransomware playbooks reuse the same tool names; a scan against your standard ransomware indicator list catches them quickly.

A short workflow

  1. Acquire the SYSTEM hive plus its SYSTEM.LOG1 and SYSTEM.LOG2 from C:\Windows\System32\config\. On a running host, capture memory too. See acquisition and memory extraction.
  2. Parse to a (path, mtime, format) table. The Shimcache Parser keeps the hive offline in your browser.
  3. Filter for ransomware playbook signatures: encryptor names, RMM installers (AnyDesk, ScreenConnect, Splashtop), credential tools, archive utilities (7z, winrar, rar.exe) used for exfil staging, browser history artifacts if the attacker downloaded tools interactively.
  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 is itself an indicator. See anti-forensics detection.

Do not over-claim

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 (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.
  • If the bitlocker or BCD got wiped, registry hives and the pagefile sometimes still hold useful breadcrumbs.

Further reading

Related articles