Woher kommt LinkDate?

Aus dem PE-Header der Binary, IMAGE_FILE_HEADER.TimeDateStamp. Der Linker schreibt es. Amcache liest es zur Inventarisierungszeit und speichert es als String.

Können Angreifer es kontrollieren?

Vollständig. Auf beliebige Werte gesetzt, für reproduzierbare Builds genullt, bewusst rückdatiert. Einer der angreiferkontrollierbarsten Zeitstempel in Windows-DFIR.

Kann ich LinkDate als 'Zeitpunkt, an dem die Datei auf dem Host erschien' verwenden?

Nein. Das ist KeyLastWriteTimestamp, und selbst das ist nur eine obere Schranke. LinkDate hat nichts mit dem Host zu tun.

Wofür ist LinkDate gut?

Binaries nach Build-Kampagne zu clustern. Sortieren Sie verdächtige Binaries nach LinkDate und suchen Sie nach engen Clustern innerhalb von Stunden. Angreifer kompilieren ihr Toolkit in einer Sitzung und die Linkzeiten clustern. Auch nützlich für BYOVD: altes LinkDate plus aktueller KeyLastWriteTimestamp ist die klassische Form.

Ist LinkDate manchmal null?

Ja. Reproduzierbare Builds und einige Go-Binaries nullen es absichtlich. Null ist allein nicht verdächtig, aber es bedeutet, dass das Feld Ihnen nichts gibt.

Was ist LinkDate in Amcache? (Glossar)

LinkDate ist der PE-TimeDateStamp. Der Linker schreibt ihn beim Build in die Binary. Amcache liest ihn zur Inventarisierungszeit aus dem PE-Header zurück. Das ist die ganze Geschichte.

Er ist kein hostseitiger Zeitstempel. Der Host hat mit diesem Wert nichts zu tun. Er reist mit der Binary. Ein Angreifer kann ihn auf was auch immer setzen, ihn auf null lassen oder ein Datum in 2007 wählen, damit die Datei wie eine alte, etablierte Software aussieht. Viele tun das.

Der Kontrast zu KeyLastWriteTimestamp#

	KeyLastWriteTimestamp	LinkDate
Quelle	Registry-Metadaten, vom Appraiser geschrieben	PE-Header, vom Linker geschrieben
Angreifer kontrolliert es?	Nein	Ja
Beantwortet	Wann hat Amcache das aufgezeichnet?	Wann wurde die Binary gebaut?
Gut für	Hostseitige First-Seen-Näherung	Build-Kampagnen-Clustering
Auflösung	Sekunden	Sekunden

Diese beiden zu verwechseln ist der häufigste Amcache-Fehler überhaupt. Die Lösung lautet, LinkDate niemals, niemals zu verwenden, um zu argumentieren, wann eine Binary auf einem Host erschien. Siehe Amcache-Zeitstempel erklärt für die Langform.

Wofür es tatsächlich gut ist#

Build-Clustering#

Sortieren Sie unsignierte PEs nach LinkDate. Suchen Sie nach 3 bis 10 Binaries, die innerhalb desselben Tages oder derselben Stunde gestempelt wurden. Das ist ein Angreifer, der sein Kit in einer Sitzung kompiliert und es auf einem oder mehreren Hosts ablegt. Starkes Kampagnensignal.

Import-Csv .\HOST_amcache_UnassociatedFileEntries.csv |
  Where-Object { $_.IsPeFile -eq 'True' -and -not $_.Publisher } |
  Sort-Object LinkDate |
  Select LinkDate, Hash, FullPath

BYOVD-Erkennung#

Treiber in DriverBinaries.csv mit DriverTimeStamp von vor Jahren, aber KeyLastWriteTimestamp von dieser Woche, haben die klassische BYOVD-Form. Siehe das BYOVD-Glossar.

Build-Prozess-Drift#

„Unsere CI baut immer montags um 03:00. Dieser ist Dienstag um 14:00." Nützlich, um zu erkennen, wann eine interne Build-Pipeline verrückt gespielt oder kompromittiert wurde.

Wofür es nicht gut ist#

First-Seen-Zeit auf dem Host. Verwenden Sie KeyLastWriteTimestamp.
Reihenfolge der Ankunft. Zwei Binaries mit demselben LinkDate können Monate auseinander angekommen sein.
Kryptografische Identität. Viele unzusammenhängende Binaries teilen sich LinkDate-Werte, besonders null.