TL;DR. Lateral movement tools — PsExec, wmic, at/schtasks, remote PowerShell — leave ShimCache entries on the destination host (the dropped service binary) and often on the source. Diffing AppCompatCache across many hosts surfaces the path the attacker took.
ShimCache is usually framed as a single-host artifact. But its real power in incident response is cross-host: the same tooling, examined for compatibility on every machine it touches, leaves a correlatable trail. This post is about reading that trail.
What lateral movement looks like in the ShimCache
Remote-execution techniques drop or invoke an executable on the destination. Each leaves a characteristic path:
| Technique | Destination ShimCache tell |
|---|---|
| PsExec / SMB service exec | C:\Windows\PSEXESVC.exe or a random 8-char service binary in C:\Windows\ |
sc \\host create | Attacker-named service binary, often in C:\Windows\ or \PerfLogs\ |
WMI (wmic process call create) | Payload path under C:\Windows\Temp\ or a user-writable dir |
Scheduled task (schtasks /s) | Task action binary, frequently C:\Users\Public\ |
| Remote PowerShell | powershell.exe plus any dropped .exe it staged |
A service binary with a random name in C:\Windows\ is one of the highest-signal ShimCache findings there is — covered as a triage rule in hunting malware with the ShimCache.
The source-host side
The originating host frequently shows ShimCache entries for the attack tooling itself: PsExec.exe, wmic.exe used interactively, a custom mover, or post-exploitation frameworks. Pairing "tool on host A" with "service binary on host B" within a plausible window is the core lateral-movement inference.
The cross-host diff workflow
- Collect SYSTEM hives from every in-scope host (see acquiring a SYSTEM hive).
- Parse each and export to CSV.
- Normalize paths and diff for shared, unusual binaries — the same random service name or the same staging path appearing on multiple hosts is the movement path.
- Order hosts by the ShimCache insertion order (not the timestamp — it's the file mtime, not an event time).
- Corroborate each hop with Security 4624/4648, 7045 service-install events, and AmCache.
This fuses naturally into a full program-execution timeline. Map the techniques to ATT&CK T1021 (Remote Services) and T1570 (Lateral Tool Transfer) for reporting.
Caveats
ShimCache only flushes at clean shutdown, so a host still running may not have written the decisive entry yet — check memory (extracting from a memory dump). And the timestamp never sequences hops on its own; rely on insertion order plus event logs. Attackers who clear the value leave their own tell — see ShimCache anti-forensics.
To diff hives quickly, parse each with the Shimcache Parser, export CSV, and compare — all client-side.
Further reading
- MITRE ATT&CK: Remote Services (T1021) — technique reference for the destination-side tells.
- Mandiant: leveraging the ShimCache — foundational ShimCache tradecraft.