Die Amcache-Zeitstempel, dekodiert

In Amcache.hve gibt es mindestens neun Felder, die wie ein Zeitstempel aussehen. Zwei davon sind keine Zeitstempel. Vier bedeuten auf Windows 7 etwas anderes als auf Windows 10. Einer wird vom Angreifer kontrolliert. Die anderen zwei sind manchmal nützlich, mit Vorbehalten.

Wenn Sie je gefragt wurden "wann tauchte diese Datei auf dem Host auf?" und mit einem einzigen Amcache-Feld geantwortet haben, ist dieser Beitrag das Gespräch, das Sie zuerst mit sich selbst hätten führen sollen.

Die zwei Formate, die Windows nebeneinander nutzt#

Die Amcache mischt zwei Zeitstempel-Konventionen in derselben Hive, was eine bestimmte Art von Design-Entscheidung ist.

Das erste ist die 64-Bit-FILETIME: 100-Nanosekunden-Intervalle seit dem 01.01.1601 UTC, little-endian gespeichert. Das nutzt der LastWrite jedes Registry-Keys, und das speichern manche wert-Ebenen-Felder. Parser handhaben es transparent. Die Semantik ist meist "die Registry hat diesen Eintrag in diesem Moment geschrieben".

Das zweite ist DateTime-als-String, wobei Microsoft entschieden hat, einen menschenlesbaren Zeitstempel in einem REG_SZ-Wert zu speichern. Die Formate variieren über Builds: MM/TT/JJJJ HH:MM:SS auf Win10, ISO-8601-artig JJJJ-MM-TT HH:MM:SS auf manchen Win11-Einträgen. Die Zeitzone ist meist UTC, aber gelegentlich Lokalzeit auf Win7-Hives. Immer prüfen, bevor Sie eine Timeline bauen; ein Off-by-One-Zeitzone in einem Bericht ist peinlich.

Lesen Sie den rohen vk-Cell-Typ, wenn Sie unsicher sind. REG_QWORD und REG_BINARY der Länge 8 bedeuten FILETIME; REG_SZ bedeutet, den String zu parsen und zu beten.

Die Felder, eines nach dem anderen#

Key LastWrite auf InventoryApplicationFile\#

Der nützlichste Zeitstempel der Hive überhaupt. Es ist die FILETIME, die die Registry in den Key-Header geschrieben hat, als der Compatibility Appraiser zuletzt den Eintrag dieser Datei aktualisierte. In der Praxis: "Appraiser hat diese Datei bemerkt" oder "Appraiser hat sie neu gehasht, weil sich etwas geändert hat".

Es ist nicht Dateierstellung, nicht Dateiausführung, nicht Benutzeraktivität. Wenn Appraiser eine frisch abgelegte Binärdatei zum ersten Mal sieht, ist der LastWrite ungefähr der nächste geplante Lauf, nachdem die Datei erschienen ist. Die Kadenz der geplanten Läufe hängt vom Host ab, aber ein paar Stunden sind auf einem normal konfigurierten System typisch.

Plausibilitätscheck: dieser Zeitstempel sollte immer später sein als die eigene NTFS-Erstellungszeit der Datei aus der MFT. Ist er früher, stimmt etwas nicht (Timestomping, Clock-Skew oder ein Angreifer, der die Hive editiert hat).

LinkDate (InventoryApplicationFile, InventoryDriverBinary)#

PE-Header-IMAGE_FILE_HEADER.TimeDateStamp, als DateTime-String gespeichert. Es ist der Compile-Zeitstempel, den der Linker gestempelt hat, was wiederum ist, was die Build-Umgebung sagte.

Vom Angreifer kontrolliert. Trivial. link.exe /timestamp oder Post-Link-Patching kann ihn auf alles setzen. Die Hälfte der Commodity-Malware liefert LinkDate = 1970-01-01, weil sich niemand kümmert. Bessere Samples setzen ihn auf einen plausiblen 2018-2020-Wert. Die polierten matchen den LinkDate einer echten Microsoft-Binärdatei, um zu mischen.

Nützlich für:

• Offenkundig falsche Werte erkennen (1970, 2099 oder Werte, die dem Rest der Host-Timeline widersprechen).
• Zwei Builds desselben Projekts unterscheiden, wenn beide Samples ehrliche Compile-Zeiten haben.

Nicht nützlich für: Timeline. Setzen Sie es nicht auf eine Timeline.

InstallDate (InventoryApplication)#

