Prouver qu’un programme a tourné : AmCache, ShimCache et leurs pièges

L’analyste arrive après la bataille. Le binaire suspect a été supprimé, les journaux d’événements ont tourné, et la question qu’on lui pose est la plus simple et la plus mal posée de toute l’investigation : est-ce que ce programme a tourné sur cette machine, et quand ? Windows conserve des réponses partielles dans des bases créées pour une raison qui n’a rien à voir avec la sécurité. Les exploiter correctement suppose de savoir exactement ce qu’elles affirment, et surtout ce qu’elles n’affirment pas.

→ Lire l’explication complète de la marmotte

D’où viennent ces bases : l’infrastructure de compatibilité applicative

Depuis Windows XP, le système embarque une infrastructure de compatibilité applicative, aussi appelée infrastructure de shim, qui permet à une application de continuer à fonctionner alors qu’elle n’est plus tout à fait compatible avec le système ou avec la version d’une de ses dépendances. Techniquement, elle détourne des appels d’interface de programmation du système vers du code de substitution. Pour l’investigateur, elle produit deux artefacts : le cache de compatibilité applicative, communément appelé ShimCache, et, depuis Windows 7 et Server 2008 R2, l’AmCache. C’est le rapport technique publié par l’ANSSI en 2019, signé Blanche Lagny, qui en donne la référence la plus détaillée en accès libre, et tout ce qui suit sur l’AmCache en vient.

L’intérêt de ces bases est leur raison d’être. Elles n’ont pas été conçues pour la sécurité, elles ne sont pas documentées comme telles, aucune alerte ne s’en nourrit, et, comme le note le rapport, leur méconnaissance les rend d’autant plus précieuses : un attaquant qui efface ses traces s’occupe des journaux d’événements et oublie le reste. Leur défaut est le même : ce qui n’a pas été conçu pour prouver quelque chose ne se lit pas comme une preuve sans précaution. Le rapport écrit que « son interprétation correcte est complexe » et qu’un grand nombre de cas particuliers doivent être pris en compte. Les sections suivantes sont la liste de ces cas particuliers, parce que c’est le seul contenu réellement utile sur le sujet.

AmCache : deux temps d’écriture, et une version de bibliothèque

Première chose à comprendre, et celle que presque tout le monde se trompe : le format de l’artefact ne dépend pas de la version du système d’exploitation, mais de la version des bibliothèques qui le remplissent. Ces bibliothèques sont les ae*.dll de %WinDir%\System32, repaquetées à chaque version majeure de Windows et rétroportées par mises à jour jusqu’à Windows 7. Un Windows 7 à jour produit donc le même format qu’un Windows 10, et un Windows 10 ne contient jamais le fichier du format ancien. La conséquence pratique est brutale : avant de conclure quoi que ce soit, l’analyste relève la version des ae*.dll de la machine saisie, et non celle de son système. La règle, le rapport la formule en trois mots dans sa conclusion de présentation : attention à la version des bibliothèques, pas à celle du système.

Deuxième chose : l’artefact se remplit en deux temps. L’exécution d’un exécutable écrit une première trace, puis une tâche planifiée, Microsoft\Windows\Application Experience\ProgramDataUpdater, repasse plus tard pour consolider. Dans le format ancien, l’exécution alimente C:\Windows\AppCompat\Programs\RecentFileCache.bcf, et la tâche planifiée, lancée à 00h30 chaque jour, vide ce fichier et produit un fichier XML AEINV_WER_{identifiant}_date_heure.xml. Dans les formats suivants, l’exécution alimente la ruche de registre C:\Windows\AppCompat\Programs\AmCache.hve, et la tâche planifiée, cette fois toutes les trois nuits environ, met cette ruche à jour et produit un AEINV_AMI_WER_{identifiant}_date_heure.xml, auquel s’ajoute un DevInvCache\PropCache.bin quand il s’agit d’un pilote.

