FSEvents (.fseventsd) : journal des changements macOS

Ce que c'est

Le démon fseventsd tient un journal persistant des changements du système de fichiers afin que les applications (Time Machine, Spotlight, clients de synchronisation) puissent demander « qu'est-ce qui a changé sous ce dossier depuis l'événement X ». Chaque volume inscriptible qu'il suit reçoit un dossier caché .fseventsd contenant des fichiers journaux compressés en gzip. Chaque enregistrement comprend un chemin, un identifiant d'événement sur 64 bits et un masque de drapeaux ; les formats récents ajoutent un identifiant de nœud.

Pour l'enquêteur, c'est un historique du volume au niveau des chemins : fichiers créés puis supprimés dans /private/tmp, archive brièvement présente dans ~/Downloads, plist de LaunchAgent écrit puis retiré, ou contenu d'une clé USB. Le guide FSEvents détaille le format ; cette page sert de référence rapide.

Où il se trouve

Dans le dossier :

• Des fichiers journaux aux noms hexadécimaux de 16 chiffres dérivés des identifiants d'événements, qui se trient donc dans l'ordre des événements.
• fseventsd-uuid : identifie le flux d'événements du volume. Un nouvel UUID signifie que l'historique a été réinitialisé.
• no_log (facultatif) : un fichier vide qui indique à fseventsd de ne pas journaliser le volume.

Protection : le dossier appartient à root. Sur un système live, le processus de collecte a aussi besoin de l'accès complet au disque. mac_apt vérifie en outre /private/var/db/fseventsd comme emplacement alternatif.

Ce qu'il prouve

• Qu'un fichier ou dossier portant un nom donné a existé à un chemin de ce volume, même après sa suppression.
• Le type de changement : création, modification, renommage ou déplacement, suppression, changement de permissions ou de propriétaire, ajout ou retrait d'un attribut étendu (par exemple le retrait de com.apple.quarantine).
• L'ordre relatif des changements sur un volume (les identifiants d'événements croissent de façon monotone).
• Qu'un volume amovible a été modifié sur un Mac, et quels chemins y ont été touchés.

Il ne prouve pas :

• Une heure exacte. Les enregistrements ne portent aucun horodatage.
• Quel utilisateur ou quel processus a effectué le changement.
• Le contenu des fichiers. Associez-le aux snapshots APFS, à Time Machine ou au carving.
• L'activité sur des montages en lecture seule ou des partages réseau, qui ne sont pas journalisés.

Champs clés

Noms de drapeaux courants renvoyés par les parseurs : Created, Removed, Renamed (mac_apt : RenamedOrMoved), Modified, InodeMetaMod, PermissionChange, ExtendedAttrModified / ExtendedAttrRemoved (mac_apt : XAttrModified / XAttrRemoved), FinderInfoMod, FolderCreated, Exchange, ItemCloned, LastHardLinkRemoved, Mount, Unmount, EndOfTransaction, ainsi que des types d'objets comme FileEvent, FolderEvent, SymbolicLink, HardLink. Les valeurs binaires sur disque diffèrent des constantes publiques FSEventStreamEventFlags de l'API Apple : fiez-vous à un parseur qui décode la structure sur disque.

Horodatages

Les enregistrements n'en contiennent aucun. Estimez l'heure à partir de :

1. La date de modification du fichier journal. Un fichier est écrit lorsque fseventsd vide son tampon : son mtime est donc une borne supérieure pour ses enregistrements, et le mtime du fichier précédent une borne inférieure approximative.
2. Les chemins datés. Des chemins contenant une date dans leur nom (journaux ayant subi une rotation, noms de snapshots, rapports de diagnostic) qui apparaissent comme Created servent d'ancres pour les identifiants d'événements voisins. FSEventsParser s'en sert pour remplir sa colonne approx_dates_plus_minus_one_day.
3. La corrélation. Un horodatage réel issu d'un autre artefact pour un chemin (date de naissance APFS, événement de quarantaine, entrée des Unified Logs) date ses voisins.

