Amcache-Zeitstempel erklärt: KeyLastWriteTimestamp vs LinkDate vs der Rest

Amcache stellt mehrere unterschiedliche Zeitstempel bereit, und sie zu verwechseln ist der einzelne häufigste Fehler, den neue Amcache-Analysten machen. Datieren Sie einen Befund falsch, und die gesamte Timeline kollabiert. Diese Seite ist die vollständige Referenz: jeder Zeitstempel, den Amcache bereitstellt, was er tatsächlich repräsentiert und auf welchen Sie für eine bestimmte Frage pivotieren sollten.

Für den breiteren Amcache-Kontext siehe die vollständige Amcache-Referenz; für die umliegende Registry-Struktur siehe Amcache-Registry-Struktur.

Die Zeitstempel auf einen Blick#

Zeitstempel Quelle Repräsentiert
KeyLastWriteTimestamp Registry-Schlüssel-Metadaten Wann der Appraiser diesen Eintrag zuletzt geschrieben hat. Das, was „wann Amcache dies aufgezeichnet hat" am nächsten kommt.
LinkDate PE-IMAGE_FILE_HEADER.TimeDateStamp Wann das Binärprogramm kompiliert / gelinkt wurde. Vom Angreifer steuerbar.
InstallDate Wert von InventoryApplication Wann die Anwendung installiert wurde.
MsiInstallDate Wert von InventoryApplicationFile Wann das übergeordnete MSI installiert wurde (falls vorhanden).
LastModified Hive-Wert (schemaabhängig) Ein Last-Modified-Marker, in einigen Schema-Versionen vorhanden.
LastWriteTimestamp (Legacy Programs) Registry-Schlüssel-Metadaten Gleiche Idee wie KeyLastWriteTimestamp, aber für das Legacy-Schema Root\Programs.

Die einzelne wichtigste Regel:

KeyLastWriteTimestamp ist der Pivot für „Wann wurde dies auf diesem Host gesehen?". Alles andere ist eine andere Frage.

KeyLastWriteTimestamp#

Das ist die Last-Write-Zeit auf Registry-Ebene des Schlüssels, der den Eintrag enthält. Es sind Metadaten der Registry-Hive selbst — Windows aktualisiert sie jedes Mal, wenn sich der Inhalt des Schlüssels ändert.

Für Root\InventoryApplicationFile\<entry> wird der KeyLastWriteTimestamp aktualisiert, wann immer der Appraiser diesen Eintrag schreibt oder aktualisiert. In der Praxis bedeutet das:

  • Beim ersten Mal, dass der Appraiser eine Datei inventarisiert, wird der Schlüssel erstellt, und sein KeyLastWriteTimestamp ist die Inventarzeit.
  • Wenn sich die Metadaten der Datei zwischen Inventaren ändern (Größe, Hash, Version), wird der Schlüssel umgeschrieben und der Zeitstempel rückt vor.
  • Wenn sich nichts zwischen Inventaren ändert, bleibt der Zeitstempel stehen — selbst wenn der Appraiser erneut lief und bestätigte, dass die Datei immer noch vorhanden ist.

Dieser letzte Punkt ist wichtig: KeyLastWriteTimestamp ist nicht „die jüngste Zeit, zu der der Appraiser diese Datei gesehen hat". Es ist „die jüngste Zeit, zu der der Appraiser über diese Datei geschrieben hat". Für eine stabile, unveränderte Datei kann der Zeitstempel Wochen oder Monate alt sein, obwohl die Datei in dieser ganzen Zeit präsent war.

Wofür KeyLastWriteTimestamp gut ist#

  • First-Seen-Näherungen. Für ein Binärprogramm, das der Angreifer neu auf einem sauberen Host abgelegt hat, ist KeyLastWriteTimestamp die Appraiser-Laufzeit nach dem Ablegen. Vorbehalte:
    • der Appraiser läuft nicht sofort — es gibt bis zu ~24 h Verzögerung auf Workstations, länger auf Servern,
    • das Binärprogramm muss zur Appraiser-Zeit noch vorhanden sein (transiente Binärprogramme, die vor dem nächsten Durchlauf gelöscht werden, erscheinen möglicherweise nie),
    • die Zeitstempel-Auflösung ist das, was der Appraiser schreibt — typischerweise sekundengenau.
  • Zeitfenster-Joins. Sobald Sie einen verdächtigen Eintrag haben, nehmen Sie seinen KeyLastWriteTimestamp ± Ihr gewähltes Fenster (eine Stunde ist ein gängiger Standard) und joinen Sie alle anderen CSVs (Prefetch, Sysmon, Security 4688) auf dieses Fenster. Sie bekommen die ganze Geschichte dessen, was rund um das Inventar-Ereignis passierte.
  • Binär-Ersetzung erkennen. Wenn zwei InventoryApplicationFile-Zeilen denselben FullPath, aber unterschiedliche Hash-Werte und unterschiedliche KeyLastWriteTimestamp-Werte haben, hat sich das Binärprogramm an diesem Pfad zwischen diesen beiden Zeiten geändert. Sortieren Sie nach Zeitstempel, um die Reihenfolge zu sehen.

