Lateral Movement mit dem ShimCache erkennen

3 Min. Lesezeit

TL;DR. Lateral-Movement-Tools (PsExec, wmic, at / schtasks, Remote-PowerShell) hinterlassen ShimCache-Einträge auf dem Zielhost (die abgelegte Dienst-Binärdatei) und oft auf der Quelle. Das Diffen von AppCompatCache über viele Hosts hinweg bringt den Pfad zum Vorschein, den der Angreifer genommen hat.

ShimCache wird meist als Single-Host-Artefakt eingeordnet. Seine wahre Stärke in der Incident-Response liegt hostübergreifend. Dasselbe Tooling, auf jeder Maschine, die es berührt, auf Kompatibilität geprüft, hinterlässt eine korrelierbare Spur. So nutze ich ihn tatsächlich, um Lateral Movement zu rekonstruieren.

Wie Lateral Movement im Cache aussieht

Remote-Execution-Techniken legen eine ausführbare Datei auf dem Ziel ab oder rufen sie auf. Jede hinterlässt einen charakteristischen Pfad.

TechnikShimCache-Hinweis am Ziel
PsExec / SMB-Service-ExecC:\Windows\PSEXESVC.exe oder eine zufällige 8-Zeichen-Service-Binärdatei in C:\Windows\
sc \\host createAngreiferbenannte Service-Binärdatei, oft in C:\Windows\ oder \PerfLogs\
WMI (wmic process call create)Payload-Pfad unter C:\Windows\Temp\ oder einem benutzerbeschreibbaren Verzeichnis
Geplanter Task (schtasks /s)Task-Action-Binärdatei, häufig C:\Users\Public\
Remote-PowerShell / WinRMpowershell.exe plus jede abgelegte .exe, die es stagete
Impacket smbexec / wmiexecZufällig benannte .bat- und .exe-Dateien unter \Windows\Temp\

Eine Service-Binärdatei mit einem zufälligen Namen in C:\Windows\ ist einer der signalstärksten ShimCache-Funde überhaupt. Behandelt als Triage-Regel in Malware mit dem ShimCache jagen.

Die Seite des Quellhosts

Der ursprüngliche Host zeigt häufig ShimCache-Einträge für das Angriffs-Tooling selbst: PsExec.exe, interaktiv genutztes wmic.exe, einen eigenen Mover, einen Post-Exploitation-Framework-Loader. "Tool auf Host A" mit "Service-Binärdatei auf Host B" in einem plausiblen Fenster zu paaren, ist der Kern der Lateral-Movement-Inferenz.

Quervergleich mit Sysmon Event ID 3 Netzwerkverbindungen und Security 4624 Logon-Typ 3, um den Kreis zu schließen. Der EVTX-Parser deckt die relevanten Event-IDs ab.

Der hostübergreifende Diff-Workflow

  1. Sammle SYSTEM-Hives von jedem Host im Geltungsbereich. Siehe Einen SYSTEM-Hive beschaffen. Oder nutze Velociraptor für Flottenerfassung.
  2. Parse jeden und exportiere nach CSV. Eric Zimmermans AppCompatCacheParser ist die richtige Antwort für Batch-Arbeit.
  3. Normalisiere Pfade und diff nach gemeinsamen, ungewöhnlichen Binärdateien. Derselbe zufällige Servicename oder Staging-Pfad, der auf mehreren Hosts erscheint, ist der Bewegungspfad.
  4. Ordne Hosts nach Insertion-Reihenfolge, nicht nach dem Zeitstempel. Der Zeitstempel ist die mtime der Datei, keine Ereigniszeit, also sequenziert er Hops nicht allein.
  5. Belege jeden Hop mit Security 4624 (Logon-Typ 3), 4648 (explizite Anmeldedaten), 7045 (Service-Install) und AmCache für die SHA-1-Zuordnung.

Das fügt sich natürlich in eine vollständige Programmausführungs-Timeline ein. Map die Techniken zu ATT&CK T1021 (Remote Services) und T1570 (Lateral Tool Transfer) für die Berichterstattung.

Vorbehalte

ShimCache wird nur bei sauberem Shutdown geleert, also kann ein noch laufender Host den entscheidenden Eintrag noch nicht geschrieben haben. Prüfe den Speicher (aus einem Memory-Dump extrahieren), bevor du folgerst, dass ein Host nicht berührt wurde. Der Zeitstempel sequenziert Hops nie allein; verlass dich auf die Insertion-Reihenfolge plus EVTX und das USN-Journal für Ereigniszeiten. Angreifer, die den Wert leeren, hinterlassen ihren eigenen Hinweis. Siehe ShimCache-Anti-Forensik.

Um Hives schnell zu diffen, parse jeden mit dem Shimcache Parser und vergleiche clientseitig. Der CSV-Export aus EZs Tool fließt direkt in pandas oder csvdiff für größere Sätze.

Weiterführende Lektüre

Verwandte Artikel