Acquérir Amcache.hve sur systèmes vivants et morts

Le moyen le plus rapide de ruiner une investigation Amcache, c'est d'acquérir la ruche n'importe comment. J'ai hérité de dossiers où le collecteur avait pris Amcache.hve à coups de xcopy, oublié la paire .LOG1 / .LOG2, et remis à l'analyste une ruche qui s'ouvrait avec des avertissements et à laquelle il manquait la semaine d'inventaire la plus récente. La ruche était là. La méthode d'acquisition l'avait jetée.

Ce billet est la version de "comment capturer le fichier correctement" que j'aurais voulu lire dans tout runbook IR.

Le fichier est verrouillé, et c'est tout le problème#

C:\Windows\AppCompat\Programs\Amcache.hve est ouvert par le noyau en tant que ruche. Le handle reste ouvert tant que Windows tourne. Sur un hôte vivant :

  • Un CopyFile normal en user-mode contre le chemin vivant échoue avec un sharing violation.
  • xcopy / robocopy contre le chemin vivant échouent de la même façon, ou pire, produisent silencieusement un fichier de zéro octet sur certains builds Windows lorsqu'ils sont lancés depuis un shell privilégié avec certaines options.
  • reg save HKLM\... Amcache.hve ne marche pas parce qu'Amcache est une ruche autonome, non montée par défaut sous HKLM. Vous pouvez la charger avec reg load HKLM\Amcache C:\Windows\AppCompat\Programs\Amcache.hve uniquement si elle n'est pas actuellement ouverte par un autre processus, ce qu'elle est sur un système vivant.

Il existe quatre façons légitimes de lire le fichier : snapshotter le volume et lire depuis le snapshot, utiliser un lecteur NTFS brut qui contourne le verrou, utiliser un outil qui sait manipuler la ruche spécifiquement, ou éteindre l'hôte et imager le disque.

Les trois premières s'appliquent sur un hôte vivant. La quatrième s'applique quand l'hôte est déjà éteint.

Acquisition à chaud qui fonctionne vraiment#

Volume Shadow Copy#

La méthode la plus ennuyeuse et la plus fiable. Créer un cliché instantané, le monter, copier le fichier en dehors.

vssadmin create shadow /for=C:

vssadmin renvoie le chemin du cliché, en général quelque chose comme \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. Vous ne pouvez pas faire cd dans ce chemin parce que la normalisation des chemins Win32 le déteste. L'astuce, c'est de créer un lien symbolique ou d'utiliser un outil qui accepte les chemins bruts directement. mklink /D C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\ puis copy C:\shadow\Windows\AppCompat\Programs\Amcache.hve* C:\out\ fonctionnent.

Deux remarques pratiques. Pensez bien à mettre le wildcard pour récupérer Amcache.hve, Amcache.hve.LOG1 et Amcache.hve.LOG2. Et nettoyez le cliché quand vous avez fini, sauf si vous avez une raison de le garder ; les clichés non nettoyés, c'est exactement comme cela qu'un poste de travail tombe en panne d'espace disque au pire moment.

Velociraptor#

Si vous avez Velociraptor déployé (et sur la plupart des missions IR en entreprise, vous devriez), c'est un one-liner :

SELECT * FROM Artifact.Windows.Forensics.Amcache()

L'artefact gère le verrou en lisant via l'accès NTFS brut de ntfs.sys, rejoue les journaux de transactions et renvoie des lignes parsées. Si vous voulez la ruche brute plutôt que la sortie parsée, Windows.KapeFiles.Targets avec _AmcacheHive comme cible vous donne le fichier et les journaux dans un zip.

Pour des sweeps sur plusieurs hôtes, c'est le workflow. Chasser à travers le parc, tirer chaque ruche, post-traiter de manière centralisée.

KAPE#

Le KAPE d'Eric Zimmerman gère la cible Amcache nativement. kape.exe --tsource C: --target Amcache --tdest .\out\ collecte la ruche et les journaux, en utilisant son lecteur NTFS brut intégré. Il fait ce qu'il faut avec les verrous.

KAPE est aussi le bon outil quand vous devez collecter Amcache en même temps que tout le reste pour un paquet de triage. La cible BasicCollection plus des modules ciblés vous récupèrent Amcache, Prefetch, MFT, journaux d'événements, journal USN, ruches du registre, et le reste du kit standard en une seule passe.

FTK Imager#

Si vous n'avez que FTK Imager (parce que le répondant est sur place avec une clé USB et aucun autre outil), ça marche. Add Evidence Item > Physical Drive > naviguer jusqu'à \Windows\AppCompat\Programs\ > clic droit > Export Files. FTK Imager utilise des lectures disque brutes, donc le verrou est sans objet.

C'est la méthode que je choisis par défaut quand je suis assis devant le portable d'un cadre avec peu de temps et peu de liberté de déploiement.

reg save après un reg load préalable#

Mentionné parce que les gens essaient. Cela ne fonctionne pas sur la ruche vivante parce qu'elle est déjà ouverte. Cela peut fonctionner sur une copie extraite : sortez la ruche par l'une des méthodes ci-dessus, chargez-la localement avec reg load HKLM\AmcacheTemp C:\path\to\Amcache.hve, interrogez, puis reg unload. C'est pour l'analyse, pas pour l'acquisition.

Le problème LOG1 / LOG2#

Amcache.hve.LOG1 et Amcache.hve.LOG2 sont les journaux de transactions de pages sales que le noyau écrit pour maintenir la ruche cohérente. Ils sont critiques pour deux raisons.

