Hunting malware with the ShimCache: a step-by-step workflow

3 min read

TL;DR. Parse the SYSTEM hive → filter for paths in user-writable locations (AppData, Temp) and unexpected system paths → corroborate hits with AmCache hashes and Prefetch → pivot on SHA-1 when the file is gone. ShimCache puts names on your hunt list; it doesn't close cases on its own.

The ShimCache is one of the highest-signal pivot points in Windows threat hunting: it tracks executables Windows examined, even ones that have since been deleted. This post is a concrete workflow for turning a ShimCache dump into a short list of hosts and files worth investigating.

Five-step ShimCache malware-hunting workflow

The workflow in five steps

  1. Collect the SYSTEM hive. Either pull the offline file from C:\Windows\System32\config\SYSTEM (plus its .LOG1/.LOG2 siblings) or use a live-system collector like Velociraptor. For background on when the cache is actually written, see Where the ShimCache is stored.
  2. Parse to a flat list. Decode the binary blob into (path, mtime, format) rows. The Shimcache Parser does this in your browser; the reference parsers do it offline.
  3. Filter for suspicious paths. Hunting starts here — you're looking for patterns, not single rows.
  4. Corroborate execution. A ShimCache hit alone proves existence, not execution. Pair every interesting row with Prefetch, AmCache, or event logs (reference).
  5. Pivot on hash. When the on-disk file is gone, AmCache's SHA-1 is your handle for VirusTotal / TI lookups (why both artifacts).

Patterns worth filtering for

These are the path patterns hunters score highest in practice:

  • User-writable directories: \AppData\Local\Temp\, \AppData\Roaming\, \Users\Public\, \ProgramData\ — places where users and services can drop binaries without admin rights.
  • System-writable-but-shouldn't-be: C:\Windows\Temp\, C:\PerfLogs\, C:\Recycler\$Recycle.Bin\ — anything under C:\Windows\ that isn't a known Windows path.
  • Double extensions / mimicking system binaries: svchost.exe outside \System32\, lsass.exe anywhere unusual, *.pdf.exe, *.docx.exe.
  • Network shares and removable media: \\?\UNC\, drive letters that aren't C:, \Device\HarddiskVolumeShadowCopy*.
  • One-shot tooling: psexec.exe, winrm.cmd, wmiexec.exe, cobaltstrike artifacts — legitimate admin tools are often abused.

Don't be too clever with regexes on a first pass. Sort by the mtime column and walk the recent entries by eye — that finds things heuristic filters miss.

Triage rules of thumb

When a row looks interesting, a few quick checks separate signal from noise:

  • Does it have a Prefetch sibling? That's near-proof of execution.
  • Does AmCache have a SHA-1? Look it up. A clean signed vendor hash tells you to deprioritize fast.
  • Is the mtime suspiciously close to a known incident time? A binary modified within minutes of an alert deserves a deeper look.
  • Is the parent directory the user's profile but the user shouldn't have admin? Reasonable, but watch for elevation indicators (Sysmon 4688 with elevated tokens).

What this workflow doesn't tell you

ShimCache by itself won't tell you who launched the binary, with what arguments, or when. For those, you'll need Sysmon, Security event logs, or a fuller program-execution timeline. ShimCache's job is to put names on your hunting list — not to close the investigation on its own.

Further reading

Related articles