fr

Extraire le ShimCache d'un dump mémoire

4 min de lecture

TL;DR. Le ShimCache vit en mémoire. Le hive SYSTEM sur disque ne contient que les entrées vidées au dernier arrêt propre. Pour récupérer les entrées de la session active d'un hôte en exécution ou crashé, lance windows.shimcachemem de Volatility 3 contre un dump RAM, ou récupère en live avec l'artefact Windows.Registry.AppCompatCache de Velociraptor.

Le cache vit en mémoire volatile pendant que Windows tourne. Il n'est écrit dans le hive SYSTEM qu'à l'arrêt propre. Ça veut dire qu'une image mémoire est souvent le seul endroit où trouver des entrées ShimCache de la session courante, soit exactement les entrées les plus susceptibles d'importer dans un incident actif. Le billet sur le timing de stockage couvre le pourquoi.

Quand la copie mémoire compte plus que le disque

Tu veux le cache en mémoire quand :

  • L'hôte n'a pas été arrêté proprement depuis l'incident. La plupart des reboots brutaux, BSOD et power-offs forcés laissent le ShimCache sur disque périmé.
  • Tu soupçonnes de l'anti-forensique. Un attaquant qui a édité le hive sur disque peut ne pas avoir touché à la copie en mémoire, qui est reconstruite à chaque session. Voir détection d'anti-forensique.
  • Tu as besoin d'entrées qui ont été évincées du hive sur disque au dernier flush. Le plafond de 1 024 entrées fait tourner les vieilles, mais elles peuvent encore être en mémoire dans certaines conditions.

Avec Volatility 2

Le plugin classique est shimcachemem. Contre une image mémoire XP à Win10 :

vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem

Parcourt les structures AppCompatCache dans la représentation en mémoire du hive SYSTEM et affiche des lignes (mtime, path) comme le ferait un parser hors ligne. Le code source du plugin est dans le dépôt Volatility 2.

Avec Volatility 3

Volatility 3 le livre sous le nom windows.shimcachemem :

vol -f memory.raw windows.shimcachemem

Plus de sélection de profil. Vol 3 détermine l'OS automatiquement. La doc Volatility 3 documente le plugin avec le reste du set d'artefacts Windows. Pendant que tu as le dump ouvert, profites-en pour récupérer aussi les processus, les connexions réseau et les listes de modules. Le parser RAM couvre le workflow plus large de memory forensics.

Avec Velociraptor

Pour collecter à grande échelle plutôt qu'analyser un dump unique, l'artefact Windows.Registry.AppCompatCache de Velociraptor lit le ShimCache en mémoire directement depuis un endpoint en exécution via la vue registre live. Même cache que l'OS aurait vidé à l'arrêt, sans attendre l'arrêt.

Combiner les deux vues

En pratique tu auras souvent les deux :

  • Le cache en mémoire de Volatility ou Velociraptor.
  • Le cache sur disque du hive SYSTEM sur le même hôte.

La copie mémoire est un sur-ensemble de la copie disque à tout moment où il n'y a pas eu d'arrêt propre. Mais la copie disque peut inclure des entrées déjà évincées de la mémoire après un long uptime. Récupère les deux, dédoublonne par (path, mtime) et fais l'union dans ton workflow de hunting.

Si les deux vues divergent sur les chemins ou les horodatages pour le même slot, c'est un indicateur de manipulation. Voir anti-forensique.

Étapes suivantes utiles

Une fois que tu as les entrées :

  • Utilise le Shimcache Parser pour du triage hors ligne rapide d'un hive extrait. Tourne dans ton navigateur, sans téléversement.
  • Voir la référence du format binaire si tu décodes le blob brut toi-même.
  • Voir preuve d'exécution avant de prétendre qu'une entrée récupérée en mémoire signifie qu'un programme a tourné.
  • Carve pagefile.sys si tu suspectes que le cache a été partiellement effacé de la mémoire et du disque ; des fragments survivent parfois dans le swap.

Lectures complémentaires

Articles liés