fr

Les attaquants peuvent-ils vider le ShimCache ? Anti-forensique et détection

5 min de lecture

TL;DR. Les attaquants combattent le ShimCache surtout en évitant les arrêts propres pour que le cache ne soit jamais vidé. Les éditions directes du registre laissent généralement le blob malformé. Repère la manipulation via des caches anormalement courts, l'absence de binaires Windows toujours présents, des tailles d'entrée malformées, ou une divergence mémoire/disque.

Le cache est plus difficile à manipuler que la plupart des artefacts Windows. Pas impossible. Après quelques incidents, tu arrêtes d'être surpris par ce que les attaquants tentent et tu commences à être surpris de la fréquence à laquelle ils laissent des empreintes. Voici le catalogue des techniques que j'ai effectivement vu utiliser, et ce que chacune laisse derrière elle.

Ce que les attaquants tentent vraiment

1. Reboot brutal avant flush. L'anti-forensique la plus propre contre le cache, c'est de ne jamais laisser à Windows la chance de l'écrire. Force un power-off dur, ou tue la VM à l'hyperviseur, et le ShimCache en mémoire de cette session est simplement perdu. Le hive sur disque contient encore ce qui a été vidé au précédent arrêt propre. C'est de loin le motif le plus courant dans les engagements ransomware. Voir quand le cache est écrit pour le mécanisme.

2. Éditions directes du blob de la valeur. Un attaquant en niveau SYSTEM peut écraser HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. En théorie ça enlève des entrées spécifiques. En pratique la disposition binaire est assez non triviale pour que les éditions à la main laissent généralement le blob malformé ou un compte d'entrées absurde.

3. Remplacement hors ligne du hive. Si l'attaquant peut arrêter le système, il peut substituer le hive SYSTEM en entier. Rare en dehors du travail d'État-nation mais ça arrive. Le registry parser peut te montrer si les horodatages et la structure du hive SYSTEM sont cohérents avec le reste des artefacts de l'hôte.

4. Timestomping du binaire. Comme le cache stocke la mtime $STANDARD_INFORMATION du fichier, un attaquant qui timestomp le binaire avant que Windows ne l'examine décale l'horodatage caché. Le cache ne ment pas ; les métadonnées du fichier qu'il a capturées étaient déjà manipulées. Croise avec l'attribut $FILE_NAME de la MFT, plus difficile à stomper.

5. Effacement des artefacts corroborants. Les attaquants qui apprennent ce que fait le ShimCache vident souvent aussi AmCache, Prefetch, EVTX et la corbeille, en laissant le ShimCache comme témoin solitaire en espérant qu'il sera écarté pour les raisons du billet sur la preuve d'exécution.

Indices de détection

Quand tu soupçonnes une manipulation, cherche :

  • Cache anormalement court. Windows remplit le cache à environ 1 024 entrées avec un usage normal. Un blob avec une poignée d'entrées sur un système qui tourne depuis plusieurs jours, c'est un signal fort de manipulation.
  • Entrées toujours présentes manquantes. Plusieurs binaires Windows apparaissent de manière fiable dans quasiment tous les ShimCache, selon la version : composants shell, helpers de tâches planifiées, outillage de mise à jour OS. Leur absence sur un poste utilisé est suspecte.
  • Tailles d'entrée malformées. Un blob qui échoue au parsing en cours de route, avec le reste du buffer à zéro ou rempli de déchets, est un indicateur classique d'édition maladroite. Le Shimcache Parser remonte cela comme une erreur explicite.
  • Divergence en mémoire et sur disque. Compare le cache extrait d'un dump RAM avec le hive sur disque (guide d'extraction). Des entrées présentes en mémoire mais absentes sur disque peuvent signifier un reboot brutal. Des entrées présentes sur disque qui contredisent la mémoire (chemins ou mtimes différents pour le même slot) suggèrent que quelqu'un a écrit dans le hive.
  • Mismatch AmCache et ShimCache. AmCache montre un binaire exécuté mais le ShimCache est vide pour ce fichier. Demande pourquoi. Les attaquants qui essuient le ShimCache oublient souvent qu'AmCache existe.
  • Empreintes d'outils anti-forensiques. Regarde dans Prefetch, Sysmon Event ID 1 et le journal USN pour des traces de reg.exe, PowerShell Remove-ItemProperty ou d'éditeurs de hive tiers dans la fenêtre pertinente.

Ce que ça dit aux enquêteurs

Quelques règles pratiques que j'impose à chaque rapport :

  • Traite un ShimCache vide ou quasi vide comme une preuve. Pas comme une absence de preuve. Documente-le explicitement.
  • Prends un dump RAM quand tu peux. Il rattrape souvent ce que le hive a perdu.
  • Corrobore toujours avec AmCache et Prefetch. Voir la référence des artefacts. Trois artefacts sont beaucoup plus durs à essuyer de manière cohérente qu'un seul.
  • Ne revendique pas "l'attaquant a essuyé le ShimCache" sauf si tu peux montrer ce qui a été essuyé. Pointe sur des trous dans le compte d'entrées, des binaires de baseline manquants, ou une divergence mémoire/disque.

Lectures complémentaires

Articles liés