Où le ShimCache est-il stocké, et quand est-il écrit ?

4 min de lecture

TL;DR. Le ShimCache vit à HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Windows le reconstruit en mémoire à chaque session et ne le vide dans le hive SYSTEM qu'à l'arrêt propre. Les reboots brutaux peuvent faire disparaître entièrement les entrées récentes. Rejoue SYSTEM.LOG1 et SYSTEM.LOG2 avant de croire ce que tu lis.

La plupart des mésaventures ShimCache remontent à la même cause racine : l'analyste a cru que le cache était mis à jour comme un fichier de log. Ce n'est pas le cas. Le cache vit en mémoire tant que le système tourne, et la copie sur disque ne reflète jamais que l'état du précédent arrêt propre. Comprends cela de travers et tu écris un rapport qui dit que l'hôte est propre alors qu'il ne l'est pas.

ShimCache : écritures en mémoire vs timing de vidage sur disque

Le chemin registre

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

Le AppCompatCache final est une valeur, pas une sous-clé. Les données sont un unique blob binaire dont le schéma varie selon la release Windows. XP, 7, 8, 8.1 et la famille 10/11 utilisent toutes des dispositions différentes. Le guide du format binaire couvre en détail le schéma moderne Windows 10/11.

Hors ligne, tu récupères le hive SYSTEM (l'un des fichiers sous C:\Windows\System32\config\) et tu pointes un parser dessus. Amène SYSTEM.LOG1 et SYSTEM.LOG2 avec toi. Le Shimcache Parser lit le hive SYSTEM dans le navigateur, sans téléversement, mais il ne prend que ce fichier et ne rejoue pas les logs. Si le hive est dirty, rejoue d'abord .LOG1 et .LOG2 avec rla.exe d'Eric Zimmerman (ou charge-le dans Registry Explorer et enregistre le hive nettoyé), puis parse le résultat.

Le piège ControlSet

Windows maintient en réalité plusieurs ControlSets, typiquement ControlSet001 et ControlSet002. À tout moment, exactement un est actif, indiqué par HKLM\SYSTEM\Select\Current. CurrentControlSet est un alias d'exécution pour celui qui est actif. Sur un système vivant, il se résout toujours correctement ; hors ligne, il faut faire le boulot soi-même.

Un parser défendable :

  1. Lit HKLM\SYSTEM\Select\Current (un DWORD, généralement 1 ou 2).
  2. Parcourt la valeur correspondante ControlSetXXX\Control\Session Manager\AppCompatCache\AppCompatCache.
  3. Replie sur le scan à la fois de ControlSet001 et ControlSet002 si Select\Current est illisible.

Cet outil, l'AppCompatCacheParser d'Eric Zimmerman et le Mandiant Shim Cache Parser gèrent tous cette résolution automatiquement. Réécris le tien à tes risques et périls.

Quand Windows écrit vraiment

Voici le morceau qui prend les gens à revers. Pendant que Windows tourne, le ShimCache vit en mémoire. La copie disque n'est écrite qu'à l'arrêt propre. Donc :

  • Un reboot brutal, une coupure de courant, un BSOD ou un kill de VM au niveau de l'hyperviseur détruit toute entrée non encore persistée.
  • Une triage en direct avec reg.exe ou RegRipper lit la valeur précédemment persistée, pas le cache en cours de construction en mémoire.
  • Le plugin windows.shimcachemem de Volatility 3 contre un dump RAM récupère le cache actuel en mémoire. C'est la seule façon de récupérer les entrées de la session active sur un hôte qui n'a pas été arrêté proprement.

Si tu arrives sur une machine compromise qui a été rebootée brutalement, le hive sur disque contient le cache d'avant l'incident. Tout ce que l'attaquant a exécuté dans la session active est parti, sauf si tu as aussi capturé la mémoire. L'histoire corroborante doit le plus souvent venir d'AmCache, qui écrit en continu et survit au même reboot.

Les journaux de transactions

SYSTEM.LOG1 et SYSTEM.LOG2 contiennent les écritures registre pas encore fusionnées dans le hive principal. Tout parser robuste rejoue ces logs avant de lire le ShimCache. Si tu as copié uniquement SYSTEM et zappé les logs, tu lis une vue obsolète. C'est de loin l'erreur d'acquisition la plus fréquente. Le guide d'acquisition couvre les façons sûres de récupérer les trois.

Checklist rapide

  • Valeur ShimCache : HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache.
  • ControlSet actif sélectionné par HKLM\SYSTEM\Select\Current.
  • Stocké en mémoire, vidé uniquement à l'arrêt propre. Corrobore l'activité récente avec AmCache.
  • Toujours rejouer SYSTEM.LOG1 et SYSTEM.LOG2 avant de parser.

Lectures complémentaires

Articles liés