← Zurück zum Blog

Die vier MFT-Zeitstempel und wie Timestomping in ihnen sichtbar wird

· 6 Min. Lesezeit

Jeder MFT-Datensatz speichert vier Zeitstempel in zwei separaten Attributen. Das sind acht Zahlen pro Datensatz. Sie sind nicht immer synchron. Die Beziehung zwischen ihnen, und wo sie zusammenbricht, ist die Grundlage der NTFS-Zeitanalyse. Wenn du nur ein Detail der MFT-Forensik lernst, lerne dieses.

Die vier Momente, die NTFS aufzeichnet

Sowohl $STANDARD_INFORMATION (SI, Attributtyp 0x10) als auch $FILE_NAME (FN, Attributtyp 0x30) tragen Zeitstempel für dieselben vier Ereignisse:

  • Erstellt: wann die Datei erstmals auf das Volume geschrieben wurde.
  • Geändert: wann sich der Dateiinhalt zuletzt änderte.
  • Zugegriffen: wann die Datei zuletzt gelesen wurde.
  • MFT-geändert: wann der Datensatz selbst zuletzt aktualisiert wurde (jede Attributänderung, nicht nur Daten).

Die Zeitstempel werden als 64-Bit-Werte im Windows-FILETIME-Format (100-Nanosekunden-Ticks seit 1601-01-01 UTC) gespeichert. 100-Nanosekunden-Granularität. Genug Bits, damit natürliche Ereignisse Rauschen in den unteren Ziffern hinterlassen.

Warum zwei Sätze existieren

$STANDARD_INFORMATION ist der Zeitstempelsatz, den das Userland sieht. Die Win32-API SetFileTime schreibt hier. Jede Routinedateioperation, die einen Zeitstempel berührt, aktualisiert SI: Schreiben, Lesen (abhängig von der Zugriffszeit-Einstellung), Umbenennen, Attributänderung.

$FILE_NAME wurde für POSIX-Subsystem-Kompatibilität in frühem NT hinzugefügt und besteht aus historischen Gründen fort. Es wird nur aktualisiert, wenn sich der Name ändert: Erstellung (wenn der Name erstmals gesetzt wird), Umbenennung (wenn sich der Name ändert) oder Verschiebung zwischen Verzeichnissen (was im NTFS-Sinn umbenennt). Danach sitzt FN unverändert, solange die Datei diesen Namen behält.

In der Praxis bedeutet das, dass SI-Zeitstempel ständig ticken, während FN-Zeitstempel stabil bleiben. Die Asymmetrie ist, was Timestomping erkennbar macht.

Was Timestomping tut

Tools, die Zeitstempel ändern, rufen meist SetFileTime auf. Das schreibt in SI. Es berührt FN nicht. Nach dem Timestomping:

  • SI zeigt, was der Angreifer gewählt hat. Oft Jahre zurückdatiert (um ein kürzlich abgelegtes Tool wie eine Systemdatei aussehen zu lassen) oder nach vorne geschoben (um die tatsächliche Aktivitätszeit zu verschleiern).
  • FN spiegelt weiterhin die echte Erstellungszeit wider, möglicherweise mit weitem Abstand.

Das produziert die kanonische Timestomping-Signatur: eine Datei mit SI created 2018 und FN created vor sechs Minuten.

Zwei Muster, auf die man bei der Triage achten sollte:

  1. SI created älter als FN created. Das ist natürlich unmöglich. Dateien können nicht existieren, bevor sie benannt werden. Jeder Datensatz, bei dem SI created vor FN created liegt, wurde manipuliert.
  2. SI modified weit weg von FN modified bei einer Datei, die offensichtlich nicht umbenannt wurde. FN modified bewegt sich nur bei Umbenennungen; wenn SI 2017 sagt und FN gestern, ohne Umbenennung dazwischen, stimmt etwas nicht.

Der Double-Rename-Trick

Operatoren, die wissen, dass SI/FN-Divergenz erkennbar ist, nutzen einen Workaround: Datei umbenennen (was NTFS zwingt, FN zu aktualisieren), dann SetFileTime auf sowohl SI als auch FN aufrufen, dann zurückbenennen. Jetzt zeigen beide Attribute die zurückdatierten Werte.

Das besiegt den SI/FN-Vergleich. Es besiegt nicht:

  • Das USN-Journal. Jede Umbenennung schreibt ein RENAME_OLD_NAME / RENAME_NEW_NAME-Paar. Die zwei Umbenennungen, die für den Trick nötig sind, sind im Journal sichtbar. Ihre Zeitstempel im Journal sind die tatsächlichen Zeiten, nicht die gefälschten FN-Werte.
  • $LogFile. Transaktionsdatensätze rund um die Umbenennung sitzen im Log.
  • VSS-Snapshots. Ältere Snapshots haben die Pre-Stomp-FN-Werte. Diffe die aktuelle MFT gegen die MFT des Snapshots für denselben Datensatz.

