Timestomping und Anti-Forensik im USN Journal erkennen

Operatoren, die sich um ihr Handwerk kümmern, löschen nicht nur Beweise. Sie tarnen, was sie zurücklassen. Der häufigste Zug ist Timestomping — das Umschreiben der Zeitstempel einer NTFS-Datei, sodass die Datei unschuldig aussieht oder aus dem Untersuchungsfenster herausfällt. Es funktionierte einmal zuverlässig. Mit aktiviertem USN Journal, was auf jedem modernen Windows-Host standardmäßig der Fall ist, hinterlässt es eine so charakteristische Signatur, dass ein einzelner Filter und eine Pfadauflösung des Übergeordneten sie zum Vorschein bringen.

Dieser Beitrag durchläuft, was Timestomping mit der Festplatte tut, wie das Journal es entlarvt und welche anderen anti-forensischen Züge Sie mit demselben Artefakt gratis abfangen können.

Eine kurze Auffrischung zu NTFS-Zeitstempeln

Jeder MFT-Eintrag trägt Zeitstempel in zwei Attributen:

• $STANDARD_INFORMATION (SI). Die Zeitstempel, die User-Space-Tools und die meisten APIs lesen und schreiben. dir, Explorer, Get-ChildItem, os.stat, GetFileTime — sie alle geben SI zurück. Microsoft dokumentiert das Layout in der NTFS-Dateizeiten-Referenz.
• $FILE_NAME (FN). Die Zeitstempel, die NTFS intern für jedes $FILE_NAME-Attribut setzt (eine Datei kann mehrere Namen haben, wenn sie hardgelinkt ist). FN-Werte sind viel schwerer zu ändern — sie aktualisieren sich nur bei bestimmten Operationen, und der Kernel legt keine saubere API offen, um sie umzuschreiben.

Timestomping-Tools zielen standardmäßig auf SI. Das ältere Metasploit timestomp.exe, SetMACE und Dutzende von benutzerdefinierten Implantaten, die von Operatoren mit auch nur bescheidenem Handwerk geschrieben wurden, schreiben alle $STANDARD_INFORMATION über NtSetInformationFile mit einer FileBasicInformation-Payload um. Moderne Implantate (Cobalt Strikes timestomp-Befehl darunter) können auch FN umschreiben, indem sie die MFT direkt manipulieren, was aufwendiger ist und zusätzliche $LogFile-Beweise produziert.

So oder so lässt der Akt des Schreibens des MFT-Eintrags das Journal aufleuchten.

Was das Journal für eine Zeitstempel-Bearbeitung aufzeichnet

Wenn SI-Zeitstempel geschrieben werden, gibt NTFS einen BasicInfoChange | Close-Eintrag auf der FileReferenceNumber der Datei aus. Dieser Eintrag ist die Diagnose:

• Eine legitime Berührung produziert BasicInfoChange | Close zusammen mit einem DataExtend oder DataOverwrite aus dem tatsächlichen Schreibvorgang, der das Zeitstempel-Update ausgelöst hat.
• Ein Timestomp produziert ein nacktes BasicInfoChange | Close ohne vorangehenden Schreibvorgang auf derselben FileReferenceNumber.

Wenn Sie BasicInfoChange | Close ohne DataOverwrite, DataExtend, FileCreate oder Rename in derselben Handle-Sitzung sehen, schauen Sie auf Metadaten-Manipulation. Die überwältigende Mehrheit davon ist Timestomping; der Rest sind Attribut-Umschaltungen (+H, +R, Kompression an/aus) und EFS-Zustandsänderungen.

Der SI-vs-FN-Vergleich

Die maßgeblichste Timestomping-Erkennung vergleicht die SI-Zeitstempel jeder Datei mit ihren FN-Zeitstempeln. Das Muster geht auf Mandiants frühe Windows-Forensik-Forschung zurück und wird in Brian Carriers File System Forensic Analysis abgedeckt. Die Formen, die Sie aufmerken lassen sollten:

• SI früher als FN. Eine Datei kann nicht legitim vor der Existenz ihres Namens modifiziert worden sein. Das ist der kanonische Smoking Gun.
• SI in der Zukunft von FN mit einem unrealistischen Spielraum. Operator, der das scheinbare Alter nach vorne schiebt, damit es wie eine Systemdatei aus einer sauberen Installation aussieht.
• Sowohl SI als auch FN sehen unmöglich sauber aus — runde Sekunden, identische M/A/C/B-Werte, alle passend zu einem bekannten Windows-Installationsdatum. Einen genaueren Blick wert, selbst wenn kein einzelnes Paar markiert.

