Le format binaire d'Amcache.hve, en pratique

La première fois que vous ouvrez Amcache.hve dans un éditeur hexadécimal, vous voyez les quatre octets ASCII regf à l'offset zéro et vous êtes légèrement déçu. Pas de schéma exotique. Amcache est une ruche de registre Windows parfaitement ordinaire, ce qui est à la fois la raison pour laquelle elle est facile à parser et la raison pour laquelle presque tous les analystes écrivent un mauvais parseur avant d'en écrire un bon.

Ce billet est la version de "comment le fichier est organisé" qu'on aurait dû me mettre entre les mains avant que je ne commence à m'intéresser aux offsets. Il a des avis tranchés sur les sous-clés qui méritent votre temps et celles que je n'ai jamais utilisées sur un vrai cas.

regf, très brièvement#

regf est le format sur disque de toutes les ruches NTUSER.DAT, SYSTEM, SOFTWARE, SAM et SECURITY, plus Amcache. Il est documenté correctement par Microsoft et redocumenté en mieux par la communauté open source, en particulier le projet yarp de Maxim Suhanov et les notes d'Eric Zimmerman livrées avec ses outils.

Quelques faits qui comptent quand vous déboguez un parse cassé :

  • Le fichier est divisé en blocs de 4 KiB appelés "hbins". Les 4 premiers KiB sont l'en-tête de fichier. Tout le reste, ce sont des hbins.
  • Chaque hbin contient une chaîne de cellules. Les cellules dont le champ Size est positif sont libres, celles dont il est négatif sont allouées. Oui, c'est à l'envers de ce que vous concevriez aujourd'hui, et oui, tous les parseurs s'y sont fait piéger.
  • Les clés sont des cellules nk. Les valeurs sont des cellules vk. Les listes de sous-clés sont lf, lh, ri, li. Les grandes valeurs utilisent des cellules db. Si vous avez déjà vu "unknown cell signature" dans un log de parseur, c'est généralement parce que la table des types de cellule est incomplète ou que la ruche est corrompue à la limite du bin.
  • La ruche porte en tête une paire de numéros de séquence. Si primary et secondary ne correspondent pas, la ruche était en cours d'écriture au moment de la capture, et il faut rejouer les journaux de transactions avant de faire confiance au contenu.

Amcache n'utilise aucune de ces structures de façon inhabituelle. Ce qui a écrit votre parseur NTUSER.DAT préféré lira la ruche Amcache, aux bugs près.

Les sous-clés qui paient leur loyer#

Le contenu intéressant vit sous Root\InventoryApplication, Root\InventoryApplicationFile, Root\InventoryDeviceContainer, Root\InventoryDriverBinary, Root\InventoryDriverPackage et Root\InventoryApplicationShortcut. Il y a d'autres racines, dont Root\InventoryApplicationFramework et l'ancienne Root\File sur de vieux builds Windows 7, mais les six ci-dessus, c'est là que je passe 95 % de mon temps.

InventoryApplication#

Une sous-clé par application installée (ou autrefois installée), nommée par le ProgramId, identifiant de 16 octets dérivé de l'éditeur, du nom et de la version. Les valeurs à l'intérieur sont la vision du logiciel depuis l'oeil de l'installeur : Name, Publisher, Version, InstallDate, RootDirPath, Source (MSI / AddRemoveProgram / etc.), Type (Application / Game / Hotfix), Language. Les installeurs MSI remplissent ces champs proprement. Les logiciels bundlés ou installés par sideload, moins.

InstallDate est ici une valeur DateTime-en-chaîne, pas un FILETIME. C'est ce que l'installeur a déclaré, pas ce que le système de fichiers a vu. À considérer comme indicatif.

InventoryApplicationFile#

La sous-clé que vous lirez le plus souvent. Une entrée par exécutable qu'Appraiser a indexé, nommée par une clé du style notepad.exe|abcd1234ef567890. Chaque entrée porte FileId (le SHA-1 préfixé par 0000), LowerCaseLongPath, OriginalFileName, Name, Publisher, ProductName, ProductVersion, Version, BinaryType, Size, LinkDate, Language, IsPeFile, IsOsComponent, et une référence arrière au ProgramId parent.

La valeur en laquelle j'ai le moins confiance est LowerCaseLongPath. C'est le chemin qu'Appraiser a vu au moment du scan, ce qui est très bien, mais les fichiers renommés ou déplacés laissent des entrées obsolètes avec des chemins qui ne correspondent plus à rien. La valeur en laquelle j'ai le plus confiance est FileId. Les hashes ne mentent pas, même quand les chemins le font.

InventoryDeviceContainer#

Les périphériques que le système a vus, internes comme externes. Indexés par container ID. Les valeurs incluent Manufacturer, ModelName, ModelNumber, FriendlyName, Categories, et quelques champs spécifiques BLE/USB. C'est la sous-clé vers laquelle je me tourne quand je dois corroborer une histoire USB, idéalement croisée avec SYSTEM\ControlSet001\Enum\USBSTOR depuis les ruches principales du registre.

Ce n'est pas un substitut aux vrais artefacts USB. Amcache vous dira qu'un récepteur Logitech a été sur cette machine ; elle ne vous dira pas quel utilisateur a branché quelle clé USB et quand. Utilisez-la pour l'amplitude, pas pour la profondeur.

