TL;DR. Le ShimCache vit en mémoire ; la ruche SYSTEM sur disque ne contient que les entrées flushées au dernier arrêt propre. Pour récupérer les entrées de la session courante d'un hôte en marche ou crashé, lancez windows.shimcachemem de Volatility 3 (ou l'artefact Windows.Registry.AppCompatCache de Velociraptor) sur une image mémoire.
Le ShimCache vit en mémoire volatile pendant que Windows tourne, et n'est écrit dans la ruche SYSTEM qu'à l'arrêt propre (plus de détails sur la temporisation). Cela signifie qu'une image mémoire d'un hôte en marche est souvent le seul endroit pour trouver les entrées ShimCache de la dernière session — exactement les entrées les plus susceptibles d'être pertinentes pour un incident actif.
Quand la copie mémoire compte plus que la copie disque
Vous voulez le ShimCache en mémoire quand :
- L'hôte n'a pas été arrêté proprement depuis l'incident. La plupart des reboots durs, BSOD et coupures forcées laissent le ShimCache de la ruche SYSTEM périmé.
- Vous suspectez de l'anti-forensique. Un attaquant qui a édité la ruche sur disque n'a peut-être pas touché à la copie en mémoire (qui se reconstruit à chaque session). Voir détection anti-forensique.
- Vous avez besoin d'entrées qui ont été évincées de la ruche sur disque au dernier flush. Le plafond de 1 024 entrées fait tourner les anciennes entrées, mais elles peuvent encore être en mémoire sous 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
Il parcourt les structures AppCompatCache dans la représentation en mémoire de la ruche SYSTEM et imprime des lignes (mtime, chemin) comme le ferait un parser hors ligne. La source et les notes d'utilisation du plugin vivent dans le repo Volatility 2.
Avec Volatility 3
Volatility 3 le porte en windows.shimcachemem :
vol -f memory.raw windows.shimcachemem
Plus de sélection de profil (Vol 3 détecte automatiquement l'OS). La documentation Volatility 3 documente le plugin avec le reste du set d'artefacts Windows.
Avec Velociraptor
Si vous collectez à grande échelle plutôt que d'analyser un dump unique, l'artefact Windows.Registry.AppCompatCache de Velociraptor lit le ShimCache en mémoire directement depuis un endpoint en marche via la vue registre live. C'est le même ShimCache que l'OS aurait flushé à l'arrêt — sans attendre l'arrêt.
Combiner les deux vues
En pratique, vous aurez souvent :
- le ShimCache en mémoire depuis un plugin Volatility ou une collecte Velociraptor,
- le ShimCache sur disque depuis la ruche SYSTEM du même hôte.
La copie mémoire est un sur-ensemble de la copie disque tant qu'un arrêt propre n'a pas eu lieu — mais la copie disque peut inclure des entrées déjà évincées de mémoire après un long uptime. Récupérez les deux, dédupliquez par (chemin, mtime), et alimentez l'union dans votre workflow de chasse.
Étapes utiles ensuite
Une fois les entrées récupérées :
- Utilisez le Shimcache Parser pour un triage hors ligne rapide d'une ruche extraite — ça tourne dans votre navigateur, sans upload.
- Voir la référence du format binaire si vous décodez le blob brut vous-même.
- Voir la preuve d'exécution avant d'affirmer qu'une entrée récupérée en mémoire signifie qu'un programme a tourné.
Pour aller plus loin
- Documentation Volatility 3 — le framework moderne de forensique mémoire.
- Volatility Foundation sur GitHub — source des plugins, dont
shimcachemem. - Velociraptor
Windows.Registry.AppCompatCache— collecte sur système vivant.