Das Binärformat von Amcache.hve in der Praxis

Wenn Sie Amcache.hve zum ersten Mal in einem Hex-Editor aufmachen, sehen Sie an Offset null die vier ASCII-Bytes regf und sind leicht enttäuscht. Da ist kein exotisches Schema. Die Amcache ist eine ganz normale Windows-Registry-Hive, was zugleich der Grund ist, warum sie sich einfach parsen lässt, und der Grund, warum fast jeder Analyst einen schlechten Parser schreibt, bevor er einen guten schreibt.

Dieser Beitrag ist die Version von "wie die Datei aufgebaut ist", die mir jemand in die Hand hätte drücken sollen, bevor ich mich für Offsets zu interessieren begann. Er ist meinungsstark dazu, welche Subkeys Ihre Zeit verdienen und welche ich in einem echten Fall nie gebraucht habe.

regf, ganz kurz#

regf ist das On-Disk-Format für alle Hives NTUSER.DAT, SYSTEM, SOFTWARE, SAM und SECURITY, plus die Amcache. Es ist von Microsoft hinreichend dokumentiert und von der Open-Source-Community besser nachdokumentiert, insbesondere von Maxim Suhanovs Projekt yarp und Eric Zimmermans Notizen, die mit seinen Tools mitkommen.

Ein paar Fakten, die zählen, wenn Sie einen kaputten Parse debuggen:

  • Die Datei ist in 4-KiB-Blöcke namens "hbins" unterteilt. Die ersten 4 KiB sind der Datei-Header. Alles danach sind hbins.
  • Jede hbin enthält eine Kette von Cells. Cells mit positivem Size-Feld sind frei, Cells mit negativem Size-Feld sind allokiert. Ja, das ist andersherum als man es heute entwerfen würde, und ja, jeder Parser ist deswegen schon hereingefallen.
  • Keys sind nk-Cells. Values sind vk-Cells. Subkey-Listen sind lf, lh, ri, li. Große Werte nutzen db-Cells. Wenn Sie je "unknown cell signature" in einem Parser-Log gesehen haben, liegt das meist daran, dass die Cell-Type-Tabelle unvollständig ist oder die Hive an der Bin-Grenze beschädigt ist.
  • Die Hive trägt oben ein Sequenznummern-Paar. Wenn primary und secondary nicht übereinstimmen, wurde die Hive während der Erfassung geschrieben, und die Transaktionslogs müssen nachgespielt werden, bevor dem Inhalt zu trauen ist.

Die Amcache nutzt keine dieser Strukturen ungewöhnlich. Was auch immer Ihren Lieblings-NTUSER.DAT-Parser geschrieben hat, wird, Bugs ausgenommen, auch die Amcache lesen.

Die Subkeys, die ihre Miete zahlen#

Der interessante Inhalt liegt unter Root\InventoryApplication, Root\InventoryApplicationFile, Root\InventoryDeviceContainer, Root\InventoryDriverBinary, Root\InventoryDriverPackage und Root\InventoryApplicationShortcut. Es gibt weitere Roots, darunter Root\InventoryApplicationFramework und das alte Root\File auf älteren Windows-7-Builds, aber die sechs oben sind, wo ich 95 % meiner Zeit verbringe.

InventoryApplication#

Ein Subkey pro installierter (oder einst installierter) Anwendung, benannt nach der ProgramId, einem 16-Byte-Identifier, abgeleitet aus Herausgeber, Name und Version. Die Werte darin sind die Software aus Sicht des Installers: Name, Publisher, Version, InstallDate, RootDirPath, Source (MSI / AddRemoveProgram / etc.), Type (Application / Game / Hotfix), Language. MSI-Installer befüllen diese Felder meist gut. Gebündelte oder per Sideload installierte Software weniger.

InstallDate ist hier ein DateTime-als-String-Wert, kein FILETIME. Es ist das, was der Installer gemeldet hat, nicht das, was das Dateisystem gesehen hat. Behandeln Sie es als Indiz, nicht als Beweis.

