Dans cet article, nous allons sortir légèrement du périmètre habituel de l’administration système pour nous intéresser au domaine du forensic sous Windows.

L’objectif est de comprendre comment identifier des traces d’activité sur un système, et surtout quels sont les premiers réflexes à adopter lors d’une analyse post-incident. Sans entrer dans une analyse avancée, nous allons nous concentrer sur des techniques simples, mais efficaces, permettant de récupérer des indices exploitables rapidement.

Pour débuter, nous allons explorer un artefact bien connu : le ShimCache (également appelé AppCompatCache). Cet élément peut contenir des informations précieuses sur des fichiers ayant été présents ou exécutés sur un système. Nous verrons comment exploiter ces données pour identifier des fichiers suspects et amorcer une première analyse forensic.

Introduction au Forensic

Le forensic, ou informatique légale, est une discipline qui consiste à collecter, analyser et préserver des preuves numériques afin de comprendre une activité ou un incident sur un système.

Sous Windows, cela revient à exploiter différentes sources de données afin de reconstituer une chronologie d’événements, d’identifier des actions suspectes et, dans certains cas, d’attribuer ces actions à un utilisateur ou à un processus.

Dans le cadre d’une analyse forensic, il est essentiel de distinguer plusieurs types de données, car chacune possède ses propres caractéristiques, sa durée de vie et son niveau de volatilité. Nous pouvons les regrouper en trois grandes catégories :

Les données persistantes (physiques)

Il s’agit des données stockées de manière durable sur le disque. Elles restent présentes même après un redémarrage du système.

On y retrouve notamment :

• les journaux d’événements Windows
• les artefacts comme le ShimCache ou l’Amcache
• les fichiers système et applicatifs
• les traces laissées dans le registre

Ces données constituent la base de toute analyse forensic, car elles permettent de remonter dans le temps et d’établir un historique des activités.

Les données centralisées (séquentielles)

Ces données correspondent aux informations collectées et transférées vers des systèmes externes, comme un SIEM ou un EDR.

Elles présentent plusieurs avantages :

• elles sont accessibles sans interagir directement avec la machine compromise
• elles peuvent contenir des événements déjà corrélés ou enrichis
• elles permettent de conserver des traces même si le système est altéré ou nettoyé

Exemples :

• logs envoyés vers un SIEM
• télémétrie EDR
• journaux centralisés sur un serveur de logs

Ces données sont particulièrement utiles dans une approche de détection et de réponse à incident à distance.

Les données volatiles (temporaires)

Il s’agit des données présentes uniquement à un instant donné, généralement en mémoire ou dans des emplacements temporaires.

Elles sont critiques, mais très fragiles, car elles peuvent disparaître lors d’un redémarrage ou de l’arrêt du système.

On y retrouve par exemple :

• le contenu de la mémoire (RAM)
• les processus en cours d’exécution
• les connexions réseau actives
• les fichiers temporaires

Ces données sont souvent les plus riches en informations lors d’une compromission en cours, mais elles nécessitent une intervention rapide pour être capturées avant leur disparition.

Comprendre le ShimCache

Pour comprendre le ShimCache, il faut d’abord comprendre comment Windows gère la compatibilité des applications en interne.

Lorsqu’une application rencontre un problème de compatibilité (par exemple à cause d’un changement d’API entre versions de Windows), le système s’appuie sur une base de données de compatibilité appelée Shim Database (SDB). Cette base contient des correctifs permettant d’adapter le comportement des programmes sans modifier leur code.

Ces fichiers SDB sont stockés sur le système, par exemple dans :

On y retrouve notamment :

Lorsqu’un programme est exécuté, Windows peut intercepter certains appels via des couches de compatibilité appelées Shims. Concrètement, au lieu d’appeler directement une API Windows, l’application passe par ce mécanisme intermédiaire qui ajuste la requête ou la réponse.

Le Shim agit donc comme une couche d’interception entre l’application et le système.

Ce mécanisme est notamment piloté par des fonctions internes de Windows (comme dans ), qui vont consulter la base SDB pour déterminer si un correctif doit être appliqué. Dans ce contexte, le ShimCache () est utilisé comme un cache rapide contenant des informations sur les exécutables rencontrés par le système.

En simplifiant le flux :