Wofür KeyLastWriteTimestamp nicht gut ist#

  • „Wann existierte dieses Binärprogramm zum ersten Mal auf der Festplatte?" — das ist eine Dateisystem-Frage ($STANDARD_INFORMATION.CreationTime in der MFT). KeyLastWriteTimestamp ist bestenfalls eine Obergrenze: Die Datei existierte auf der Festplatte spätestens zum Zeitstempel, aber wahrscheinlich früher.
  • „Wann wurde dieses Binärprogramm ausgeführt?" — Amcache zeichnet Präsenz auf, nicht Ausführung. Verwenden Sie Prefetch.
  • Sub-Sekunden-Präzision. Ziehen Sie keine Schlüsse aus einigen hundert Millisekunden.

LinkDate#

Der PE-Header-TimeDateStamp — der Wert, den der Linker zur Kompilier-/Linkzeit in den IMAGE_FILE_HEADER des Binärprogramms gestempelt hat. Jedes PE hat einen.

Wofür LinkDate gut ist#

  • Binärprogramme nach Build-Kampagne clustern. Wenn Sie alle unassoziierten PEs auf einem Host nach LinkDate sortieren, sehen Sie häufig enge Cluster: 3–10 Binärprogramme, alle innerhalb desselben Tages oder derselben Stunde gestempelt. Das ist oft ein einzelner Angreifer, der sein gesamtes Toolkit in einer Sitzung kompiliert.
  • Verdächtig alte oder neue Builds erkennen. Ein 2014 kompilierter Treiber, der heute zum ersten Mal in Ihrer Amcache erscheint, ist ein Hinweis auf BYOVD. Ein in der Zukunft kompiliertes Binärprogramm ist ein Hinweis auf Uhrenversatz- Schenanigans oder schlampige Tools.
  • Bestätigen, dass ein Build zur erwarteten Kampagne gehört. „Unsere internen Tool-Builds linkdaten immer montags um 03:00 UTC; dieser ist dienstags um 14:00 — untersuchen."

Wofür LinkDate nicht gut ist#

  • „Wann ist dieses Binärprogramm auf diesem Host erschienen?" Vom Angreifer steuerbar. Ein Angreifer kann beim Linken jeden beliebigen TimeDateStamp setzen, und er wird manchmal absichtlich auf 0 gesetzt (für reproduzierbare Builds) oder auf ein Datum in der Vergangenheit (um das Binärprogramm alt / etabliert aussehen zu lassen). LinkDate als Host-Präsenz-Pivot zu vertrauen, erzeugt falsche Befunde.
  • Kryptografische Identität. LinkDate allein ist nicht eindeutig; viele Binärprogramme teilen denselben Link-Zeitstempel.

InstallDate (auf InventoryApplication)#

Wann die Anwendung installiert wurde, im Registry-FILETIME-Format. Nützlich für:

  • Querprüfung mit KeyLastWriteTimestamp auf den Dateieinträgen. Wenn der KeyLastWriteTimestamp einer Datei deutlich älter ist als das InstallDate ihrer übergeordneten Anwendung, ist etwas ungewöhnlich — die Datei scheint laut Windows vor der Existenz der Anwendung auf der Festplatte gewesen zu sein.
  • Silent Installs erkennen. Anwendungen, die ohne Benutzerinteraktion installiert werden, hinterlassen manchmal InstallDate nahe 1601-01-01 (die FILETIME-Epoche) oder zu unrealistischen zukünftigen Daten. Beides sind Hinweise.

MsiInstallDate (auf InventoryApplicationFile)#