Conséquence méthodologique immédiate : il faut collecter tous les fichiers, pas seulement la ruche. Les XML produits par la tâche planifiée portent des informations que la ruche ne porte pas, ou plus, et c’est souvent là que se trouve le renseignement décisif. Les outils publics existent, AmcacheParser et RecentFileCacheParser d’Eric Zimmerman, un module de RegRipper, et ils sont utiles ; ils ne dispensent pas de ramasser les XML à la main dans l’image disque.

Ce que l’artefact prouve : le condensé qui survit à la suppression

Le scénario le plus courant est celui que l’ANSSI prend comme premier exemple. Un attaquant compromet un compte utilisateur ordinaire, se connecte, exécute un binaire depuis le répertoire de l’utilisateur, puis supprime le fichier. L’analyste, alerté par un comportement suspect, trouve plusieurs artefacts indiquant une exécution, mais le binaire n’est plus sur le disque. Impossible de l’analyser, impossible de le soumettre à un service de réputation, impossible de dire si c’était un outil d’administration ou une porte dérobée.

L’AmCache règle le problème, parce qu’il conserve le condensé SHA-1 du binaire exécuté avec son nom et son chemin. Une recherche en source ouverte sur ce condensé peut identifier l’outil ; quoi qu’il en soit, le condensé devient un marqueur exploitable sur le reste du parc, que l’on versera dans les indicateurs de compromission comme décrit dans l’usage des IoC et des TTP. C’est le cas d’usage qui justifie à lui seul de connaître l’artefact : récupérer l’empreinte d’un fichier qui n’existe plus.

L’artefact va plus loin que l’exécution. Selon les versions, il enregistre aussi le programme auquel appartient un exécutable, les dates d’installation et de désinstallation, la liste des exécutables présents dans un répertoire d’installation au moment de cette installation, les pilotes installés avec leur condensé, et même les périphériques branchés. Deux de ces informations méritent d’être soulignées. Cette liste d’exécutables n’est jamais mise à jour : la comparer au contenu actuel du répertoire révèle les fichiers ajoutés après coup, trace exacte d’un binaire dissimulé dans le dossier d’un logiciel légitime, cousine du détournement de bibliothèque. Et la présence d’un pilote avec son condensé répond à la question qui hante toute remédiation : l’attaquant a-t-il chargé un pilote vulnérable pour se ménager un retour ? Elle décide souvent de l’arbitrage exposé dans assainir ou reconstruire.

Les horodatages ne veulent pas dire ce qu’on croit

Voici le piège principal, et il est sérieux. Le rapport de l’ANSSI explique qu’il cherche précisément à comprendre « pourquoi l’horodatage associé à cet artefact ne peut pas être interprété de manière fiable comme la date d’exécution de l’application ». Ce n’est pas une nuance d’expert : c’est la différence entre une chronologie défendable et une chronologie fausse.

La raison tient au fonctionnement en deux temps. La date de dernière écriture d’une entrée peut être celle de l’exécution du binaire, celle du lancement de la tâche planifiée, ou celle de l’installation du programme, selon une arborescence de cas que la présentation de l’ANSSI détaille sur une page entière. Si l’exécutable fait partie d’un programme, qu’il avait besoin d’être traité par l’infrastructure de compatibilité et qu’il a tourné avant le passage de la tâche planifiée, alors la date semble bien être celle de l’exécution. Si la tâche planifiée est passée depuis l’installation du programme, la date semble être celle du passage de la tâche. Sinon, elle semble être celle de l’installation. Et si l’exécutable est l’installateur d’un programme, ou s’il n’appartient à aucun programme, les règles changent encore.

Deux conséquences de méthode. D’abord, un horodatage d’AmCache ne se verse jamais seul dans une chronologie d’attaque : il s’y verse avec la mention de son incertitude, et il se corrobore par un artefact d’une autre nature, journal d’événements, horodatage de système de fichiers, trace réseau. La construction d’une chronologie défendable à partir de sources hétérogènes est l’objet de la reconstruction d’une timeline d’attaque, et les règles d’intégrité qui rendent ces éléments opposables relèvent de la chaîne de conservation. Ensuite, l’écart entre l’exécution et la consolidation donne un encadrement utile : pour les binaires référencés dans un AEINV_AMI_WER, le rapport note qu’ils ont été exécutés avant le dernier passage de la tâche planifiée. C’est une borne supérieure, pas une date, et une borne supérieure est déjà un renseignement.

