Forensique Amcache : comment trouver des preuves d'exécution

La question qui met Amcache sur la table est presque toujours une variante de « prouvez que ceci a tourné sur cet hôte » — un outil que l'attaquant a supprimé, un binaire qu'une alerte EDR a nommé mais que l'analyste ne trouve pas sur disque, un malware qui s'est effacé après son staging. Amcache.hve est l'endroit le moins coûteux d'un système Windows pour répondre à cette question, car le Compatibility Appraiser inventorie les exécutables portables qu'ils existent encore ou non, et il enregistre le seul champ qui survit à tout le reste : le hash SHA-1.

Voici le parcours de bout en bout : acquérir la ruche, la parser, couper le bruit, trouver les entrées qui comptent, pivoter dessus, et — la partie que la plupart des guides éludent — comprendre exactement ce qu'une entrée Amcache prouve et ne prouve pas. Si vous cherchez la référence de l'artefact plutôt que le workflow, commencez par la référence complète Amcache ; cette page parle de l'utiliser pour trouver des preuves.

Ce qu'une entrée Amcache prouve réellement#

Posez ce point correctement d'abord, car toute conclusion en aval en dépend.

La clé phare d'Amcache, Root\InventoryApplicationFile, contient une entrée par PE que l'appraiser a vu. Une entrée signifie : cet exécutable était présent sur le système de fichiers quand l'appraiser a tourné, et voici ses métadonnées. C'est de la présence, pas de l'exécution. Pour l'immense majorité des cas réels la distinction est académique — le mimikatz.exe d'un attaquant posé dans C:\ProgramData\ y est arrivé pour être lancé — mais dans un tribunal ou un rapport, on l'énonce précisément :

• Affirmation forte, bien étayée : le binaire avec ce SHA-1 et ce chemin existait sur cet hôte au moment, ou avant, de la passe de l'appraiser qui a écrit cette entrée.
• Affirmation plus faible, à corroborer : le binaire a été exécuté. À confirmer avec Prefetch, ShimCache, Sysmon Event ID 1 ou Security 4688.

Ce cadrage honnête — la présence d'abord, l'exécution par corroboration — est ce qui sépare un constat qui survit à la relecture d'un constat qui se fait démolir. Voir ce que la ruche Amcache vous dit pour le traitement complet de cette frontière.

Étape 1 : acquérir la ruche#

Le fichier réside à un chemin fixe sur chaque version de Windows depuis la 8 :

C:\Windows\AppCompat\Programs\Amcache.hve
C:\Windows\AppCompat\Programs\Amcache.hve.LOG1
C:\Windows\AppCompat\Programs\Amcache.hve.LOG2

Sur un hôte actif, la ruche est maintenue ouverte ; vous ne pouvez donc pas simplement la copier depuis l'Explorateur. Utilisez une copie par handle brut (KAPE, FTK Imager, RawCopy ou l'artefact Velociraptor) et emportez avec elle les deux journaux de transactions .LOG — ils portent des écritures pas encore flushées dans la ruche, et un bon parseur les rejoue. Les options complètes d'acquisition sont dans acquérir Amcache.hve ; la version courte : copiez les trois fichiers, ne faites jamais confiance à une copie à chaud sans les journaux.

# KAPE, le chemin de triage standard
kape.exe --tsource C: --target Amcache --tdest C:\triage\

Étape 2 : parser avec AmcacheParser#

AmcacheParser d'Eric Zimmerman est l'outil de facto. Les flags qui comptent :

AmcacheParser.exe -f Amcache.hve --csv .\out\ --mp -i

• -f — la ruche à parser.
• --csv — répertoire de sortie pour le jeu de CSV.
• --mp — inclut les chemins \Microsoft\ (ne pré-filtrez pas au moment du parsing ; filtrez plus tard, là où vous voyez ce que vous écartez).
• -i — inclut les entrées même là où les données de l'appraiser sont partielles.

Il rejoue automatiquement les journaux de transactions et émet un jeu de CSV — UnassociatedFileEntries.csv et AssociatedFileEntries.csv sont les deux dans lesquels vous vivez. (Pas de machine Windows sous la main ? Déposez la ruche sur le parseur navigateur — il lit la ruche côté client via WebAssembly et ne l'envoie jamais, ce qui lève aussi la règle « aucun upload tiers » qu'imposent les environnements régulés.) Pour la signification de chaque colonne, gardez les colonnes de sortie d'AmcacheParser ouvertes dans un onglet.

Étape 3 : lire les champs qui portent la preuve#

Par entrée de fichier, voici ceux sur lesquels vous bâtissez vos constats :

Le FileId mérite une attention particulière : AmcacheParser retire pour vous le 0000 de padding initial, donc les 40 caractères hexadécimaux restants sont le vrai SHA-1 du fichier — collez-le tel quel dans VirusTotal. Les mécanismes complets sont dans le FileId Amcache expliqué et le workflow de chasse dans les hashes SHA-1 pour la chasse au malware.