Ein DateTime-String unter jedem InventoryApplication\<ProgramId>-Key. Der Wert ist, was der Installer geschrieben hat, meist aus MSI-Metadaten oder dem Wert DisplayInstallDate im Uninstall-Key. Für legitim verpackte Software (Office, Chrome, Vendor-MSIs) ist das auf den Tag genau, gelegentlich auf die Sekunde.

Für Malware-Dropper, sideloaded Tooling oder alles, was nicht durch einen echten Installer ging, ist das Feld entweder abwesend, null oder auf das gesetzt, was bequem war. Als Indiz behandeln.

Ich nutze InstallDate, um anwendungsbezogene Aussagen zu untermauern, wenn die Frage "wann hat dieser Benutzer Chrome installiert" lautet, nicht für Angreifer-Aktivität.

InstallDateMsi, InstallDateArpLastModified, InstallDateFromLinkFile (InventoryApplication)#

Gleiche allgemeine Bedeutung, andere Quellen. Windows 10 Build 1709 und neuer legen pro Anwendung mehrere Install-Date-Varianten offen:

• InstallDateMsi: aus der MSI-Datenbank, falls die Installation MSI nutzte.
• InstallDateArpLastModified: aus dem Last-Modified-Zeitstempel des Registry-Eintrags von Add/Remove Programs (ARP).
• InstallDateFromLinkFile: aus den Metadaten der Start-Menü-.lnk-Datei, wenn die Anwendung eine erstellt hat.

Wenn diese drei sich um mehr als ein paar Minuten unterscheiden, ist etwas Interessantes passiert: eine Reparaturinstallation, ein Upgrade oder eine Neuregistrierung. Wenn sie übereinstimmen, ist das Installationsdatum solide.

Key LastWrite auf InventoryApplication\#

Anders als InstallDate. Dies ist der Last-Write des Registry-Keys, der aktualisiert wird, wann immer Appraiser den Anwendungseintrag aktualisiert. Für die meisten Anwendungen liegt der erste Schreibvorgang nahe an der Installationszeit, nachfolgende sind selten. Nützlich als Korroborationscheck gegen InstallDate*.

Key LastWrite auf InventoryDeviceContainer\#

Das Nächste an "wann hat Windows dieses Gerät zuletzt gesehen", was Sie in der Hive finden. Aktualisiert, wenn Appraiser den Geräte-Eintrag auffrischt. Koppeln Sie mit der eigentlichen USB-Geschichte (SYSTEM\ControlSet001\Enum\USBSTOR, Microsoft-Windows-Partition%4Diagnostic.evtx, setupapi.dev.log) für jede USB-Frage; der Amcache-Wert allein ist zu grob.

Key LastWrite auf InventoryDriverBinary\ und InventoryDriverPackage\#

Gleiche Form wie die Application-Keys. Der LastWrite ist "Appraiser hat diesen Treiber-Eintrag aufgefrischt", was auf einem normal laufenden Host kurz nach dem Landen des Treibers passiert. Für BYOVD-Untersuchungen, in denen der Angreifer einen verwundbaren signierten Treiber abgelegt hat, ist der LastWrite von InventoryDriverBinary häufig die engste Grenze, die Sie für "wann wurde dieser Treiber bereitgestellt" haben.

Key LastWrite auf InventoryApplicationShortcut\#

Wann Appraiser dieses .lnk indiziert hat. Der Shortcut selbst hat seine eigenen MAC-Zeiten im LNK-Datei-Body, die der LNK-Parser Ihnen gibt. Der Amcache-LastWrite ist ein separater, späterer, weniger interessanter Zeitstempel. Ich nutze ihn als Plausibilitätscheck, nicht als Befund.

Was Win7, Win10 und Win11 anders machen#

Die Hive ist nicht über Major-Builds hinweg gleich, selbst wenn die Key-Namen identisch aussehen.

Windows 7 SP1 mit dem ursprünglichen Compatibility Appraiser hatte eine viel einfachere Hive. Die Top-Level-Keys waren Root\File, Root\Programs, Root\Generic und Root\Orphan. Der Wert LastModified unter Root\File\<volume>\<fileid> war das explizite "Datei zuletzt geändert per NTFS zum Appraiser-Scanzeit", eine andere Semantik als alles in der modernen Hive. Wenn Sie eine Win7-Hive lesen, können Sie keine Win10-Feldnamen verwenden. RegRippers älteres Plugin amcache handhabt das; AmcacheParser handhabt moderne Hives besser als Legacy-Hives.