L’absence n’est pas une preuve d’absence

Troisième piège, aussi coûteux que le deuxième, et qui conclut la présentation de l’ANSSI : attention aux conclusions tirées sur l’absence d’un exécutable dans l’artefact. Tous les exécutables ne sont pas enregistrés, et les exceptions ne sont ni documentées par l’éditeur ni exhaustivement connues.

Dans le format ancien, l’ANSSI relève que les exécutions depuis un média externe ou depuis un partage réseau ne sont pas enregistrées, et qu’il existe des exceptions empiriques dans C:\Users, notamment les répertoires de téléchargement et de documents, ainsi qu’un cas lié à l’ancienneté de la date de modification du binaire. Ajoutez le fait que la tâche planifiée vide le fichier chaque nuit, et l’on comprend qu’un RecentFileCache.bcf muet sur un binaire ne prouve strictement rien sur son exécution.

La formulation correcte d’un constat négatif est donc : « l’AmCache ne porte pas de trace de ce binaire, ce qui est compatible avec une absence d’exécution, mais aussi avec une exécution depuis un partage réseau, depuis un support amovible, ou dans un cas d’exception connu de l’artefact ». C’est plus long et moins satisfaisant qu’un « il n’a pas tourné », et c’est la seule phrase qui tiendra devant un contradicteur compétent. La règle générale, valable bien au-delà de cet artefact, est que l’absence de trace dans une source dont on ne connaît pas le périmètre de collecte n’est pas une information.

ShimCache, le voisin qu’on confond

Le cache de compatibilité applicative est l’autre artefact de la même infrastructure, et il est régulièrement confondu avec l’AmCache dans les comptes rendus d’investigation, y compris dans des rapports professionnels. Les deux viennent du même mécanisme, les deux parlent d’exécutables, et c’est à peu près tout ce qu’ils ont en commun : ils ne vivent pas au même endroit, ne portent pas les mêmes champs, et ne se mettent pas à jour dans les mêmes circonstances.

Le point à retenir, et il suffit à éviter la faute la plus fréquente, est qu’une entrée dans ce cache n’établit pas qu’un programme a été exécuté. L’infrastructure de compatibilité s’intéresse aux fichiers qu’elle rencontre, ce qui n’est pas la même chose que les fichiers qu’elle a lancés. Conclure à l’exécution sur la seule présence d’une entrée est une erreur classique, et elle a des conséquences réelles : elle fait entrer dans un rapport une exécution qui n’a pas eu lieu, donc une victime qui n’en est pas une, ou une date de première compromission fausse de plusieurs semaines.

La bonne pratique est donc de ne pas traiter les deux artefacts ensemble : chacun a son périmètre, ses champs et ses incertitudes, à vérifier sur la version exacte du système analysé plutôt que sur un mémo recopié. Le rapport de l’ANSSI fait référence pour l’AmCache et ne traite pas le ShimCache en détail ; celui-ci se lit ailleurs, avec la même méfiance.

Méthode : collecter large, conclure étroit

Trois gestes suffisent à transformer cet artefact d’anecdote en élément d’enquête. Collecter l’ensemble : la ruche AmCache.hve ou le RecentFileCache.bcf, tous les fichiers XML du répertoire AppCompat\Programs, le PropCache.bin quand il existe, et la version des bibliothèques ae*.dll. Cette collecte se fait sur une copie intègre et tracée, dans les conditions décrites dans la préparation de preuves et l’analyse mémoire et réseau après incident ; l’AmCache se lit sur une image, pas sur une machine qu’on laisse tourner.