• Un programme est lancé
• Windows vérifie sa compatibilité via la base SDB
• Les appels API peuvent être interceptés par les shims
• Le système analyse le fichier
• Une entrée est ajoutée dans le ShimCache
• Ces informations sont ensuite stockées dans le registre

Ce mécanisme n’a jamais été conçu pour la sécurité, mais uniquement pour la compatibilité applicative. Cependant, il laisse derrière lui des traces exploitables, ce qui en fait aujourd’hui un artefact très utilisé en forensic.

Le ShimCache est stocké dans le registre Windows sous le chemin suivant :

Et dans le fichier physique de la ruche :

Les limites de l’analyse du ShimCache

Le ShimCache présente malgré tout quelques limites qu’il est important de garder en tête lors d’une analyse forensic.

Tout d’abord, il possède une taille limitée (par exemple autour de 1024 entrées selon les versions de Windows). Cela signifie que les anciennes entrées sont progressivement écrasées par les nouvelles, ce qui peut entraîner une perte d’historique.

Ensuite, il ne contient pas uniquement des programmes exécutés. Le ShimCache peut également référencer des fichiers simplement ouverts, parcourus ou analysés par le système. Autrement dit, la présence d’un fichier dans ce cache ne garantit pas qu’il ait été réellement exécuté. Pour cela, il devra être complété par des sources comme et et que nous verrons dans un prochain article.

Analyser le fichier ShimCache

Nous allons maintenant passer à l’analyse de ce fichier.

Dans un premier temps, si l’on ouvre directement la clé de registre contenant la valeur , on constate rapidement que les données sont au format binaire. Ces informations ne sont donc pas exploitables en l’état et restent difficilement lisibles sans outil adapté.

Pour faciliter l’analyse, nous allons utiliser un outil bien connu dans le monde du forensic, développé par Eric Zimmerman. Sa suite d’outils permet notamment de parser facilement le contenu du ShimCache.

Vous pouvez télécharger les outils ici :

• Télécharger l’outil AppCimpartCacheParser

Téléchargez l’outil AppCimpartCacheParser et placez-le dans un dossier après extraction, pour ma part je l’ai mis dans le dossier .

Ensuite, ouvrez une invite de commande en administrateur et exécutez l’outil avec les paramètres suivants :

Première analyse

Avant d’exécuter la commande, j’ai simplement parcouru le dossier SysInternals jusqu’au fichier , sans lancer le programme. Il s’agit donc uniquement d’une navigation dans les fichiers.

Après un redémarrage du système, j’exécute la commande précédente pour générer le fichier .

En analysant le fichier, on constate que les éléments parcourus apparaissent bien dans le ShimCache, jusqu’au niveau atteint dans l’exploration.

Deuxième analyse

Dans un second test, je suis allé un peu plus loin dans le dossier, jusqu’au fichier toujours sans exécuter le programme.

Après un nouveau redémarrage, j’exécute à nouveau la commande pour générer un fichier .

Cette fois encore, les fichiers visibles lors de la navigation apparaissent dans le résultat. On remarque notamment la présence de fichiers , mais pas forcément d’autres types de fichiers.

Cas réel : un fichier supprimé

Pour aller plus loin, j’ai téléchargé un échantillon du malware WannaCry. Celui-ci a été immédiatement supprimé par l’antivirus. Malgré cela, une trace apparaît dans le ShimCache. Cela montre un point très intéressant en forensic : même si un fichier est supprimé rapidement, il peut laisser une trace exploitable dans le cache

Note : contrairement à une idée répandue, la présence d’une entrée dans le ShimCache ne signifie pas qu’un shim a été appliqué. Une application peut être parfaitement compatible avec Windows et apparaître dans le cache sans qu’aucun mécanisme de correction ne soit utilisé.

Le ShimCache reflète donc les fichiers observés par le système, et non uniquement les applications corrigées par les shims.

Conclusion

Vous l’avez compris, le ShimCache contient des informations et des horodatages sur les fichiers rencontrés par le système : fichiers ouverts, parcourus ou analysés… mais pas nécessairement exécutés.

Il constitue donc un excellent point de départ dans une analyse forensic, notamment pour identifier des outils suspects comme BloodHound, Mimikatz ou d’autres exécutables. Cependant, en tenant compte des limites précédemment citées, il doit être corrélé avec d’autres artefacts comme Prefetch, Amcache ou les journaux d’événements.