Skip to content

macOS-FSEvents-Forensik: Was .fseventsd beweist

Was das FSEvents-Log von macOS aufzeichnet, wo .fseventsd liegt, was es beweisen kann und was nicht, und wie man es ohne exakte Zeitstempel liest.

Veröffentlicht am 4 Min. Lesezeit

Kurzfassung. FSEvents ist eine Historie jedes macOS-Volumes auf Pfadebene: welche Dateien und Ordner erstellt, geändert, umbenannt oder entfernt wurden, und in welcher Reihenfolge. Es gibt keine Zeitstempel, keinen Benutzer und keinen Prozess, aber FSEvents erinnert sich oft an Dateien, die längst verschwunden sind. Sichern Sie den gesamten .fseventsd-Ordner mitsamt den Änderungszeiten der Dateien und lesen Sie ihn mit einem Parser, der die zeitliche Unsicherheit sichtbar lässt, etwa dem FSEvents Parser auf dieser Website.

Was fseventsd schreibt

Der Daemon fseventsd existiert, damit Time Machine, Spotlight und Sync-Clients fragen können: „Was hat sich unterhalb dieses Ordners seit Punkt X geändert?“, ohne die Festplatte neu zu scannen. Um das auch über Neustarts hinweg beantworten zu können, führt er auf jedem beschreibbaren Volume, das er überwacht, ein dauerhaftes Journal in einem versteckten Ordner im Stammverzeichnis des Volumes:

macOSOrdner
10.15 Catalina und neuer/System/Volumes/Data/.fseventsd/ (das Data-Volume)
10.14 und älter/.fseventsd/
Externe Laufwerke/Volumes/<name>/.fseventsd/

Der Ordner enthält gzip-komprimierte Logdateien mit 16-stelligen Hex-Namen, eine Datei fseventsd-uuid, die den Event-Stream identifiziert, und manchmal eine no_log-Markierung. Jedes Log enthält eine oder mehrere Seiten mit Datensätzen. Ein Datensatz besteht aus:

  • einem Pfad, relativ zum Stammverzeichnis des Volumes (Users/dana/Downloads/tools.zip);
  • einer 64-Bit-Event-ID aus einem systemweiten Zähler, der nur aufwärts zählt;
  • einem 32-Bit-Satz von Flags: was passiert ist (erstellt, entfernt, umbenannt, geändert, erweitertes Attribut geändert …) und mit welchem Objekt (Datei, Ordner, Symlink, Hardlink);
  • ab macOS 10.13 einer Node-ID; ab macOS 14 vier weiteren Bytes, deren Bedeutung Apple nicht dokumentiert hat.

Das Layout auf Byte-Ebene beschreibt der Artikel zum FSEvents-Dateiformat.

Was es beweist

  • Existenz. Taucht ein Pfad in einem Datensatz auf, existierte ein Objekt mit diesem Namen an diesem Ort auf diesem Volume, auch wenn es inzwischen gelöscht wurde.
  • Art der Änderung. Erstellt, geändert, umbenannt oder verschoben, entfernt, Rechte geändert, erweitertes Attribut hinzugefügt oder entfernt, Finder-Info geändert, geklont.
  • Reihenfolge. Event-IDs steigen monoton, daher lassen sich Datensätze zuverlässig in eine Abfolge bringen, auch über mehrere Volumes desselben Macs hinweg.
  • Nutzung von Wechseldatenträgern. Das Data-Volume protokolliert Ein- und Aushänge-Ereignisse unter Volumes/<name>; der eigene .fseventsd-Ordner des Laufwerks protokolliert, was darauf geschrieben wurde.

Was es nicht beweist

  • Wann genau. Ein Datensatz enthält keinen Zeitstempel. Siehe FSEvents-Datensätze zeitlich einordnen.
  • Wer oder was. Weder Benutzer noch Prozess werden erfasst. Das 3SLD-Zusatzfeld wird von FSEventsParser als Benutzer-ID dekodiert; behandeln Sie das als unbestätigt.
  • Jeden einzelnen Schritt. Zeitlich nah beieinanderliegende Änderungen an einem Pfad werden zu einem Datensatz zusammengefasst: Created;Modified;Removed in einer einzigen Zeile verrät nicht die Reihenfolge.
  • Inhalt. Nur Namen. Kombinieren Sie mit APFS-Snapshots, Time Machine oder Carving, um Daten wiederherzustellen.
  • Netzwerkfreigaben und schreibgeschützte Volumes. Werden nicht protokolliert.

Wo es sich auszahlt

  1. Persistenz. Eine LaunchAgent-plist, die in ~/Library/LaunchAgents erstellt wurde, auch wenn sie später entfernt wurde.
  2. Staging und Aufräumen. Dutzende Dokumente, die in einem versteckten Ordner auftauchen und dann auf einen Schlag entfernt werden.
  3. Downloads. Ein Archiv, das zehn Minuten lang in Downloads lag, mit hinzugefügtem Quarantäne-Attribut, gefolgt von einem Attribut, das vom entpackten Inhalt entfernt wurde.
  4. Datenschutzberechtigungen. Schreibvorgänge in die TCC-Datenbank etwa zu dem Zeitpunkt, als Terminal Festplattenvollzugriff (Full Disk Access) erhielt.
  5. Exfiltration per USB. Ein Einhängen von Volumes/EXFIL auf dem Mac und auf dem Stick selbst die Liste der geschriebenen Dateien.

Das durchgespielte Exfiltrationsbeispiel zeigt alle fünf in einem fiktiven Fall.

Richtig lesen

  • Zuerst nach Pfad filtern. Ein stark genutzter Mac erzeugt Hunderttausende Datensätze pro Tag. Beginnen Sie bei Users/*/Downloads, Library/LaunchAgents, Users/Shared, private/tmp und Volumes/ und erweitern Sie dann.
  • Node-IDs über Umbenennungen verfolgen. Eine Umbenennung besteht aus zwei Datensätzen (alter und neuer Pfad), die bei 2SLD und 3SLD dieselbe Node-ID tragen.
  • Die Unsicherheit beibehalten. Berichten Sie „zwischen 10:09:55 und 10:23:18 UTC“, nicht „um 10:23:18“.
  • Korrelieren. Quarantäne-Ereignisse, Unified Logs, APFS-Zeitstempel und die Flag-Referenz grenzen den Ablauf ein.
  • Korrekt sichern. Die Änderungszeiten sind Ihre einzige Uhr: siehe .fseventsd richtig sichern.

FAQ

Was ist FSEvents in der macOS-Forensik?

Ein dauerhaftes Protokoll der Dateisystemänderungen, das der Daemon fseventsd in einen versteckten .fseventsd-Ordner auf jedem Volume schreibt. Jeder Datensatz enthält einen Pfad, eine Event-ID und Flags wie Created, Removed oder Renamed.

Zeichnet FSEvents gelöschte Dateien auf?

Ja. Eine Löschung wird als Datensatz mit dem Flag Removed und dem vollständigen Pfad protokolliert, daher bewahrt FSEvents oft Namen und Speicherort von Dateien, die nicht mehr existieren.

Hat FSEvents Zeitstempel?

Nein. Datensätze tragen nur eine Event-ID. Die Zeit wird aus den Änderungszeiten der Logdateien geschätzt, was ein Zeitfenster statt eines Zeitpunkts ergibt.

Verwandte Artikel