InventoryApplicationFile#

Der Subkey, den Sie am häufigsten lesen werden. Ein Eintrag pro ausführbarer Datei, die der Appraiser indexiert hat, benannt mit einem Schlüssel wie notepad.exe|abcd1234ef567890. Jeder Eintrag trägt FileId (die 0000-präfixierte SHA-1), LowerCaseLongPath, OriginalFileName, Name, Publisher, ProductName, ProductVersion, Version, BinaryType, Size, LinkDate, Language, IsPeFile, IsOsComponent und einen Rückverweis auf die übergeordnete ProgramId.

Der Wert, dem ich am wenigsten traue, ist LowerCaseLongPath. Es ist der Pfad, den der Appraiser zum Scanzeitpunkt gesehen hat, was in Ordnung ist, aber umbenannte oder verschobene Dateien hinterlassen veraltete Einträge mit Pfaden, die zu nichts mehr passen. Der Wert, dem ich am meisten traue, ist FileId. Hashes lügen nicht, auch wenn Pfade es tun.

InventoryDeviceContainer#

Geräte, die das System gesehen hat, intern wie extern. Indexiert über eine Container-ID. Werte sind unter anderem Manufacturer, ModelName, ModelNumber, FriendlyName, Categories und einige BLE/USB-spezifische Felder. Das ist der Subkey, zu dem ich greife, wenn ich eine USB-Geschichte korroborieren muss, idealerweise gegen SYSTEM\ControlSet001\Enum\USBSTOR aus den Haupt-Registry-Hives gegengeprüft.

Es ist kein Ersatz für die eigentlichen USB-Artefakte. Die Amcache sagt Ihnen, dass ein Logitech-Empfänger an diesem Rechner war; sie sagt Ihnen nicht, welcher Benutzer wann welchen Stick eingesteckt hat. Nutzen Sie es für Breite, nicht für Tiefe.

InventoryDriverBinary und InventoryDriverPackage#

Zwei verwandte Keys, die das Kernel-Mode-Treiberinventar abdecken. InventoryDriverBinary enthält einen Eintrag pro .sys-Datei, die der Appraiser gesehen hat, mit den üblichen FileId, DriverName, DriverCompany, Service, DriverSigned, DriverInBox, DriverIsKernelMode, dazu LinkDate und Produkt-Strings. InventoryDriverPackage deckt .inf-Pakete ab, mit Class, ClassGuid, Date, Provider, Version und den Inbox-/Signed-Flags.

Diese beiden Keys sind der Grund, warum "Bring Your Own Vulnerable Driver"-Ermittlungen fast immer mit der Amcache anfangen. Ein Angreifer wirft gdrv.sys oder RTCore64.sys ab, lädt ihn, exploitet ihn, löscht ihn. Die Binärdatei ist von der Platte verschwunden, wenn Sie eintreffen. Der InventoryDriverBinary-Eintrag, mit seinem SHA-1, oft nicht.

InventoryApplicationShortcut#

Jeder Subkey entspricht einer LNK-Datei, die der Appraiser untersucht hat, identifiziert über einen Hash und mit dem Pfad in Kleinschreibung. Weniger Felder als die anderen Inventories, aber es ist eine der wenigen Quellen, die Ihnen sagt, dass eine .lnk, die auf Wechselmedien zeigte, auf dem Host existiert hat. Kombinieren Sie es mit dem LNK-Parser für die eigentlichen Zieldetails, da Amcaches Eintrag flach bleibt.

Parsen, ohne eigene Bugs zu erfinden#

Es gibt drei Tools, die ich in der Fallarbeit tatsächlich nutze, grob absteigend danach, wie oft sie auf meiner Analyst-Workstation die Hive anfassen.

Eric Zimmermans AmcacheParser#

