Eine $LogFile-Untersuchung Schritt für Schritt (fiktiv)

TL;DR. Dieser Fall ist fiktiv. Er verwendet das synthetische $LogFile und die $MFT, die dem Browser-Parser für das $LogFile beiliegen (Beispiel ausprobieren). In 57 Minuten Log bekommt ein fremdes Konto svc_backup ein Profil, lädt tools.zip herunter, entpackt m64.exe, verschiebt es nach \ProgramData\Intel und datiert es auf 2019 zurück, legt rc.tmp ab und benennt es in rclone.exe um, schreibt und löscht creds.txt und hinterlässt eine .lnk auf Payroll_2026.xlsx. Das Log belegt die Verschiebungen, das Umschreiben der Zeitstempel und die Löschung mit Vorher-/Nachher-Werten. Ausführung oder Exfiltration belegt es nicht; dafür braucht es andere Artefakte.

Die Geschichte setzt die fort, die sich durch diese Familie von Parser-Websites zieht: ein Arbeitsplatz in der Finanzabteilung, ein nach Dienstkonto aussehendes Konto, das es nicht geben dürfte, und eine Gehaltsdatei, die auf einem USB-Stick gelandet ist. Jeder Name, jede Uhrzeit und jedes Byte unten ist erfunden, und das Log wurde anhand des veröffentlichten Formats erzeugt, nicht unter Windows gesichert.

Die (fiktive) Ausgangslage

• Host: FIN-WKS-07, Windows 11, Finanzabteilung.
• Auslöser: ein DLP-Alarm wegen Gehaltsdaten auf einem Wechseldatenträger; ein Konto namens svc_backup, das niemand bewusst angelegt hat.
• Frage der Incident-Leitung: „Was hat svc_backup heute Morgen auf diesem Rechner getan, und was hat es angefasst?“
• Gesichert (live, mit KAPE, auf ein externes Laufwerk): C:\$LogFile, C:\$MFT, C:\$Extend\$UsnJrnl:$J, Prefetch, Registry-Hives, Ereignisprotokolle. Vorgehen wie in Das NTFS-$LogFile sichern: live und post mortem.

Erster Blick auf das Log

Die Kopfzeile des Parsers:

• LFS 2.0, nicht sauber ausgehängt → live gesichert unter Windows 8 oder neuer ($LogFile-Format 1.1 vs. 2.0).
• 1 Seite aus dem Fast-Page-Bereich übernommen → die neuesten Logeinträge existierten nur dort.
• 100 Logeinträge, LSN 115720 → 117880, keine Warnungen.

Ein echtes Log eines Systemvolumes wäre rund 64 MiB groß und enthielte Hunderttausende Einträge; das synthetische ist 256 KiB groß, damit die Geschichte lesbar bleibt.

Aus dem Log rekonstruierte Zeitleiste

Zeiten in UTC, aus den Daten in den Logeinträgen (Spalte Zeit aus). „≈“ bedeutet: vom nächstgelegenen datierten Ereignis übernommen.

Hintergrundrauschen wurde weggelassen: Zeitstempel-Aktualisierungen der SRUM-Datenbank um 10:15 und 10:45 sowie eine um 10:20 in \Windows\Temp angelegte und wieder gelöschte temporäre Datei.

Phase für Phase gelesen