Étape 4 : filtrer le bruit#

UnassociatedFileEntries.csv sur une station normale grimpe à des dizaines de milliers de lignes. Vous ne pouvez pas lire ça. L'ordre de filtrage que j'applique à chaque fois, identique à celui sur lequel convergent les analystes aguerris :

1. Écartez la plomberie de l'OS par le chemin. Tout ce qui est sous c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\.
2. Écartez IsOsComponent = True. D'autre bruit OS que le filtre par chemin a manqué.
3. Gardez les voisinages intéressants. Les chemins dans \users\, \programdata\, \windows\temp\, \perflogs\, ou tout ce qui contient \appdata\. Les attaquants se posent là où ils peuvent écrire.
4. Gardez les Publisher vides ou Unknown. Un logiciel signé avec un vrai éditeur est rarement la première piste.
5. Triez par KeyLastWriteTimestamp décroissant. Travaillez d'abord la fenêtre qui vous intéresse.

En PowerShell, contre le CSV parsé :

Import-Csv .\out\*_UnassociatedFileEntries.csv |
  Where-Object {
    $_.IsOsComponent -ne 'True' -and
    $_.LowerCaseLongPath -notmatch '\\winsxs\\|\\servicing\\|\\program files\\microsoft\\' -and
    $_.LowerCaseLongPath -match '\\users\\|\\programdata\\|\\windows\\temp\\|\\appdata\\|\\perflogs\\'
  } |
  Sort-Object KeyLastWriteTimestamp -Descending |
  Select-Object KeyLastWriteTimestamp, LowerCaseLongPath, Name, Publisher, FileId |
  Format-Table -AutoSize

Vingt mille lignes deviennent quelques dizaines. C'est le jeu que vous lisez réellement.

Étape 5 : un exemple traité — le binaire supprimé#

Voici le motif qui rend Amcache prioritaire. Le jeu filtré fait remonter une ligne comme celle-ci :

KeyLastWriteTimestamp: 2026-06-09 23:51:07 UTC
LowerCaseLongPath:   c:\programdata\intel\drivers\igfxsvc.exe
Name:          igfxsvc.exe
OriginalFileName:    rundll32.exe
Publisher:        (vide)
IsPeSigned:        False
FileId:          0000a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2
Size:           1264640

Trois choses font hurler cette entrée :

• Divergence Name/OriginalFileName. Le fichier se nomme igfxsvc.exe sur disque mais son en-tête PE indique rundll32.exe. Un vrai logiciel graphique Intel ne fait pas ça. Outil système renommé — ou quelque chose se faisant passer pour lui.
• Mauvais voisinage. Les vrais pilotes Intel ne vivent pas sous c:\programdata\intel\drivers\. Ce chemin est un camouflage choisi par l'attaquant.
• Non signé, sans éditeur, dans un répertoire inscriptible. Trois signaux faibles qui se composent en un signal fort.

Le binaire lui-même a maintenant disparu du disque — l'attaquant l'a supprimé. Vous avez quand même tout ce qu'il faut :

1. Pivotez le SHA-1. Portez a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2 (retirez le 0000) sur VirusTotal / votre plateforme d'intel. Une correspondance nomme l'outil. Aucune correspondance signifie qu'il faut le passer sur l'Amcache de chaque autre hôte pour voir où ce fichier exact a atterri ailleurs.
2. Établissez une borne temporelle. Le KeyLastWriteTimestamp du 2026-06-09 23:51 vous indique que le fichier était présent au plus tard à cet instant. Associez-le à la référence des horodatages pour ne pas surinterpréter — c'est l'heure d'écriture de l'appraiser, pas l'heure d'exécution.
3. Confirmez l'exécution. Croisez avec Prefetch pour IGFXSVC.EXE-<hash>.pf (compte d'exécutions + dernières heures de run), avec ShimCache, et avec Sysmon EID 1 / Security 4688 pour la création de processus réelle. Amcache dit c'était là ; ceux-là disent ça a tourné, tant de fois, à ces moments.

Cette chaîne — faire remonter, pivoter, borner, confirmer — est l'épine dorsale de l'investigation d'un incident réel avec la ruche Amcache et du guide d'investigation de malware.

Au-delà des exécutables : preuves de périphériques et de pilotes#

L'exécution de programme est le titre, mais la même ruche répond à deux autres questions probatoires que les analystes sous-exploitent :