Der Double Rename ist schwerer leise zu machen. Er ist immer noch häufig in reifen Red-Team-Toolkits.

Sub-Sekunden-Granularität, der Hinweis fauler Tools

NTFS speichert Zeitstempel in 100-Nanosekunden-Ticks. Native Windows-Operationen hinterlassen Rauschen in den unteren Ziffern. Das OS nullt die Sub-Sekunden-Komponente beim Schreiben eines Zeitstempels nicht aus; was die Kernel-Uhr zurückgab, wird aufgezeichnet.

Die meisten Timestomping-Tools runden vor dem Schreiben auf die nächste Sekunde. Das Ergebnis ist ein Zeitstempel, der auf .0000000 UTC endet. Ein einzelner solcher Zeitstempel ist unauffällig (gelegentliche natürliche Ereignisse runden). Eine Spalte von .0000000-Suffixen, sauber aufgereiht über viele Dateien, ist ein Fingerabdruck.

Das ist leicht zu prüfen. Nimm die Spalten created, modified, accessed und MFT-modified aus deinem MFT-Parse. Filtere nach jedem Datensatz, in dem alle vier SI-Zeitstempel auf .0000000 enden. Vergleiche mit einer Baseline natürlicher Windows-Aktivität. Der Kontrast ist sofort sichtbar.

Was Windows selbst Zeitstempeln antut

Um den SI/FN-Vergleich zu nutzen, musst du wissen, was Windows den vier Feldern allein antut. Der Spickzettel:

  • SI created: bei der Erstellung geschrieben. Wird von manchen Installern aktualisiert, wenn sie eine Datei "erstellen", indem sie sie extrahieren.
  • SI modified: bei jedem Datenschreib geschrieben. Aktualisiert durch SetFileTime. Nicht durch reine Metadatenänderungen aktualisiert.
  • SI accessed: standardmäßig auf Windows 7+ deaktiviert (setze fsutil behavior set disablelastaccess 0, um zu aktivieren). Wenn deaktiviert, wird dieses Feld dennoch gelegentlich von bestimmten Operationen aktualisiert (Backup-Software, EDR-Scans), ist aber als "Zuletzt-gelesen"-Signal in beide Richtungen unzuverlässig.
  • SI MFT-modified: bei jeder Attributänderung geschrieben, einschließlich Umbenennungen, ACL-Änderungen, ADS-Erstellung und Datenschreiben.
  • FN created: geschrieben, wenn der Name erstmals gesetzt wird (Erstellung, Hard-Link-Erstellung, Umbenennung).
  • FN modified, FN accessed, FN MFT-modified: geschrieben, wenn der Name gesetzt wird, dann weitgehend stabil.

Auf einer sauberen Installation sind die vier Zeitstempel von FN typischerweise gleich (alle wurden zum gleichen Zeitpunkt gesetzt, als der Name vergeben wurde). Wenn du FN mit allen vier identischen Zeitstempeln und die vier SI divergent siehst, ist das normal.

Windows Update und gepatchte Binärdateien

Windows Update berührt die SI-Zeitstempel gepatchter Binärdateien. Nach einem kumulativen Update hat die Hälfte von \Windows\System32\ SI modified innerhalb von Minuten voneinander, und FN, das seit dem letzten Service Pack stabil ist. Das ist normal. Behandle es als Baseline-Muster, nicht als anomale Aktivität.

Querverweis mit CBS.log und setupapi.dev.log für das Patching-Fenster. Wenn SI sagt, svchost.exe wurde um 03:14 modifiziert und das CBS-Log einen Komponenteneinbau um 03:14 zeigt, ist das Windows Update, kein Angreifer.

Wie ich nach Timestomping screene

Das Screening, das ich auf einem frischen MFT-Extrakt laufen lasse:

  1. Ziehe jeden Datensatz, bei dem SI created < FN created. Prüfe jeden manuell.
  2. Ziehe jeden Datensatz, bei dem SI modified mehr als 30 Tage vor FN modified liegt und die Datei in einem vom Benutzer beschreibbaren Verzeichnis ist. Manuell prüfen.
  3. Ziehe jeden Datensatz, bei dem alle vier SI-Zeitstempel auf .0000000 enden und die Datei keine Windows-Systembinärdatei ist. Manuell prüfen.
  4. Diffe die aktuelle MFT gegen den neuesten VSS-Snapshot. Markiere Datensätze, deren SI-Zeitstempel sich rückwärts bewegten. Manuell prüfen.

Diese Sequenz fängt den Großteil des Timestomping in freier Wildbahn. Anspruchsvolle Operatoren, die den Double-Rename-Trick oder VSS-Löschung verwenden, brauchen die Journal- und Ereignisprotokollschichten zur Erkennung, aber die obigen vier Prüfungen werden sie ohnehin durch andere Artefakte aufdecken (die Umbenennung im USN-Journal, die VSS-Löschung im Ereignisprotokoll).

Weiterführende Literatur

Verwandte Artikel

Externe Ressourcen