InventoryDriverBinary et InventoryDriverPackage#

Deux clés liées couvrant l'inventaire des pilotes en mode noyau. InventoryDriverBinary contient une entrée par fichier .sys qu'Appraiser a vu, avec les habituels FileId, DriverName, DriverCompany, Service, DriverSigned, DriverInBox, DriverIsKernelMode, plus le LinkDate et les chaînes produit. InventoryDriverPackage couvre les paquets .inf, avec Class, ClassGuid, Date, Provider, Version et les flags inbox/signed.

Ces deux clés sont pourquoi les enquêtes "Bring Your Own Vulnerable Driver" commencent presque toujours par Amcache. Un attaquant dépose gdrv.sys ou RTCore64.sys, le charge, l'exploite, le supprime. Le binaire a disparu du disque quand vous arrivez. L'entrée InventoryDriverBinary, avec son SHA-1, souvent non.

InventoryApplicationShortcut#

Chaque sous-clé correspond à un fichier LNK qu'Appraiser a examiné, identifié par un hash et portant le chemin en minuscules. Moins de champs que les autres inventaires, mais c'est l'une des rares sources qui vous dit qu'un .lnk pointant vers un média amovible a existé sur l'hôte. Combinez-le avec le parseur LNK pour les vrais détails de la cible, car l'enregistrement Amcache reste superficiel.

Parser sans inventer vos propres bugs#

Il y a trois outils que j'utilise vraiment en travail de cas, à peu près par ordre décroissant de fréquence d'utilisation sur ma machine d'analyse.

AmcacheParser d'Eric Zimmerman#

Le défaut. AmcacheParser.exe -f Amcache.hve --csv .\out\ -i vous donnera un CSV par sous-clé d'inventaire, avec -i activant l'inclusion des fichiers non-PE (utile pour attraper les scripts qui ont été ramassés). Le schéma qu'il émet est, pour le meilleur et pour le pire, celui sur lequel les autres outils se sont normalisés. Si vous devez écrire du tooling interne, calquez les noms de colonnes.

Deux flags que je mets toujours : --mp pour garder la précision à la milliseconde sur les timestamps (le format arrondi par défaut cache des détails de timing qui comptent parfois), et --nl pour garder les entrées sans LinkDate (les ignorer par défaut m'a mordu en chassant les pilotes noyau).

RegRipper#

Le rip.exe de Harlan Carvey avec le plugin amcache (et le plus récent amcache_tln pour la sortie timeline). Plus ancien mais encore utile, surtout sur les ruches Windows 7 où la sous-clé legacy Root\File est encore présente et où AmcacheParser la saute parfois. La sortie du plugin est en texte, pas en CSV. Faites avec, ou grepez.

yarp#

La bibliothèque regf en Python pur de Maxim Suhanov. C'est ce que j'utilise quand je dois faire quelque chose que les outils existants ne font pas, comme parcourir les cellules libres à la recherche d'enregistrements supprimés ou comparer deux snapshots de la même ruche. L'API expose les cellules brutes, le replay des journaux de transactions, et un modèle d'objet sain pour clés et valeurs. yarp-print est une CLI pratique quand vous voulez juste dumper une ruche.

Si vous construisez de l'automatisation, yarp est la bonne base. Si vous répondez à un incident à 02h00, AmcacheParser est plus rapide.

Les journaux de transactions ne sont pas optionnels#

Amcache.hve.LOG1 et Amcache.hve.LOG2 sont les journaux de pages sales que le noyau utilise pour maintenir la ruche cohérente à travers les crashs. Le format est documenté (blocs HvLE pour le Windows moderne, l'ancien DIRT sur Win7). Ils comptent pour vous parce que :

  1. Si l'acquisition a eu lieu pendant que la ruche était en cours d'écriture, le fichier principal est incohérent et les journaux contiennent les pages manquantes. AmcacheParser et yarp les rejouent automatiquement lorsqu'ils sont présents. RegRipper, selon la version, non.
  2. Les sous-clés récemment supprimées existent fréquemment encore dans les pages de journal. J'ai récupéré des entrées de .LOG1 qui avaient été purgées de la ruche principale quelques minutes avant l'acquisition. Récupérez toujours les LOGs en plus de la ruche, jamais juste le .hve.
  3. Un numéro de séquence qui ne correspond pas sur la ruche est votre indice qu'il vous faut les journaux. Si primary != secondary dans l'en-tête, ne parsez pas sans eux. Les meilleurs outils refuseront ; les pires produiront de la bouillie sans vous avertir.

Ce que je ne touche jamais#

Liste honnête. Je n'ai jamais clôturé un dossier en utilisant InventoryApplicationFramework, la sous-clé Orphan, ou InventoryMiscellaneousMemorySlotArrayInfo (oui, ça existe). Du bruit. Si vous vous retrouvez à creuser là parce que les clés évidentes sont ressorties vides, on vous a probablement remis un hôte où Appraiser était désactivé, et votre temps est mieux investi dans la MFT, le journal USN et le journal d'événements Sécurité.

Pour aller plus loin#

Tagsamcachewindows-forensicsdfirregistrybinary-format

Articles liés

← Retour à tous les articles