Das Journal ergänzt den Vergleich, anstatt ihn zu ersetzen. Der MFT-Vergleich sagt Ihnen, dass etwas die Zeitstempel manipuliert hat. Das Journal sagt Ihnen genau wann die SI-Umschreibung stattfand, was der Zeitstempel ist, den Sie in den Bericht setzen. Paaren Sie die beiden, und der Fall schreibt sich selbst:

1. MFT-Vergleich markiert SI < FN bei \Windows\System32\drivers\suspicious.sys.
2. Journal hat ein BasicInfoChange | Close auf der FileReferenceNumber der Datei bei 2026-04-12 03:08:14Z ohne umgebende Schreibvorgänge.
3. Dieser Zeitstempel ist, wann der Operator seinen timestomp-Befehl ausgeführt hat. Korrelieren Sie mit Sysmon Event 1, und Sie haben den Prozess.

$LogFile und das Journal sollten übereinstimmen

Das Journal zeichnet Schreibvorgänge auf Per-Datei-Ebene auf. $LogFile zeichnet die zugrunde liegenden MFT-Transaktionen auf der Metadaten-Schreib-Ebene auf. Ein Timestomp produziert:

• Eine MFT-Schreib-Transaktion in $LogFile, die das $STANDARD_INFORMATION-Attribut des Ziel-Eintrags modifiziert.
• Ein BasicInfoChange | Close im Journal.

Wenn $LogFile eine MFT-Update-Transaktion auf einer Datei ohne passendes Journal-BasicInfoChange | Close zeigt, hat der Operator möglicherweise den Journal-Eintrag gelöscht, indem er $UsnJrnl gewischt und ein neues erstellt hat. Dieses Manöver ist möglich (fsutil usn deletejournal /D /N C: gefolgt von fsutil usn createjournal /m ... /a ... C:), aber selbst laut.

Andere anti-forensische Züge, die das Journal abfängt

Das Journal deaktivieren oder wischen

fsutil usn deletejournal /D /N C: entfernt das Journal vollständig. Nachdem es ausgeführt wurde:

• Die Journal-Datei wird leer neu aufgebaut. Pre-Call-Einträge sind für immer weg.
• Der MFT-Eintrag von $UsnJrnl wird frisch geschrieben, was $LogFile aufzeichnet.
• Das Security-Log zeichnet ein Sensitive Privilege Use-Ereignis für SeRestorePrivilege oder SeManageVolumePrivilege auf, wenn SACLs konfiguriert waren (was sie normalerweise nicht waren).

Das Journal kann Ihnen nicht sagen, was es früher enthielt, aber der Akt des Deaktivierens selbst ist ein starkes Anti-Forensik-Signal. Microsoft dokumentiert die Verwaltungsbefehle in der fsutil-usn-Referenz.

Operatoren, die wissen, dass das Journal existiert, tun in der Regel eines von zwei Dingen: es auf dem Weg nach draußen wischen (laut) oder selektiv vermeiden, Beweise darin zu hinterlassen (schwerer, erfordert, von der Festplatte fernzubleiben). Auf einem Host, bei dem das Journal um ein bekanntes Vorfallsfenster verdächtig leer ist, behandeln Sie das als eine zu testende Hypothese.

Alternative Datenströme

ADS-Versteck ist älter als ich, und das Journal zeichnet es sauber auf. Das StreamChange-Reason-Bit feuert, wenn ein alternativer Datenstrom hinzugefügt, umbenannt oder von einer Datei entfernt wird. Filtern Sie nach StreamChange, und jedes ADS-Erstellungs-/Modifikations-Ereignis auf dem Volume taucht auf.

Erwartete False Positives: legitime Zone.Identifier-Streams von Browser-Downloads (gepaart mit dem FileCreate der Host-Datei), Mark-of-the-Web-Streams von E-Mail-Clients und SmartScreen-Status. Alles andere, das StreamChange-Einträge auf signierten System-Binärdateien, auf Dateien in \Windows\System32\ oder auf Benutzerprofil-Binärdateien außerhalb des normalen Browser-Download-Flusses produziert, verdient einen Blick.

Hardlink-Tricks

