Nous poursuivons notre analyse forensic sous Windows en nous intéressant aux traces laissées par les activités sur un système. Après avoir étudié le ShimCache dans le précédent article, nous allons cette fois nous pencher sur un artefact souvent sous-estimé, mais particulièrement riche : l’Amcache.
Là où le ShimCache permet d’identifier des fichiers observés par le système, l’Amcache va plus loin en apportant des informations détaillées sur les exécutables, leur origine et leur cycle de vie. C’est un artefact précieux pour mettre en évidence des outils utilisés ponctuellement, même après leur suppression.
L’objectif de cet article est de comprendre son fonctionnement, d’explorer son contenu et de voir concrètement comment il peut être exploité dans une démarche d’investigation.
Qu’est-ce que c’est l’Amcache ?
Le fichier Amcache.hve a été introduit à partir de Windows 8 pour remplacer le fichier RecentFileCache.bcf utilisé sous Windows 7.
Il est associé au mécanisme de compatibilité des applications Windows, aussi appelé AppCompat, dont le rôle est d’assurer le bon fonctionnement des programmes sur différentes versions du système.
Contrairement au ShimCache, qui se limite principalement à la présence de fichiers observés par le système, l’Amcache va beaucoup plus loin en enregistrant des informations détaillées sur les exécutables et leur utilisation.
On y retrouve notamment :
Les chemins complets des exécutables
La date et l’heure de première exécution et de suppression.
Des informations de hachage des fichiers, le SHA-1 du fichier binaire.
Des métadonnées sur les fichiers exécutés ou analysés (taille du fichier en octets)
Version du programme, informations sur l’éditeur.
Des informations sur les périphériques connectés (USB, Bluetooth)
L’Amcache conserve donc des traces persistantes des fichiers ayant été exécutés, ou ayant interagi avec le système, même après leur suppression.
Il s’inscrit pleinement dans le framework AppCompat, qui enregistre ces informations afin d’optimiser la compatibilité, mais qui devient, côté sécurité, une source précieuse pour les analystes forensic.
Le fichier Amcache est stocké à l’emplacement suivant : C:\Windows\AppCompat\Programs\Amcache.hve.
Analyse du fichier Amcache
Nous allons maintenant extraire les informations contenues dans le fichier Amcache afin de mieux comprendre sa structure et son contenu, avant de passer à une analyse plus avancée. Pour cela, nous utiliserons la suite d’outils développée par Eric Zimmerman.
Commencez par télécharger l’outil AmcacheParser, puis extrayez-le dans un dossier. Dans notre cas, l’outil a été extrait dans C:\Temp.
Analyse via ligne de commande
Depuis un terminal, nous allons parser le fichier Amcache à partir de son emplacement par défaut. Notez qu’il est possible de récupérer le fichier Amcache.hve depuis une autre machine et de l’analyser en local.
Exécutez la commande suivante:
AmcacheParser.exe –f C:\Windows\appcompat\Programs\Amcache.hv –csv Cache1
La commande nous a généré un dossier nommé Cache1 dans le répertoire de l’outil. Ce dossier contient plusieurs fichiers CSV, chacun correspondant à une catégorie d’informations issue de l’Amcache.
Par exemple, si nous ouvrons le fichier lié aux raccourcis (Shortcuts), nous y retrouvons des informations sur les fichiers .lnk, comme :
le chemin du raccourci
la cible associée
des informations temporelles
Ci-dessous une description du contenu des fichiers générés.
✅ Amcache_DeviceContainers
Ce fichier regroupe les informations globales sur les périphériques ayant été connectés au système.➤➤
On y retrouve notamment des éléments permettant d’identifier un appareil de manière unique, son type, ainsi que la manière dont il a été découvert (USB, Bluetooth, etc.).
D’un point de vue forensic, ce fichier est particulièrement intéressant pour retracer :
L’utilisation de périphériques externes
La présence de matériel potentiellement non autorisés
Des connexions ponctuelles (clé USB, casque Bluetooth, téléphone…)
Même si le périphérique n’est plus présent, sa trace peut persister ici.
✅ Amcache_DevicePnps
Ce fichier va plus loin en détaillant les périphériques détectés au niveau système, en lien avec leur pilote et leur configuration.
Il permet de comprendre :
Quel type de matériel a été utilisé ?
Quel pilote a été installé ?
À quel moment le périphérique a été pris en charge par le système ?
En investigation, cela permet de valider qu’un périphérique a réellement été installé et utilisé, et pas simplement branché.
C’est également utile pour détecter :
Des périphériques exotiques
Des drivers non standards
Ou des comportements anormaux liés à du matériel spécifique
✅ Amcache_DriveBinaries
Ce fichier est centré sur les pilotes présents sur le système. Il contient des informations sur les fichiers binaires des drivers, leur origine et leurs caractéristiques.
Côté forensic, il permet notamment :
D’identifier des pilotes malveillants (rootkits, drivers injectés)
De vérifier si un pilote est natif Windows ou ajouté manuellement
D’analyser l’origine et l’éditeur du code exécuté en mode kernel
C’est une source intéressante dans les cas d’attaques avancées où des composants bas niveau sont utilisés.
✅ Amcache_ShortCuts
Ce fichier contient des informations sur les raccourcis (.lnk) présents sur le système. Même si cela peut sembler anodin, c’est en réalité très utile en investigation, car :
Les raccourcis peuvent pointer vers des exécutables supprimés
Ils peuvent révéler des chemins inhabituels
Ils permettent d’identifier des actions utilisateur (double-clic, ouverture via raccourci)
C’est souvent une piste complémentaire pour reconstruire l’activité d’un utilisateur.
✅ Amcache_DriverPackages
Ce fichier permet de retracer l’installation des packages de pilotes sur le système. Il donne une vision plus globale que les simples binaires, en incluant :
Les répertoires d’installation
Les informations fournisseur
Les identifiants matériels associés
En forensic, cela permet de dater l’installation d’un périphérique, d’identifier l’origine d’un driver et même de détecter des installations suspectes ou non prévues.
✅ Amcache_UnassociatedFileEntries
C’est sans doute l’un des fichiers les plus intéressants dans notre analyse. Ce dernier contient des informations sur les fichiers exécutables qui ne sont pas forcément liés à une application installée de manière classique.
Concrètement, on y retrouve :
Des exécutables lancés manuellement
Des outils téléchargés puis supprimés
Des fichiers isolés hors installation standard
C’est typiquement ici que l’on peut retrouver des traces d’outils offensifs comme Mimikatz et BloodHound, que vous connaissez certainement si vous êtes familier avec la sécurité Active Directory.
Même après suppression du fichier, certaines informations comme le chemin ou le hash peuvent rester accessibles. C’est donc une source clé pour identifier des activités suspectes qui ne laissent pas de traces ailleurs.
Structure du fichier
La lecture des fichiers CSV générés facilite l’analyse. Cependant, pour bien comprendre le fonctionnement de l’Amcache, il est nécessaire d’examiner directement la structure de la ruche. En effet, le fichier Amcache.hve est une ruche de registre qui contient un ensemble de clés et de sous-clés organisées de manière hiérarchique.
Chargement de la ruche dans le registre
Afin d’explorer son contenu, nous devrions charger le fichier Amcache.hve dans le registre. Ce dernier étant en lecture seule, il est protégé par le système et la copie ne sera pas possible. J’ai alors récupéré le fichier à partir d’une copie VSS en le copiant directement dans le répertoire Temp.
Une fois copié, nous allons charger le fichier à partir de l’éditeur du registre.
Depuis la clé HKLM, sélectionnez “Fichier”, puis chargez une ruche et donnez un nom à la base. Nous l’avons appelé ici : AnalyseAM1.
Une fois chargée, la structure apparaît clairement avec plusieurs clés organisées sous Root.
On y retrouve notamment :
Des informations sur les applications
Des données liées aux fichiers exécutables
Des informations sur les pilotes (drivers)
Des éléments liés à des composants système (ex : AppLocker, Office VBA…)
L’ensemble constitue une base d’inventaire très riche.
Au niveau de la clé InventoryApplicationFile, on retrouve des informations détaillées sur les exécutables. Comme le montre l’image ci-dessous, nous avons le chemin d’exécutable “Copilot” ainsi que les informations sur l’éditeur, la version ….
Nous pouvons en déduire que l’exploration directe de la ruche permet de mieux comprendre l’organisation interne de l’Amcache ainsi que la richesse des informations qu’elle contient. Elle peut également apporter des pistes complémentaires lorsque l’analyse des fichiers CSV ne permet pas d’aboutir.
Nous revenons maintenant sur les fichiers CSV extraits précédemment afin de les exploiter. Pour cela, nous pouvons ouvrir ces fichiers avec un éditeur CSV (Excel, Notepad++, etc.) afin d’avoir une meilleure lisibilité des données.
En ouvrant le fichier UnassociatedFileEntries, nous pouvons observer un grand nombre d’informations intéressantes. Ce fichier est particulièrement important car il contient :
Des exécutables isolés
Des fichiers non liés à une installation classique
Des traces de programmes exécutés puis supprimés
C’est souvent ici que l’on retrouve des outils utilisés ponctuellement.
Filtrage des données
Pour faciliter l’analyse, il est recommandé de filtrer les résultats. Une première approche consiste à filtrer sur la colonne ProductName afin d’exclure :
Les outils Microsoft
Les logiciels connus
Les composants système
Cela permet de faire ressortir rapidement des éléments suspects.
Le filtrage nous a permis de mettre en évidence l’exécution d’un outil comme Mimikatz, pourtant supprimé du système.
Interprétation des données (Defender / SmartScreen)
Nous pouvons également observer des éléments liés à Microsoft Defender, comme certaines entrées associées à des mécanismes de protection (SmartScreen, analyse Defender) juste avant le lancement du fichier suspect ; ceci peut révéler un contournement de l’AV. Ces alertes représentent des points de vigilance importants à corréler avec les journaux d’événements et autres sources de logs afin d’identifier le déroulement exact de l’attaque.
Analyse globale
Nous venons d’explorer l’un des fichiers d’extraction les plus pertinents. Les autres fichiers sont tout aussi importants et doivent être analysés avec la même approche. Les informations restent globalement lisibles, mais leur exploitation demande de la rigueur, une bonne capacité de corrélation et une certaine connaissance du fonctionnement du système.
Si vous souhaitez aller plus loin, je vous mets à disposition des liens vers des analyses plus avancées, notamment des travaux réalisés par l’ANSSI, qui approfondissent l’étude des ruches de registre et apportent un éclairage complémentaire.
Limite importante
Nous allons à présent exécuter deux tâches planifiées qui lancent respectivement un programme Windows et un script .bat. Nous lancerons aussi des outils Sysinternals comme TCPView.
La tâche a bien été lancée.
TCPView est bien ouvert.
Nous effectuons une nouvelle extraction du fichier Amcache.
Après l’analyse du fichier CSV UnassociatedFileEntries, nous constatons que le binaire exécuté via la tâche planifiée, ainsi que notre script .bat, n’apparaissent pas dans le fichier Amcache, contrairement aux outils Sysinternals qui, eux, sont bien enregistrés.
La colonne IsOSComponent (True) indique que le fichier est considéré comme un composant du système d’exploitation. Dans notre cas, la tâche planifiée n’apparaît pas car elle s’appuie sur des binaires déjà connus et reconnus comme légitimes par le système.
Si un fichier exécutable inconnu, ou lancé pour la première fois dans le cadre de cette tâche, avait été utilisé, il aurait très probablement été enregistré dans l’Amcache.
On notera également que les scripts .cmd et PowerShell ne sont pas directement enregistrés, qu’ils soient exécutés manuellement ou via une tâche planifiée. Pour ce type d’activité, il sera nécessaire de compléter l’analyse avec d’autres artefacts, comme les fichiers Prefetch ou les journaux système.
Conclusion
Une fois de plus, nous avons vu que l’exploitation de l’Amcache, en complément du ShimCache, permet de remonter des pistes concrètes sur des comportements suspects ou anormaux.
Cet artefact apporte une vision plus précise des exécutables introduits sur un système, notamment grâce aux informations de hachage et aux différentes métadonnées associées. Il permet par exemple de retrouver des outils exécutés puis supprimés, ce qui en fait une source particulièrement intéressante en investigation.
Cependant, il ne faut pas le considérer comme une source complète. Certaines activités, comme l’exécution de scripts ou l’utilisation de binaires déjà connus du système, peuvent ne pas apparaître.
Pour aller plus loin, il est donc nécessaire de croiser ces informations avec d’autres artefacts, comme le Prefetch ou les journaux système, afin de reconstituer une vision plus fidèle de l’activité réelle de la machine.
Consultant et formateur expert Windows Server et Cloud Azure. Chercheur en Cybersécurité.