Das Installationsdatum des übergeordneten MSI für Dateien, die aus einem MSI-Installer stammen. Gleiches FILETIME-Format wie InstallDate. Nützlich, um Dateien zu unterscheiden, die über eine ordentliche MSI-Installation kamen, von Dateien, die per Kopie / Drop kamen.

LastModified (falls vorhanden)#

Einige Amcache-Schema-Versionen stellen einen LastModified-Wert pro Datei bereit. Nicht jede Hive hat ihn. Wenn vorhanden, behandeln Sie ihn als die Dateisystem-Last-Modified-Zeit wie der Appraiser sie beim Inventar sah — nicht als maßgeblich. Die $STANDARD_INFORMATION der MFT ist die maßgebliche Quelle.

LastWriteTimestamp auf Legacy-Programs#

Das Legacy-Schema Root\Programs stellt einen LastWriteTimestamp pro Eintrag bereit, der konzeptionell identisch ist mit KeyLastWriteTimestamp im modernen Schema. Gleiche Vorbehalte gelten.

Der zeitlich gebundene Standard-Pivot#

Das Ermittlungsmuster, auf das sich die meisten Analysten standardisieren:

  1. Identifizieren Sie eine verdächtige Zeile in *_UnassociatedFileEntries.csv (typischerweise über „unsigniertes PE in benutzerbeschreibbarem Pfad").
  2. Nehmen Sie ihren KeyLastWriteTimestamp.
  3. Definieren Sie ein einstündiges Fenster, zentriert um diesen Zeitstempel.
  4. Ziehen Sie aus diesem Fenster:
    • Alle anderen Amcache-Zeilen (schlüsselübergreifend — Treiber, Geräte, Verknüpfungen).
    • Alle Prefetch-Einträge (definitive Ausführung).
    • Alle Security-4688-Prozesserstellungs-Events.
    • Alle Sysmon-1- (Prozess erstellen), 7- (Image laden) und 11-Events (Datei erstellen).
    • Alle Dateisystem-Erstellungen aus der MFT und dem USN-Journal.
  5. Die resultierende Timeline ist das vollständige Bild dessen, was rund um dieses Inventarereignis geschah.

Das ist der kanonische Join „Was hat der Angreifer in dieser Minute getan?", und KeyLastWriteTimestamp ist der Anker, der ihn möglich macht.

Ein durchgespieltes Beispiel#

Sie sehen zwei Amcache-Zeilen für denselben Pfad:

FullPath: C:\Users\bob\AppData\Local\Temp\notepad.exe
Row A:   KeyLastWriteTimestamp = 2026-03-12 14:23:11 UTC
         Hash                  = aaaaaaaa...
         LinkDate              = 2018-04-03 09:00:00 UTC
         Publisher             = ""

Row B:   KeyLastWriteTimestamp = 2026-04-19 02:14:55 UTC
         Hash                  = bbbbbbbb...
         LinkDate              = 2018-04-03 09:00:00 UTC
         Publisher             = ""

So liest man das:

  • LinkDate ist identisch. Das ist der TimeDateStamp im PE-Header — der Angreifer hat dieselbe Build-Identität wiederverwendet oder ein Template benutzt, das jeden Build gleich linkstempelt. Kein Beweis für die Build-Zeit.
  • Hash unterscheidet sich. An den beiden KeyLastWriteTimestamp-Momenten befand sich unterschiedlicher Dateiinhalt am Pfad.
  • KeyLastWriteTimestamp unterscheidet sich. Amcache hat den Pfad zweimal gesehen, ~5 Wochen auseinander, mit jeweils unterschiedlichem Inhalt.

Fazit: Ein Binärprogramm an diesem Pfad wurde zwischen dem 12. März und dem 19. April ersetzt. Pivotieren Sie auf den Zeitstempel vom 19. April ± 1 h für das Drop-Ereignis des neuen Binärprogramms; pivotieren Sie auf den 12. März ± 1 h für den ursprünglichen Drop. Zwei Eindringereignisse; ein Pfad; ein Amcache-Eintrag, um beide zu finden.

Siehe auch#

Um Zeitstempel in Ihrer eigenen Hive zu erkunden, ohne etwas zu installieren, legen Sie eine Datei auf der Startseite des Parsers ab — sie parst vollständig in Ihrem Browser.

Tagsforensikwindowsamcachedfirtimestamps

Verwandte Beiträge

← Zurück zu allen Beiträgen