• Quel matériel a touché cet hôte ? Root\InventoryDeviceContainer et Root\InventoryDevicePnp donnent l'historique USB / périphériques le plus propre et tabulaire que Windows expose — friendly names, fabricant/modèle, état de connexion. C'est la base de tout triage d'exfiltration par USB ; la méthode complète est dans l'historique USB et périphériques depuis Amcache. C'est aussi, d'après les données de recherche, la question avec laquelle les gens arrivent le plus souvent sur Amcache — le couple DeviceContainers / KeyLastWriteTimestamp.
• Quels pilotes ont été chargés ? Root\InventoryDriverBinary enregistre les binaires de pilotes avec leurs propres hashes — l'artefact que vous consultez pour les attaques BYOVD (bring-your-own-vulnerable-driver), où un pilote signé-mais-vulnérable est déposé pour obtenir un accès kernel.

Les limites qui piègent les analystes#

Les tutoriels de type it-connect ont raison de s'y attarder, et je vais faire de même. Un constat Amcache ne vaut que par votre conscience de ce que la ruche ne peut pas vous dire.

Les scripts sont invisibles#

.ps1, .cmd, .bat, .vbs — aucun n'a d'en-tête PE, donc l'appraiser ne les inventorie pas comme entrées de fichier. Une intrusion uniquement PowerShell peut ne laisser aucune trace d'exécution Amcache pour la logique malveillante elle-même (bien que powershell.exe et tout outil compilé qu'elle a déposé apparaîtront). Pour l'exécution de scripts il vous faut Prefetch, le ScriptBlock logging (EID 4104) et la ligne de commande dans 4688/Sysmon. C'est la raison numéro un pour laquelle un analyste conclut à tort « rien n'a tourné ».

Les composants de l'OS sont filtrés par conception#

Les entrées marquées IsOsComponent = True — et beaucoup de binaires living-off-the-land livrés avec Windows — peuvent être absentes ou minorées. Un attaquant utilisant seulement certutil.exe, bitsadmin.exe, wmic.exe laisse une trace Amcache ténue précisément parce que ce sont des composants de l'OS. Les LOLBins échappent à l'inventaire de la même manière qu'ils échappent à tout le reste.

C'est un inventaire, pas un journal#

Il n'y a pas d'enregistrement par exécution ni de compte d'exécutions — c'est le travail de Prefetch. Une entrée Amcache par fichier, mise à jour sur place. Si un binaire a tourné cinquante fois, vous voyez une ligne, et KeyLastWriteTimestamp reflète la dernière écriture de l'appraiser, pas le dernier run.

Le délai de l'appraiser est réel#

Le Microsoft Compatibility Appraiser tourne environ chaque jour, bridé par l'état d'inactivité et d'alimentation. Un binaire qui a tourné deux heures avant que vous tiriez la ruche peut simplement ne pas encore être inventorié. L'absence d'une entrée Amcache n'est jamais la preuve qu'un binaire n'a pas tourné — voir pourquoi mon Amcache est-elle vide et à quelle fréquence Amcache se met à jour.

Les horodatages sont des bornes, pas des événements#

KeyLastWriteTimestamp est l'heure d'écriture de l'appraiser. LinkDate est un horodatage de compilation que l'auteur contrôle et peut falsifier. Ni l'un ni l'autre n'est « l'heure à laquelle le programme a tourné ». La lecture rigoureuse est dans les horodatages Amcache décodés.

Corrélation : où Amcache se situe dans le tableau#

Amcache justifie sa place comme le premier coup d'œil rapide et le survivant de la suppression. Elle est à son plus fort quand on triangule :

Pour les comparaisons artefact par artefact, voir Amcache vs Prefetch, Amcache vs ShimCache et Amcache vs SRUM.

Le workflow en un écran#

1. Acquérir Amcache.hve + les deux fichiers .LOG (copie brute).
2. AmcacheParser.exe -f Amcache.hve --csv .\out\ --mp -i.
3. Filtrer : écarter les chemins OS et IsOsComponent, garder les chemins utilisateur inscriptibles et les Publisher vides, trier par KeyLastWriteTimestamp décroissant.
4. Lire les lignes survivantes pour repérer les divergences chemin/nom et les voisinages anormaux.
5. Pivoter le SHA-1 de chaque candidat vers l'intel et entre hôtes.
6. Borner le temps avec KeyLastWriteTimestamp ; ne l'appelez jamais l'heure d'exécution.
7. Confirmer l'exécution dans Prefetch / ShimCache / EVTX.
8. Énoncer la présence comme un fait, l'exécution comme corroborée — et nommer ce que la ruche n'a pas pu voir.

Voilà comment vous transformez Amcache.hve en preuve plutôt qu'en intuition.

Liés#

• Amcache : la référence forensique complète de la ruche Windows .hve
• Investigation d'un incident réel avec la ruche Amcache : déroulé
• Les hashes SHA-1 pour la chasse au malware
• L'historique USB et périphériques depuis Amcache
• Amcache vs Prefetch
• Ce que la ruche Amcache vous dit