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

4 min de lecture

TL;DR. Les attaquants combattent le ShimCache surtout en évitant les arrêts propres (pour qu'il ne soit jamais écrit). Les éditions directes du registre laissent généralement le blob malformé. Repérez l'altération via des caches anormalement courts, des binaires Windows toujours-présents manquants, des tailles d'entrée malformées, ou une divergence mémoire/disque.

Le ShimCache est plus difficile à altérer que la plupart des artefacts Windows, mais il n'est pas intouchable. Ce billet passe en revue ce que les attaquants tentent réellement, pourquoi la plupart de ces tentatives laissent des empreintes, et comment détecter une altération à l'analyse.

La boîte à outils anti-forensique de l'attaquant

1. Reboot dur avant le flush. L'« anti-forensique » la plus propre contre le ShimCache est de ne jamais donner à Windows la chance de l'écrire. Si l'attaquant force une coupure dure (ou tue une VM au niveau hyperviseur), le ShimCache en mémoire pour cette session est simplement perdu. La ruche sur disque garde ce qui avait été flushé au précédent arrêt propre. Voir quand le cache est écrit pour le mécanisme.

2. Édition directe de la valeur du registre. Un attaquant privilégié peut écraser la valeur HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. En théorie, cela permet de retirer des entrées spécifiques — en pratique, la mise en page binaire est suffisamment non triviale pour que les mauvaises éditions laissent généralement le blob malformé.

3. Remplacement de la ruche SYSTEM hors ligne. Si l'attaquant peut mettre le système hors ligne, il peut échanger le fichier de ruche. C'est rare dans les intrusions opportunistes mais apparaît dans les cas étatiques.

4. Time stomping du binaire. Parce que le ShimCache stocke le mtime $STANDARD_INFORMATION du fichier, un attaquant qui altère l'horodatage du binaire avant que Windows l'examine décale l'horodatage caché. Le ShimCache lui-même ne ment pas — les métadonnées qu'il a capturées avaient déjà été altérées.

5. Effacement d'AmCache et Prefetch. Les attaquants qui connaissent les artefacts corroborants les effacent souvent aussi, laissant le ShimCache comme témoin solitaire et en espérant qu'il sera écarté pour les raisons de notre billet sur la preuve d'exécution.

Indices de détection

Quand vous suspectez une altération, cherchez :

  • ShimCache anormalement court. Windows remplit le cache jusqu'à ~1 024 entrées en usage normal. Un blob avec seulement quelques entrées sur un système qui tourne depuis des jours est un fort signal d'altération.
  • Entrées toujours-présentes manquantes. Plusieurs binaires Windows apparaissent de façon fiable dans presque tous les ShimCache (selon la version : shell, helpers de tâches planifiées, outillage Windows Update). Leur absence sur un poste utilisé est suspecte.
  • Tailles d'entrées malformées. Un blob qui échoue au parsing en cours de route, avec le reste du buffer mis à zéro ou rempli de bruit, est un indicateur classique d'édition maladroite. Le Shimcache Parser le remontera comme une erreur explicite.
  • Divergence mémoire / disque. Comparez le ShimCache extrait de la mémoire (guide) avec la ruche sur disque. Les entrées présentes en mémoire mais absentes sur disque peuvent signifier un reboot dur — mais les entrées présentes sur disque qui contredisent la mémoire (chemins ou mtime différents pour le même slot) suggèrent que quelqu'un a écrit dans la ruche.
  • AmCache et ShimCache désaccordés. Si AmCache montre qu'un binaire s'est exécuté mais que le ShimCache qui devrait également porter l'entrée est vide, demandez pourquoi. Les effacements de ShimCache qui n'ont pas touché AmCache sont courants parce que les attaquants ne réalisent pas toujours qu'AmCache existe.

Ce que cela dit aux enquêteurs

Quelques règles pratiques :

  • Traitez un ShimCache vide ou quasi-vide comme une preuve, pas comme une absence de preuves. Documentez-le.
  • Récupérez l'image mémoire quand vous pouvez. Elle attrape souvent ce que la ruche a perdu.
  • Corroborez toujours avec AmCache et Prefetch (référence). Trois artefacts sont beaucoup plus difficiles à effacer de façon cohérente qu'un seul.
  • N'affirmez pas « l'attaquant a effacé le ShimCache » sans pouvoir montrer ce qui a été effacé — pointez sur des trous dans le nombre d'entrées, des binaires de base manquants, ou une divergence mémoire/disque.

Pour aller plus loin

Articles connexes