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. 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 is how I actually use it to reconstruct lateral movement.
What lateral movement looks like in the cache
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 / WinRM | powershell.exe plus any dropped .exe it staged |
Impacket smbexec / wmiexec | Random-named .bat and .exe under \Windows\Temp\ |
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, a post-exploitation framework loader. Pairing "tool on host A" with "service binary on host B" within a plausible window is the core lateral-movement inference.
Cross-reference with Sysmon Event ID 3 network connections and Security 4624 logon type 3 to close the loop. The EVTX parser covers the relevant event IDs.
The cross-host diff workflow
- Collect SYSTEM hives from every in-scope host. See acquiring a SYSTEM hive. Or use Velociraptor for fleet collection.
- Parse each and export to CSV. Eric Zimmerman's AppCompatCacheParser is the right answer for batch work.
- Normalize paths and diff for shared, unusual binaries. The same random service name or staging path appearing on multiple hosts is the movement path.
- Order hosts by insertion order, not by the timestamp. The timestamp is the file's mtime, not an event time, so it does not sequence hops on its own.
- Corroborate each hop with Security 4624 (logon type 3), 4648 (explicit credentials), 7045 (service install), and AmCache for SHA-1 attribution.
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) before concluding a host was not touched. The timestamp never sequences hops on its own; rely on insertion order plus EVTX and the USN journal for event times. Attackers who clear the value leave their own tell. See ShimCache anti-forensics.
To diff hives quickly, parse each with the Shimcache Parser and compare client-side. CSV export from EZ's tool feeds directly into pandas or csvdiff for larger sets.
Further reading
- MITRE ATT&CK Remote Services (T1021) — technique reference for the destination-side tells.
- Mandiant's Caching Out the Val — foundational ShimCache tradecraft.
- JPCERT/CC's Detecting Lateral Movement through Tracking Event Logs — pairs naturally with the EVTX side of the analysis.