Windows 8 / 8.1 führte die InventoryApplication*-Keys ein, aber das Schema war unstabil. Einige Felder erscheinen in 8.1, die in 10 verschwinden, und umgekehrt. Ich würde keine Automatisierung gegen eine 8.1-Hive bauen, ohne die Werte-Liste vorher zu inspizieren.

Windows-10-Builds bis ~1709 hatten ein dünneres InventoryApplication-Schema. Die drei InstallDate*-Varianten existierten nicht alle. LinkDate war manchmal leer für PE-Dateien, die Appraiser nicht vollständig parsen konnte.

Windows 10 1809 und neuer ist das stabile Schema, das die meiste aktuelle Tools-Landschaft anvisiert. AmcacheParsers Spalten-Set matcht dieses.

Windows 11 fügt unter InventoryApplicationFile ein paar Werte hinzu (insbesondere einige signatur-bezogene Felder) und ändert das String-Format gewisser DateTime-Werte vom US-Locale zu ISO-artig. Die Semantik der Kern-Zeitstempel ist unverändert.

In-Place-Upgrades machen ein Durcheinander#

Wenn ein Host von Windows 10 auf Windows 11 oder von einem 10-Major-Build auf einen anderen upgradet, wird die Amcache migriert, nicht neu erzeugt. In der Praxis:

• Alte InventoryApplicationFile-Einträge werden meist mit ihrem ursprünglichen LastWrite aus dem Pre-Upgrade-Lauf erhalten.
• Der Appraiser scannt nach dem Upgrade alles neu, also werden innerhalb von Stunden bis Tagen die meisten LastWrites aufgefrischt.
• Schemaänderungen bedeuten, dass manche Felder auf nach dem Upgrade erstellten Einträgen befüllt sind und auf Einträgen, die von davor überlebt haben, leer.
• Eine Teilmenge der Einträge wird gelegentlich verwaist: die Binärdatei existiert nicht mehr, aber der Key wurde während der Migration nie aufgeräumt.

Wenn die LastWrite-Verteilung Ihrer Hive zwei Cluster zeigt, die durch eine saubere Lücke getrennt sind, schauen Sie wahrscheinlich auf eine Pre-Upgrade- und eine Post-Upgrade-Population. Bestätigen Sie gegen setupact.log oder den Setup-Kanal im Ereignisprotokoll, bevor Sie zu viel hineinlesen.

Praktische Plausibilitätschecks#

Bevor irgendein Zeitstempel in einen Bericht geht, lassen Sie diese im Kopf durchlaufen:

1. Ist der LastWrite des InventoryApplicationFile-Keys nach der NTFS-Erstellungszeit der Datei? Wenn nicht, stimmt etwas nicht.
2. Ist der LastWrite konsistent mit der Last-Run-Time der Compatibility-Appraiser-Task in Microsoft-Windows-TaskScheduler%4Operational.evtx? Appraiser-Schreibvorgänge sind gebatcht; Sie sollten Cluster von LastWrites sehen, die mit Task-Läufen zusammenfallen.
3. Sind die InstallDate*-Triplets unter InventoryApplication untereinander konsistent? Disagreement ist interessant.
4. Ist LinkDate plausibel? 1970, 2099 oder ein Wert außerhalb grob 1995-jetzt bedeutet, dass der PE-Header gestempelt wurde, nicht dass die Datei so alt ist.
5. Querchecken Sie mindestens einen Amcache-Zeitstempel gegen Prefetch-Ausführungszeiten, Sysmon-Process-Create-Events oder USN-Journal-Dateierstellung. Wenn der Quercheck widerspricht, ist die Amcache nicht unbedingt falsch, aber Sie müssen die Lücke erklären, bevor Sie sich festlegen.

Die Amcache wird Sie nicht absichtlich anlügen. Sie wird Ihnen aber einen vollkommen vernünftig aussehenden Zeitstempel reichen, der etwas völlig anderes bedeutet, als Sie angenommen haben. Das haben alle Felder in diesem Beitrag gemeinsam.

Weiterführende Quellen#

• Yogesh Khatris Amcache.hve in Windows 8, das die Feld-Semantik immer noch besser dokumentiert als jede Anbieter-Quelle.
• Eric Zimmermans AmcacheParser-Quellcode für das kanonische Mapping von Wertnamen zu Spalten.
• Microsofts Compatibility-Appraiser-Dokumentation, dünn in Forensik, aber nützlich, um die Task-Kadenz zu verstehen.
• 13Cubeds Deep-Dive-Videos zu Amcache und Shimcache, insbesondere die Zeitstempel-Segmente.