Ce que l'Amcache vous dit vraiment dans une investigation DFIR

La plupart des articles sur l'Amcache la traitent comme un registre propre de "tout programme ayant tourné sur cet hôte". Ce n'est pas le cas. Après quelques centaines d'incidents, on cesse de faire confiance à ce cadre et on commence à traiter la ruche pour ce qu'elle est vraiment : un effet secondaire bruyant et asynchrone du Program Compatibility Assistant qui fait son boulot, et qui se révèle très utile en DFIR parce qu'il survit aux désinstallations, suppressions de fichiers et altérations du registre bien mieux que la plupart le pensent.

Ce billet, c'est la version de la conversation que j'aurais avec un nouvel analyste de mon équipe. Ce que la ruche prouve, ce qu'elle ne prouve pas, et les endroits précis où j'ai vu des enquêtes dérailler.

Où vit la ruche, et pourquoi ça compte déjà#

C:\Windows\AppCompat\Programs\Amcache.hve sur Windows 7 SP1 et postérieurs. C'est une ruche de registre au format regf habituel, ce qui veut dire que tout parseur capable de lire NTUSER.DAT peut, en principe, la lire. Ce qui la rend intéressante en forensique, c'est qu'elle est écrite de façon transparente par compattelrunner.exe chaque fois que le Program Compatibility Assistant inventorie le système, ce qui se produit selon une planification (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) et sur certains événements installeur/désinstalleur.

Quelques conséquences pratiques :

• La ruche vit en dehors du profil utilisateur, donc elle est par-machine, pas par-utilisateur. Vous ne pouvez pas attribuer une entrée à un compte précis depuis la ruche seule.
• La tâche de l'Appraiser peut être désactivée par GPO, par certains scripts "telemetry remover" et par certaines configurations baseline d'EDR. Sur ces hôtes la ruche peut être obsolète depuis des semaines. J'ai hérité d'enquêtes où l'équipe IR avait considéré l'Amcache comme un smoking gun avant d'avoir vérifié si la tâche tournait vraiment.
• Comme c'est une ruche normale, elle a un couple de journaux de transactions (Amcache.hve.LOG1 / Amcache.hve.LOG2). Acquérez-les toujours avec le fichier principal. Les rejouer récupère les entrées qui étaient en vol au moment de l'acquisition et fait parfois remonter des enregistrements qui ne sont jamais arrivés à la ruche vivante.

Ce qu'une entrée prouve vraiment#

La réponse honnête est : un fichier était présent sur disque à un moment où l'Appraiser parcourait le système de fichiers. Rien de plus.

C'est là que commencent les erreurs les plus fréquentes. La ruche ne prouve pas l'exécution. Elle prouve l'existence au moment du scan. Sur le plan opérationnel, cette distinction compte pour trois raisons :

1. Les fichiers déposés et supprimés entre deux passes de l'Appraiser ne laissent rien. Un opérateur red team compétent peut introduire et retirer un outil dans une seule fenêtre de scan. L'Amcache n'en parlera jamais. Combinez la ruche avec Prefetch et les journaux Sysmon / Sécurité avant de prétendre "pas de preuve d'exécution".
2. L'inventaire d'un installeur n'est pas l'exécution du payload. Quand Setup a tourné, l'Appraiser a indexé tout ce qu'il a copié dans Program Files. Y compris des lanceurs de shellcode et des outils d'exfil empaquetés qui n'ont jamais été appelés. La présence d'evil.exe sous InventoryApplicationFile est intéressante, pas accablante.
3. Les binaires sur partages réseau apparaissent aussi. Les chemins UNC sont inventoriés quand l'Appraiser les voit montés. Si un utilisateur a double-cliqué un fichier depuis \\fileserver\public\, l'entrée peut ressembler à s'y méprendre à un binaire installé localement. Lisez le chemin avec soin.

Ce que la ruche prouve, et de façon fiable, c'est qu'un fichier a existé avec un certain hash SHA-1 à un certain moment. C'est assez pour pivoter, vers le threat intel, vers VirusTotal, vers d'autres hôtes du parc, même si le fichier sur disque a disparu depuis longtemps. C'est l'unique élément le plus utile que l'Amcache apporte, et la raison pour laquelle je récupère toujours la ruche en premier sur un hôte où je soupçonne une suppression de fichier.

Les horodatages vous induiront en erreur si vous les laissez faire#

Il y a au moins cinq champs qui ressemblent à des horodatages dispersés dans les clés qui vous intéressent, et ils ne signifient pas tous la même chose. Les noms ne se suffisent pas à eux-mêmes, la documentation est mince, et les valeurs reflètent des événements différents selon la build Windows.

Un petit guide de terrain qui tient sur Win7, Win10 et Win11 :

• FileId n'est pas un horodatage. C'est un hash SHA-1 préfixé par 0000. Les gens trébuchent dessus dans les scripts.
• LinkDate (quand il est présent) est l'horodatage de compilation de l'en-tête PE. Contrôlable par l'attaquant. Traitez-le comme une métadonnée sur le binaire, pas sur le moment où il a touché la machine.
• Le LastWrite de la clé sur InventoryApplicationFile\<id> est, en pratique, le proxy le plus utile pour "l'Appraiser a remarqué ce fichier". Ce n'est pas la création ni l'exécution du fichier.
• InstallDate sous InventoryApplication est ce que l'installeur a déclaré. Les installeurs MSI le remplissent généralement honnêtement. Les installeurs mal empaquetés et beaucoup de droppers malveillants non, donc ne vous y fiez pas pour les timelines d'adversaire.
• Construisez une super-timeline en pivotant sur la MFT et le journal USN avant de vous engager dans un récit basé uniquement sur les horodatages Amcache. La validation croisée est bon marché ; se tromper dans le rapport final, non.