Présentez toujours les heures FSEvents sous forme d'intervalle et nommez l'ancre utilisée.

Rétention

Pas de durée fixe. fseventsd purge lui-même les anciens fichiers journaux, et l'historique dépend de l'activité et de l'espace du volume. CrowdStrike a signalé des événements d'environ quatre mois sur des systèmes typiques ; les volumes très actifs peuvent en garder beaucoup moins. Un fseventsd-uuid modifié ou un reformatage du volume démarre un nouvel historique. Collectez tôt et préservez les mtime des fichiers.

Collecte

Copiez le dossier entier en conservant les dates de modification (c'est votre seule horloge) :

# Live, as root, from a terminal with Full Disk Access
sudo ditto /System/Volumes/Data/.fseventsd /Volumes/CASE/MBP01/fseventsd
sudo ls -lT /System/Volumes/Data/.fseventsd > /Volumes/CASE/MBP01/fseventsd_listing.txt

• UAC : les profils ir_triage et full incluent l'artefact files/logs/macos.yaml, qui collecte /.fseventsd et /System/Volumes/*/.fseventsd.
• mac_apt : le plugin FSEVENTS lit le dossier directement depuis une image E01, DMG, brute ou montée.
• Aftermath : non collecté par défaut ; ajoutez le dossier avec --collect-dirs.
• Supports amovibles : faites une image du disque ou copiez son .fseventsd avec le même soin.

Analyse

FSEventsParser (gère 1SLD, 2SLD et 3SLD) produit une base SQLite ainsi que des rapports TSV :

python3 FSEParser_V4.1.py -s /cases/MBP01/fseventsd -t folder -o /cases/MBP01/out -c MBP01

-- FSEventsParser schema: deleted items under a user's Downloads
SELECT id_hex, fullpath, type, flags, approx_dates_plus_minus_one_day, source, source_modified_time
FROM fsevents_sorted_by_event_id
WHERE fullpath LIKE 'Users/%/Downloads/%' AND flags LIKE '%Removed;%'
ORDER BY id;

mac_apt analyse les mêmes données depuis une image, avec une colonne SourceModDate pour chaque enregistrement :

python3 mac_apt.py -o /cases/MBP01/mac_apt E01 /cases/MBP01.E01 FSEVENTS

FSEvents Parser décode dans le navigateur un dossier .fseventsd (ou une collecte UAC, Aftermath ou Velociraptor), avec drapeaux décodés, fenêtres de temps, paires de renommage et export CSV ou Timesketch ; rien n'est envoyé.

Conseils d'investigation

• Appariez les enregistrements Renamed par identifiant de nœud (version 2 et ultérieures) pour suivre un fichier à travers renommages et déplacements.
• Un ExtendedAttrRemoved sur un bundle d'application fraîchement téléchargé peut signifier que l'attribut de quarantaine a été retiré. Consultez les événements de quarantaine.
• Surveillez les chemins Library/LaunchAgents et Library/LaunchDaemons pour repérer une persistance éphémère ; voir LaunchAgents et LaunchDaemons.
• Un fichier no_log ou un fseventsd-uuid récent peut relever d'une manœuvre anti-forensique délibérée, ou simplement d'un volume formaté ailleurs. Vérifiez les Unified Logs et les horodatages APFS de ces fichiers.
• Sur le volume Data interne, de nouveaux chemins Volumes/<name> montrent qu'un volume a été monté. Croisez avec le .fseventsd propre au disque et les traces de périphériques USB.
• Coalescence : un même enregistrement peut combiner Created;Modified;Removed. L'ordre exact au sein d'un enregistrement est irrécupérable.
• La sortie analysée dépasse facilement le million de lignes. Filtrez d'abord par chemin (Users/*/Downloads, private/tmp, Users/Shared, Library/LaunchAgents), puis élargissez.
• Dédupliquez avant de rédiger le rapport : FSEventsParser ne déduplique pas, et des fichiers gzip récupérés par carving peuvent répéter des enregistrements.