TL;DR. Les outils de déplacement 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. Comparer l'AppCompatCache entre de nombreux hôtes fait apparaître le chemin emprunté par l'attaquant.
Le ShimCache est généralement présenté comme un artefact mono-hôte. Mais sa vraie puissance en réponse à incident est inter-hôtes : le même outillage, examiné pour compatibilité sur chaque machine qu'il touche, laisse une piste corrélable. Ce billet explique comment lire cette piste.
À quoi ressemble un déplacement latéral dans le ShimCache
Les techniques d'exécution à distance déposent ou invoquent un exécutable sur la destination. Chacune laisse un chemin caractéristique :
| Technique | Indice ShimCache côté destination |
|---|---|
| PsExec / exéc. service SMB | C:\Windows\PSEXESVC.exe ou un binaire de service à 8 caractères aléatoires dans C:\Windows\ |
sc \\host create | Binaire de service nommé par l'attaquant, souvent dans C:\Windows\ ou \PerfLogs\ |
WMI (wmic process call create) | Chemin de charge sous C:\Windows\Temp\ ou un dossier accessible en écriture |
Tâche planifiée (schtasks /s) | Binaire d'action de tâche, souvent C:\Users\Public\ |
| PowerShell distant | powershell.exe plus tout .exe déposé qu'il a préparé |
Un binaire de service au nom aléatoire dans C:\Windows\ est l'un des constats ShimCache les plus forts qui soient — traité comme règle de triage dans chasser le malware avec le ShimCache.
Le côté hôte source
L'hôte d'origine montre fréquemment des entrées ShimCache pour l'outillage d'attaque lui-même : PsExec.exe, wmic.exe utilisé en interactif, un déplaceur sur mesure ou des frameworks de post-exploitation. Apparier « outil sur l'hôte A » avec « binaire de service sur l'hôte B » dans une fenêtre plausible est l'inférence centrale du déplacement latéral.
Le flux de comparaison inter-hôtes
- Collectez les ruches SYSTEM de chaque hôte en périmètre (voir acquérir une ruche SYSTEM).
- Analysez chacune et exportez en CSV.
- Normalisez les chemins et comparez les binaires partagés et inhabituels — le même nom de service aléatoire ou le même chemin de staging sur plusieurs hôtes est le chemin de déplacement.
- Ordonnez les hôtes par l'ordre d'insertion ShimCache (pas l'horodatage — c'est le mtime du fichier, pas une heure d'événement).
- Corroborez chaque saut avec Security 4624/4648, les événements 7045 d'installation de service et AmCache.
Cela se fond naturellement dans une chronologie complète d'exécution de programmes. Mappez les techniques sur ATT&CK T1021 (Remote Services) et T1570 (Lateral Tool Transfer) pour le rapport.
Réserves
Le ShimCache ne flushe qu'à l'arrêt propre ; un hôte encore allumé n'a peut-être pas encore écrit l'entrée décisive — vérifiez la mémoire (extraction depuis un dump mémoire). Et l'horodatage ne séquence jamais les sauts à lui seul ; appuyez-vous sur l'ordre d'insertion plus les journaux d'événements. Les attaquants qui effacent la valeur laissent leur propre indice — voir anti-forensique du ShimCache.
Pour comparer rapidement les ruches, analysez chacune avec le Shimcache Parser, exportez en CSV et comparez — tout côté client.
Pour aller plus loin
- MITRE ATT&CK : Remote Services (T1021) — référence de technique pour les indices côté destination.
- Mandiant : leveraging the ShimCache — fondamentaux du ShimCache.