Les champs qui méritent leur place#

Après ProgramId et SHA-1, le champ que je touche le plus, c'est OriginalFileName sous InventoryApplicationFile. Il vient de la ressource version du PE et est plus dur à nettoyer pour des attaquants négligents que LowerCaseLongPath. Je l'ai utilisé pour relier une svchost.exe renommée déposée dans \AppData\Local\Temp\ à sa vraie identité (mimikatz.exe) parce que le bloc ressource n'avait jamais été édité.

BinaryType vaut aussi la lecture : pe32_file versus pe64_file versus xbox_one_pkg_file (oui, vraiment). Les mismatches entre BinaryType et chemin peuvent être un indice sur des échantillons packés ou repackés.

Les clés InventoryApplicationShortcut et InventoryDeviceContainer sont faciles à oublier. La sous-clé de shortcut enregistre les fichiers .lnk que Windows a examinés, y compris ceux pour des supports amovibles : parfois la seule preuve subsistante qu'un utilisateur a ouvert un fichier depuis une clé USB qui a depuis quitté le bâtiment. Combinez avec le parseur LNK et le shim cache pour l'affirmation la plus solide.

Anti-forensique : ce que les attaquants peuvent ou non faire en silence#

La ruche est un fichier de registre normal. Quiconque dispose de SYSTEM peut y écrire. En pratique, trois patterns reviennent :

• Suppression totale. Amcache.hve est verrouillée tant que Windows tourne, donc les attaquants tuent compattelrunner et le processus de registre avant de supprimer, ou ils mettent en queue un Pending File Rename. La suppression est facile à détecter : le fichier devrait toujours être là sur un hôte sain, mais vous perdez le contenu historique. Espérez avoir une sauvegarde récente ou un cliché.
• Suppression ciblée de clés. Retirer des sous-clés précises sous InventoryApplicationFile pour nettoyer un binaire particulier. Possible, mais : l'opération met à jour le LastWrite de la clé parente, et les journaux de transactions peuvent encore contenir l'ancien enregistrement. J'ai récupéré ~30 % des entrées "supprimées" depuis .LOG1/.LOG2 dans des cas où l'attaquant ne les avait pas effacées aussi.
• Mascarade d'éditeur de confiance. Définir les ressources de version PE d'un outil déposé pour imiter un composant Microsoft. Cela survit dans l'Amcache, mais ne change pas le SHA-1. Le lookup par hash bat toujours le lookup par chaîne.

La catégorie à laquelle des attaquants compétents recourent, c'est de désactiver la tâche du Compatibility Appraiser dès le départ. Sur un hôte où l'Amcache est suspectement vide pour la période d'intérêt, vérifiez l'historique du Task Scheduler dans Microsoft-Windows-TaskScheduler%4Operational.evtx avant de supposer que l'absence de preuve est preuve d'absence.

Un workflow qui survit à une review#

Ce que je fais, dans l'ordre, sur un hôte où l'Amcache compte :

1. Acquérir Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 ensemble. Sur un système vivant, utiliser un snapshot VSS ou un outil qui gère le verrou correctement. Ne pas copier le fichier vivant avec xcopy.
2. Rejouer les journaux. La plupart des parseurs le font automatiquement ; vérifiez en contrôlant que la ruche récupérée s'ouvre sans avertissements.
3. Tirer SHA-1, OriginalFileName, LowerCaseLongPath et le LastWrite de la clé pour chaque entrée InventoryApplicationFile. C'est le set de travail.
4. Filtrer par chemins dans des répertoires inscriptibles par l'utilisateur (\Users\*\AppData\, \Users\Public\, \ProgramData\ hors sous-dossiers de vendeurs connus, C:\Windows\Temp\, C:\PerfLogs\). La majorité de l'activité d'adversaire atterrit là.
5. Pivoter par hash les survivants. Tout ce qui n'est pas signé par un éditeur connu ou pas connu de VirusTotal va sur la liste à corroborer ailleurs.
6. Corroborer. Les affirmations les plus solides associent une ligne Amcache à un hit Prefetch, un Sysmon process create ou un Security 4688. Tout ce qui repose uniquement sur la ruche reçoit la mention "preuve de présence de fichier ; exécution non corroborée".

Cette dernière puce est celle que je finis par imposer dans chaque rapport.

Lire la ruche sans quitter le navigateur#

Le parseur de ce site lit Amcache.hve entièrement dans votre navigateur, replay des journaux de transactions inclus. Déposez la ruche et vous obtenez un tableau plat des entrées InventoryApplicationFile avec les champs ci-dessus, classé par LastWrite. Filtrez, pivotez par hash, exportez. Pas d'upload, ce qui compte quand la ruche vient d'un environnement régulé.

Pour aller plus loin#

• Amcache.hve in Windows 8 de Yogesh Khatri, le reverse engineering public original. Toujours la meilleure référence unique pour la disposition des champs.
• AmcacheParser d'Eric Zimmerman, outil offline de référence. Son schéma de sortie est de facto le standard de l'industrie.
• MITRE ATT&CK T1070.009 Clear Persistence pour le contexte sur ce que des attaquants bien dotés font face à des ruches comme celle-ci.

Si vous ne retenez qu'une chose : hash d'abord, chemin ensuite, temps en troisième. L'Amcache donne le meilleur d'elle quand vous la traitez comme un index de hash qui se trouve aussi connaître les fichiers vus par Windows, et le pire quand vous traitez les horodatages comme une vérité de terrain.