Kann man dem Kompilierzeitstempel im PE-Header vertrauen, um eine Malware-Probe zu datieren?

Analysten lieben den PE-Kompilierzeitstempel, weil er wie kostenlose Attributionsdaten aussieht. Der Haken: Es ist nur eine Zahl, die die Toolchain in den Header schrieb.

Was die Spezifikation sagt

Die Microsoft-Dokumentation zum PE-Format definiert TimeDateStamp im COFF-Dateiheader als die unteren 32 Bit eines C-Laufzeit-time_t-Werts, der „angibt, wann die Datei erstellt wurde". Dieselbe Seite vermerkt, dass ein Wert von 0 oder 0xFFFFFFFF keinen realen oder aussagekräftigen Zeitstempel darstellt, und verweist auf IMAGE_DEBUG_TYPE_REPRO als Ausnahme vom üblichen Zeitformat. Dieser Debug-Typ existiert für reproduzierbare Builds, die deterministische Ausgabe anstreben.

Warum das nur schwache Evidenz ist

Der Loader prüft das Feld nicht, und nichts im Format signiert es (eigene Schlussfolgerung aus der Spezifikation, kein Zitat). Wer Header-Bytes umschreiben kann oder dessen Toolchain deterministische oder genullte Werte erzeugt, bestimmt, was Sie sehen. Ein Datum in der Zukunft oder 1992 ist ein klassisches Warnsignal, aber ein plausibler Wert beweist ebenfalls nichts.

Richtig nutzen

• Mit anderen Artefakten abgleichen: Debug-Verzeichniseinträge, Rich-Header, Ressourcen, First-Seen-Daten in öffentlichen Sandboxes.
• Häufungen über eine Kampagne suchen, statt einer einzelnen Probe zu trauen.
• Im Bericht als „angegebene Kompilierzeit" festhalten.

Warum die Distraktoren verlockend sind

„Kryptografisch gebunden" und „Windows lehnt zukünftige Zeitstempel ab" erfinden Prüfungen, die es nicht gibt. „Dateigröße" verwechselt ein anderes Headerfeld.

Was Interviewer hören wollen

„Nützlich, aber nicht vertrauenswürdig: bestätigen." Die Vorbehalte zu 0/0xFFFFFFFF und reproduzierbaren Builds zeigen, dass Sie die Spezifikation gelesen haben.