D'abord, si la ruche était en cours d'écriture au moment de la capture, le fichier primaire est incohérent et les journaux contiennent les pages manquantes. Sans eux, les parseurs vont soit refuser d'ouvrir la ruche, soit l'ouvrir avec des données obsolètes. Vérifiez toujours la sortie du parseur, à la recherche de messages "log replay" ou d'avertissements "primary sequence != secondary".

Ensuite, des sous-clés récemment supprimées existent souvent encore comme cellules non effacées dans les pages des journaux. J'ai déjà récupéré des entrées de .LOG1 qu'un attaquant avait purgées de la ruche principale quelques minutes avant l'acquisition. Si vous prenez uniquement le .hve, vous jetez cette récupération.

La règle est simple : ne jamais collecter la ruche sans les journaux. Faire un match wildcard Amcache.hve* à chaque collecte. Velociraptor et KAPE le font automatiquement ; les copy ad hoc, non, sauf si vous les y forcez.

Un autre mode de défaillance : collecter les journaux mais ne pas les rejouer. Certains parseurs rejouent automatiquement (AmcacheParser, yarp), d'autres pas (anciens builds de RegRipper). En cas de doute, ouvrez la ruche récupérée dans deux parseurs et comparez les nombres de lignes. Un écart significatif veut dire que l'un d'eux n'a pas rejoué.

Acquisition sur disque mort#

Quand vous avez une image disque (E01, brute, VHDX) ou un disque éteint :

  • Montez l'image en lecture seule avec FTK Imager, Arsenal Image Mounter, ou losetup plus ntfs-3g sous Linux.
  • Naviguez jusqu'à \Windows\AppCompat\Programs\ sur le système de fichiers monté.
  • Copiez Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 vers la machine d'analyse.
  • Parsez normalement.

Pas de souci de verrou sur une image morte. La seule chose à surveiller, ce sont les clichés du volume sur l'image, qui peuvent contenir des ruches Amcache plus anciennes. Si la ruche vivante a été altérée, une copie plus ancienne dans \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\AppCompat\Programs\Amcache.hve peut porter les entrées que l'attaquant a supprimées. Des outils comme vshadowmount (libvshadow) sous Linux ou ShadowExplorer sous Windows exposent ces snapshots proprement.

Je récupère des lignes Amcache historiques depuis des clichés dans environ un cas sur cinq où la ruche sur disque montre des signes d'élagage.

À quoi ressemblent les bons scripts IR#

Un script de collecte IR pour Amcache qui fonctionne, en pseudo-code grossier :

  1. Créer un snapshot VSS de C: (ou utiliser des lectures NTFS brutes directement).
  2. Lire Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 depuis le chemin du snapshot.
  3. Calculer le SHA-256 de chaque fichier acquis. Inscrire dans le registre de chaîne de garde.
  4. Compresser les trois fichiers ensemble avec un nom horodaté (<hostname>_<UTC-timestamp>_amcache.zip).
  5. Démonter le snapshot.
  6. Expédier vers le stockage central.

Si votre script ne fait pas ces six étapes, corrigez-le. Concrètement : s'il ne hache pas les fichiers acquis, vous n'avez pas d'histoire d'intégrité. S'il ne collecte pas les journaux, il vous manque des données. S'il laisse traîner les snapshots, vous finirez par planter un hôte de production.

L'artefact Windows.KapeFiles.Targets de Velociraptor fait tout cela et plus encore. Si vous en écrivez un à partir de zéro, demandez-vous pourquoi.

Pièges de xcopy et autres méthodes ad hoc#

xcopy "C:\Windows\AppCompat\Programs\Amcache.hve" "C:\out\" sur un hôte vivant échoue avec sharing violation dans la plupart des cas. Certains builds Windows, avec certaines combinaisons de privilèges, produisent à la place un fichier de zéro octet. Les deux modes d'échec sont bruyants si vous vérifiez ; silencieux si vous ne vérifiez pas.

copy a le même problème. robocopy /B (mode sauvegarde) fonctionne parfois sur la ruche vivante parce que les ouvertures en mode sauvegarde utilisent SeBackupPrivilege, mais les résultats sont incohérents entre builds Windows et je ne leur fais pas confiance. Le Copy-Item de PowerShell n'est que CopyFile en dessous.

certutil -urlcache -split n'est pas pertinent ici, non, mais j'ai vu des gens essayer.

Les seules règles fiables : snapshotter le volume, ou utiliser un outil avec accès NTFS brut, ou éteindre l'hôte. Tout le reste, c'est de la chance.

Vérifier l'acquisition#

Avant de quitter un hôte, vérifiez que le fichier collecté est parsable.

  • Ouvrez avec yarp-print (la CLI de Maxim Suhanov). Il signalera les mismatchs de séquence et les journaux non rejoués.
  • Lancez AmcacheParser contre les fichiers collectés. Confirmez que les lignes sous InventoryApplicationFile ne sont pas nulles.
  • Vérifiez par échantillonnage que le KeyLastWrite le plus récent est proche de "maintenant" (dans la cadence de scan de l'Appraiser, généralement quelques heures). Si l'entrée la plus récente date de plusieurs jours sur un hôte censé fonctionner normalement, la tâche Appraiser a peut-être été désactivée, la ruche a peut-être été élaguée, ou votre chemin d'acquisition était mauvais.

Si quelque chose cloche, recollectez avant que l'état de l'hôte ne change. Vérifier sur place vous épargne un long vol retour.

Pour aller plus loin#

Articles liés

Retour à tous les articles