Détecter le mouvement latéral avec le ShimCache

4 min de lecture

TL;DR. Les outils de mouvement latéral (PsExec, wmic, at / schtasks, PowerShell distant) laissent des entrées ShimCache sur l'hôte destination (le binaire de service déposé) et souvent sur la source. Diffuser l'AppCompatCache sur de nombreux hôtes fait remonter le chemin que l'attaquant a pris.

Le ShimCache est généralement présenté comme un artefact mono-hôte. Sa vraie force en réponse à incident est inter-hôtes. Le même tooling, examiné pour compatibilité sur chaque machine qu'il touche, laisse une trace corrélable. Voilà comment je m'en sers vraiment pour reconstruire le mouvement latéral.

À quoi ressemble le mouvement latéral dans le cache

Les techniques d'exécution distante déposent ou invoquent un exécutable sur la destination. Chacune laisse un chemin caractéristique.

TechniqueIndice ShimCache côté destination
PsExec / exécution de service SMBC:\Windows\PSEXESVC.exe ou un binaire de service aléatoire de 8 caractères dans C:\Windows\
sc \\host createBinaire de service nommé par l'attaquant, souvent dans C:\Windows\ ou \PerfLogs\
WMI (wmic process call create)Chemin de la charge utile sous C:\Windows\Temp\ ou un répertoire accessible en écriture par l'utilisateur
Tâche planifiée (schtasks /s)Binaire d'action de la tâche, fréquemment C:\Users\Public\
PowerShell distant / WinRMpowershell.exe plus tout .exe déposé qu'il a stagé
Impacket smbexec / wmiexec.bat et .exe à noms aléatoires sous \Windows\Temp\

Un binaire de service avec un nom aléatoire dans C:\Windows\ est l'une des découvertes ShimCache à plus haut signal qui soient. Traité comme règle de triage dans chasser du malware avec le ShimCache.

Le côté hôte source

L'hôte d'origine montre fréquemment des entrées ShimCache pour le tooling d'attaque lui-même : PsExec.exe, wmic.exe utilisé interactivement, un mover personnalisé, un loader de framework post-exploitation. Apparier "outil sur hôte A" avec "binaire de service sur hôte B" dans une fenêtre plausible est le cœur de l'inférence de mouvement latéral.

Croise avec les connexions réseau Sysmon Event ID 3 et Security 4624 logon type 3 pour boucler la boucle. Le parser EVTX couvre les Event IDs pertinents.

Le workflow de diff inter-hôtes

  1. Collecte les hives SYSTEM de chaque hôte en scope. Voir acquérir un hive SYSTEM. Ou utilise Velociraptor pour la collecte de parc.
  2. Parse chacun et exporte en CSV. L'AppCompatCacheParser d'Eric Zimmerman est la bonne réponse pour du travail en lot.
  3. Normalise les chemins et fais un diff sur des binaires partagés et inhabituels. Le même nom de service aléatoire ou chemin de staging apparaissant sur plusieurs hôtes, c'est le chemin du mouvement.
  4. Ordonne les hôtes par ordre d'insertion, pas par horodatage. L'horodatage est la mtime du fichier, pas un temps d'événement, donc il ne séquence pas les sauts tout seul.
  5. Corrobore chaque saut avec Security 4624 (logon type 3), 4648 (identifiants explicites), 7045 (installation de service), et AmCache pour l'attribution par SHA-1.

Ça se fond naturellement dans une chronologie d'exécution de programmes complète. Mappe les techniques sur ATT&CK T1021 (Remote Services) et T1570 (Lateral Tool Transfer) pour le rapport.

Réserves

Le ShimCache n'est vidé qu'à l'arrêt propre, donc un hôte encore en marche peut ne pas avoir encore écrit l'entrée décisive. Vérifie la mémoire (extraction depuis un dump mémoire) avant de conclure qu'un hôte n'a pas été touché. L'horodatage ne séquence jamais les sauts à lui seul ; appuie-toi sur l'ordre d'insertion plus EVTX et le journal USN pour les temps d'événement. Les attaquants qui effacent la valeur laissent leur propre indice. Voir anti-forensique ShimCache.

Pour diffuser des hives rapidement, parse chacun avec le Shimcache Parser et compare côté client. L'export CSV de l'outil d'EZ alimente directement pandas ou csvdiff pour des ensembles plus larges.

Lectures complémentaires

Articles liés