HardLinkChange feuert, wenn Hardlinks hinzugefügt oder entfernt werden. Operatoren verwenden manchmal Hardlinks, um eine bösartige Binärdatei über zwei Übergeordnete zugänglich zu machen, was AppLocker-Regeln und pfadbasierte EDR-Kontrollen besiegen kann. Pivotieren Sie auf FileReferenceNumber, um alle Übergeordneten für einen gegebenen Inode zu sehen.

Reparse-Point-Missbrauch

ReparsePointChange leuchtet auf, wenn ein Reparse Point — Junction, Symbolic Link, Mount Point — hinzugefügt, modifiziert oder entfernt wird. Suchen Sie nach Reparse Points, die in \$Recycle.Bin\, \Users\Default\, \ProgramData\ oder anderen Stellen erstellt werden, wo sie normalerweise nicht existieren würden. Der Recycle-Bin-Parser ist das komplementäre Artefakt für die $Recycle.Bin-Seite.

Security- und Object-ID-Änderungen

SecurityChange legt ACL- und Eigentümer-Umschreibungen offen. ObjectIdChange legt die selteneren Object-ID-Manipulationen offen. Beide sind auf einem gesunden Host leise. Bursts von beiden auf Benutzerprofil-Binärdateien oder auf Systemdateien sind es wert, nachverfolgt zu werden.

Eine praktische Scan-Prozedur

Der schnellste Screen für Timestomping mit einem geparsten Journal:

1. Auf Einträge filtern, deren Reason-Maske genau BasicInfoChange | Close ist. Die meisten Parser defaulten auf "enthält das Bit"; Sie wollen für diesen Scan exakte Übereinstimmung.
2. Schauen Sie sich für jeden Kandidaten die vorherigen fünf Minuten von Einträgen auf derselben FileReferenceNumber an. Wenn es kein DataOverwrite, DataExtend, FileCreate oder Rename gibt, markieren Sie den Eintrag.
3. Berechnen Sie für markierte Einträge das SI-vs-FN-Delta in der MFT. Sortieren Sie nach absolutem Delta.

Die Spitze der Liste ist Ihr Timestomping. Die verbleibenden markierten Einträge sind normalerweise attrib +H- oder attrib +R-Aufrufe oder Skripte, die Read-Only umschalten — kontextabhängig, selten interessant für eine typische IR-Untersuchung, aber wert, der Vollständigkeit halber in der gerankten Ausgabe zu bleiben.

Der Parser auf dieser Seite legt exakten Mask-Filter offen. Für Schritt 3 brauchen Sie eine geparste $MFT parallel offen — die meisten Analysten verwenden Eric Zimmermans MFTECmd für den CSV-Export und pivotieren in einer Tabellenkalkulation.

Was Sie auf diese Weise nicht abfangen können

Eine kurze Liste anti-forensischer Züge, die das Journal komplett umgehen:

• Booten von externen Medien und Umschreiben der Festplatte. Hat nie das laufende Betriebssystem berührt, hat nie ins Journal geschrieben.
• Userland-Datei-Umschreibungen, die die Inhaltsgröße am selben Offset bewahren ohne SI-Update. Produziert DataOverwrite-Einträge, verliert aber den Originalinhalt. Das Journal sieht den Schreibvorgang, nicht, was vorher dort war.
• Das Journal vor irgendetwas anderem deaktivieren. Das Journal kann nur aufzeichnen, was passiert ist, während es lief.

Dafür benötigen Sie $LogFile, Volume Shadow Copies, Off-Host-Telemetrie oder einen RAM-Dump, der nahe genug am Vorfall erfasst wurde, um den relevanten Zustand noch zu enthalten.

Weiterführende Literatur

• Microsoft Learn — File Times und die NtSetInformationFile-API-Referenz. Letzteres ist der Syscall, den jedes Timestomping-Tool letztlich aufruft.
• Eric Zimmermans MFTECmd — der kanonische Offline-Parser für SI- und FN-Zeitstempel in einem flachen CSV.
• Joachim Metzs libfsntfs-Dokumentation — die gründlichste offene Referenz zu $LogFile-Interna, was der zweite Zeuge ist, wenn das Journal allein nicht reicht.
• Brian Carrier, File System Forensic Analysis — das Kapitel über NTFS-Metadaten-Attribute ist immer noch die kanonische Referenz dafür, wie sich SI und FN unter verschiedenen Operationen verhalten.