Interpréter selon la version, ensuite, et jamais selon un tableau générique : les champs disponibles changent d’une version de bibliothèque à l’autre, et l’annexe du rapport de l’ANSSI donne, version par version, la liste des informations présentes. Corroborer enfin, systématiquement, et par un artefact de nature différente. L’AmCache apporte un condensé et une fourchette ; il n’apporte pas une date. Les journaux de création de processus produits par Sysmon, dont la mise en place est décrite dans la centralisation des journaux Sysmon, ou la journalisation de PowerShell traitée dans journaliser et durcir PowerShell, fournissent exactement ce que l’AmCache ne donne pas : l’heure, le compte, le processus parent. L’un ne remplace pas l’autre, et c’est bien pour cela qu’il faut les deux.

Dernière remarque, qui n’a rien de technique : la valeur de cet artefact vient de son obscurité, et cette obscurité est un actif périssable. Tant que les outils d’effacement de traces l’ignorent, il parle ; le jour où ils le traiteront, l’investigation sur poste Windows reposera sur la journalisation que l’organisation aura, ou n’aura pas, déployée à l’avance. Argument de plus en faveur d’une télémétrie choisie plutôt que subie, développé dans la détection de la persistance d’un attaquant.

Sources

Analysis of the AmCache, version 2, Blanche Lagny, ANSSI, 25 juillet 2019, 66 pages.
AmCache Investigation, présentation CoRI&IN 2019, Blanche Lagny, ANSSI.

🐝 Ce qui arrive si on s’en passe

Sans collecte de l’AmCache, le condensé d’un binaire supprimé par l’attaquant est définitivement perdu, et avec lui le seul marqueur qui aurait permis de chercher le même outil sur le reste du parc. Sans relevé de la version des bibliothèques de compatibilité, l’analyste lit un artefact avec la grille d’une autre version et conclut sur des champs qui n’ont pas le sens qu’il leur prête. Sans précaution sur les horodatages, une date de dernière écriture entre dans la chronologie comme une date d’exécution, et la première compromission se trouve datée du passage d’une tâche planifiée, c’est-à-dire de rien. Sans conscience des exceptions d’enregistrement, l’absence d’un binaire dans l’artefact est présentée comme une preuve qu’il n’a pas tourné, alors qu’une exécution depuis un partage réseau produit exactement la même absence. Et sans journalisation de création de processus déployée avant l’incident, il ne reste que des artefacts conçus pour autre chose, dont chacun apporte la moitié d’une réponse.

🦫 Explication de la marmotte 🍫

Windows contient un mécanisme destiné à faire fonctionner les vieux logiciels sur les versions récentes du système. Pour cela, il note des informations sur les programmes qu’il rencontre, dans des fichiers dont presque personne ne connaît l’existence. Après une attaque, ces fichiers deviennent précieux : ils gardent parfois l’empreinte numérique d’un programme que l’attaquant a effacé, ce qui permet de l’identifier et de le chercher sur les autres machines.

Mais ces notes n’ont pas été faites pour servir de preuve, et elles se lisent mal. Elles ne sont pas écrites d’un seul coup : le système en inscrit une partie au moment où le programme tourne, puis une tâche automatique repasse quelques heures ou quelques jours plus tard pour compléter, et parfois pour effacer. La date inscrite peut donc être celle de l’exécution du programme, celle du passage de la tâche automatique, ou celle de l’installation du logiciel. Prendre cette date pour l’heure de l’attaque est l’erreur la plus répandue, et elle fausse toute la reconstitution.

Deux autres difficultés. Le format de ces fichiers ne dépend pas de la version de Windows mais de celle de quelques bibliothèques internes, mises à jour séparément : deux machines affichant le même numéro de Windows produisent des fichiers différents, et qui applique la mauvaise grille de lecture se trompe sans s’en apercevoir. Et certains programmes ne sont jamais notés, par exemple ceux lancés depuis une clé USB ou depuis un dossier partagé sur le réseau : ne rien trouver ne veut donc pas dire que rien n’a tourné.

La méthode consiste à tout ramasser plutôt qu’un seul fichier, à noter la version exacte des bibliothèques, et à ne jamais conclure sur ce seul élément. L’empreinte d’un programme effacé, oui. L’heure précise d’une attaque, non : pour cela, il faut une vraie journalisation, mise en place avant l’incident.

Pages voisines

La citent

Prouver qu'un programme a tourné : AmCache, ShimCache et leurs pièges

Elle cite