Erste Anmeldung (09:58). Die Profilordner von svc_backup erscheinen. Der Ordner Recent unter AppData steht nicht im erhaltenen Log – seine Einträge wurden überschrieben –, aber die $MFT kennt seinen Namen; deshalb wird die .lnk später zu einem vollständigen Pfad aufgelöst. Ohne die $MFT begännen mehrere Pfade mit [MFT #n].

Toolkit (10:04–10:07). tools.zip landet in Downloads; es folgt ein Ordner tools mit m64.exe und readme.txt. Der Text der Readme ist resident, ihre ersten Bytes sind also im Log sichtbar: Sie beschreibt m64.exe als „memory utility“, die als Administrator auszuführen sei – ein Hinweis auf ein Werkzeug zum Auslesen des Arbeitsspeichers. Um 10:07:03 wird eine Prefetch-Datei für 7ZFM.EXE angelegt; das passt dazu, dass der Dateimanager von 7-Zip rund um das Entpacken lief.

Verstecken der Binärdatei (10:09). Ein neuer Ordner \ProgramData\Intel wird angelegt, m64.exe dorthin verschoben, und anschließend werden ihre $STANDARD_INFORMATION-Zeitstempel umgeschrieben: vorher erstellt 10:06:52.3551871, nachher alle vier Zeiten 2019-03-19 07:14:22.0000000. Der Parser nennt vier Gründe – Erstellungszeit überschrieben, Werte rückwärts gesprungen, volle Sekunden, $SI-Erstellung vor der $FN-Erstellung. Methode und Fehlalarme beschreibt Timestomping mit dem NTFS-$LogFile erkennen. Hier gibt es zu diesem Zeitpunkt kein Entpacken und keine Wiederherstellung, das Ziel ist eine ausführbare Datei in einem nach Hersteller aussehenden Ordner, und die Änderung folgt auf eine gezielte Verschiebung: ein starker Befund, den Sie mit dem BASIC_INFO_CHANGE aus dem USN-Journal für die tatsächliche Uhrzeit untermauern.

Hinweis auf Ausführung (10:12). M64.EXE-1C9E54B7.pf wird angelegt. Das Anlegen einer Prefetch-Datei ist ein starkes Indiz dafür, dass m64.exe lief; bestätigen Sie das, indem Sie die Prefetch-Datei selbst auswerten (Prefetch-Parser) – für Ausführungszähler und Zeiten.

Bereitstellen von Exfiltrationswerkzeugen (10:31). rc.tmp wird in \Users\Public abgelegt und vierzehn Sekunden später in rclone.exe umbenannt. Die Umbenennung steht mit beiden Namen im Log. Ob rclone lief und wohin es Daten schickte, klären Prefetch, Amcache (Amcache-Parser), die SRUM-Netzwerknutzung (SRUM-Parser) und Proxy-Logs.

Notiz mit Zugangsdaten (10:38). creds.txt wird auf dem Desktop angelegt, ihr Inhalt geschrieben (resident, im Log sichtbar: ein Freigabepfad und der Kontoname, als SYNTHETIC markiert), um 10:38:27 geändert und dann gelöscht. Die Löschung hat keine eigene Zeit: „zu diesem Zeitpunkt oder nach 10:38:27“. Siehe Spuren gelöschter Dateien im $LogFile finden.

Gehaltsdaten (10:47). In Recent erscheint eine Verknüpfung Payroll_2026.xlsx.lnk – der Benutzer hat also eine Datei dieses Namens geöffnet. Zielpfad und Volume-Seriennummer stehen in der .lnk selbst (LNK-Parser); in dieser Geschichte zeigt sie auf den USB-Stick E:.

Was in den Bericht gehört

Schreiben Sie Beobachtungen, keine Markierungen:

Im NTFS-Transaktionsprotokoll des Volumes C: (Logeinträge LSN 116846 und 116951) wurde die Datei \ProgramData\Intel\m64.exe (MFT-Eintrag 322) aus \Users\svc_backup\Downloads\tools\ verschoben, und ihre $STANDARD_INFORMATION-Zeitstempel wurden von 2026-09-14 10:06:52 UTC (Erstellung) für alle vier Werte auf 2019-03-19 07:14:22 UTC geändert. Das Log enthält keine Uhrzeit der Änderung; sie erfolgte nach 10:09:40 UTC (Verschiebung) und vor dem nächsten datierten Ereignis.

Zitieren Sie LSNs, bewahren Sie die Rohexporte auf (CSV/JSON der gefilterten Ereignisse und ihrer Logeinträge), und nennen Sie das Werkzeug samt seiner Grenzen: Der hier verwendete Parser ist an synthetischen Daten validiert, dieselben Einträge sollten also mit einem zweiten Werkzeug bestätigt werden ($LogFile-Parser-Vergleich: LogFileParser, NTFS Log Tracker).

Was das Log nicht beantworten konnte

• Lief rclone.exe? Wurden Daten übertragen? Keine Frage von Dateisystem-Metadaten.
• Wann genau wurde m64.exe zurückdatiert oder creds.txt gelöscht? USN-Journal.
• Was geschah vor 09:58? Außerhalb des Log-Fensters; USN-Journal und Schattenkopien reichen weiter zurück (Wie weit reicht das $LogFile zurück?).
• Wer saß an der Tastatur? Anmeldeereignisse, RDP-Artefakte (EVTX-Parser).

Der Beitrag des $LogFile ist schmal, aber stark: eine präzise, geordnete Darstellung der Metadatenänderungen der letzten Stunde – einschließlich Werten, die andere Artefakte überschreiben.

Verwandte Artikel

• Ein NTFS-$LogFile Schritt für Schritt analysieren
• Timestomping mit dem NTFS-$LogFile erkennen
• NTFS-$LogFile-Forensik: der vollständige Leitfaden