Der Standard. AmcacheParser.exe -f Amcache.hve --csv .\out\ -i liefert Ihnen eine CSV pro Inventory-Subkey, wobei -i das Einschließen von Nicht-PE-Dateien aktiviert (nützlich, um Skripte einzufangen, die mitaufgenommen wurden). Das Schema, das es ausgibt, ist, im Guten wie im Schlechten, das, an das sich die meisten anderen Tools angepasst haben. Wenn Sie internes Tooling schreiben müssen, spiegeln Sie die Spaltennamen.

Zwei Flags, die ich immer setze: --mp, um die Millisekundengenauigkeit auf Zeitstempeln zu behalten (das gerundete Default-Format verbirgt Timing-Details, die gelegentlich zählen), und --nl, um Einträge ohne LinkDate zu behalten (das Default-Skippen hat mich beim Jagen von Kernel-Treibern schon erwischt).

RegRipper#

Harlan Carveys rip.exe mit dem Plugin amcache (und dem neueren amcache_tln für Timeline-Ausgabe). Älter, aber immer noch nützlich, besonders auf Windows-7-Hives, wo der alte Subkey Root\File noch vorhanden ist und AmcacheParser ihn manchmal überspringt. Die Plugin-Ausgabe ist Text, kein CSV. Damit leben, oder grep.

yarp#

Maxim Suhanovs reine Python-regf-Bibliothek. Das nutze ich, wenn ich etwas tun muss, was die bestehenden Tools nicht können, etwa freie Cells nach gelöschten Records durchsuchen oder zwei Snapshots derselben Hive vergleichen. Die API legt Raw-Cells, Transaction-Log-Replay und ein vernünftiges Objektmodell für Keys und Values offen. yarp-print ist eine handliche CLI, wenn Sie nur eine Hive ausgeben wollen.

Wenn Sie Automatisierung bauen, ist yarp das richtige Fundament. Wenn Sie um 02:00 Uhr auf einen Incident reagieren, ist AmcacheParser schneller.

Die Transaktionslogs sind nicht optional#

Amcache.hve.LOG1 und Amcache.hve.LOG2 sind die Dirty-Page-Logs, die der Kernel verwendet, um die Hive über Abstürze hinweg konsistent zu halten. Das Format ist dokumentiert (HvLE-Blöcke für modernes Windows, das ältere DIRT-Format auf Win7). Sie zählen für Sie, weil:

  1. Wenn die Erfassung stattfand, während die Hive geschrieben wurde, ist die Hauptdatei inkonsistent und die Logs enthalten die fehlenden Pages. AmcacheParser und yarp spielen sie beide automatisch nach, wenn sie vorhanden sind. RegRipper tut das je nach Version nicht.
  2. Kürzlich gelöschte Subkeys existieren oft noch in den Log-Pages. Ich habe Einträge aus .LOG1 wiederhergestellt, die Minuten vor der Erfassung aus der Haupt-Hive entfernt worden waren. Greifen Sie immer die LOGs zusammen mit der Hive ab, nie nur die .hve.
  3. Eine nicht übereinstimmende Sequenznummer auf der Hive ist Ihr Hinweis, dass Sie die Logs brauchen. Wenn primary != secondary im Header, parsen Sie nicht ohne sie. Bessere Tools verweigern; schlechtere Tools produzieren Müll und warnen nicht.

Was ich nie anfasse#

Ehrliche Liste. Ich habe noch nie einen Fall mit InventoryApplicationFramework, dem Orphan-Subkey oder InventoryMiscellaneousMemorySlotArrayInfo (ja, das existiert) abgeschlossen. Das ist Rauschen. Wenn Sie dort wühlen, weil die offensichtlichen Keys leer waren, hat man Ihnen vermutlich einen Host übergeben, auf dem der Appraiser deaktiviert war, und Ihre Zeit ist bei der MFT, dem USN-Journal und dem Sicherheits-Ereignisprotokoll besser aufgehoben.

Weiterführende Quellen#

Tagsamcachewindows-forensicsdfirregistrybinary-format

Verwandte Beiträge

← Zurück zu allen Beiträgen