Analyse forensique FSEvents : ce que prouve .fseventsd
Ce qu'enregistre le journal FSEvents de macOS, où se trouve .fseventsd, ce qu'il prouve ou non, et comment le lire sans horodatage exact.
En bref. FSEvents est un historique, au niveau des chemins, de chaque volume macOS : quels fichiers et dossiers ont été créés, modifiés, renommés ou supprimés, et dans quel ordre. Il ne contient ni horodatage, ni utilisateur, ni processus, mais il garde souvent la trace de fichiers disparus depuis longtemps. Collectez l'intégralité du dossier .fseventsd en préservant les dates de modification de ses fichiers, puis lisez-le avec un parseur qui laisse l'incertitude temporelle visible, comme le FSEvents Parser de ce site.
Ce qu'écrit fseventsd
Le démon fseventsd existe pour que Time Machine, Spotlight et les clients de synchronisation puissent demander « qu'est-ce qui a changé sous ce dossier depuis le point X ? » sans rescanner le disque. Pour répondre même après un redémarrage, il tient un journal persistant sur chaque volume inscriptible qu'il suit, dans un dossier caché à la racine du volume :
| macOS | Dossier |
|---|---|
| 10.15 Catalina et versions ultérieures | /System/Volumes/Data/.fseventsd/ (le volume Data) |
| 10.14 et versions antérieures | /.fseventsd/ |
| Disques externes | /Volumes/<name>/.fseventsd/ |
Le dossier contient des fichiers journaux compressés en gzip, nommés par 16 chiffres hexadécimaux, un fichier fseventsd-uuid qui identifie le flux d'événements et, parfois, un marqueur no_log. Chaque journal contient une ou plusieurs pages d'enregistrements. Un enregistrement se compose :
- d'un chemin, relatif à la racine du volume (
Users/dana/Downloads/tools.zip) ; - d'un identifiant d'événement sur 64 bits, issu d'un compteur global au système qui ne fait qu'augmenter ;
- d'un ensemble de flags sur 32 bits : ce qui s'est passé (création, suppression, renommage, modification, attribut étendu modifié…) et sur quel type d'objet (fichier, dossier, lien symbolique, lien physique) ;
- depuis macOS 10.13, d'un node ID ; depuis macOS 14, de quatre octets supplémentaires dont Apple n'a pas documenté la signification.
La structure octet par octet est détaillée dans l'article sur le format de fichier FSEvents.
Ce qu'il prouve
- L'existence. Si un chemin apparaît dans un enregistrement, un élément portant ce nom a existé à cet emplacement sur ce volume, même s'il a été supprimé depuis.
- Le type de modification. Création, modification, renommage ou déplacement, suppression, changement de permissions, ajout ou retrait d'un attribut étendu, modification des informations Finder, clonage.
- L'ordre. Les identifiants d'événement croissent de façon monotone : on peut donc ordonner les enregistrements avec confiance, y compris entre plusieurs volumes d'un même Mac.
- L'usage de supports amovibles. Le volume Data journalise le montage et le démontage de
Volumes/<name>; le propre.fseventsddu disque journalise ce qui y a été écrit.
Ce qu'il ne prouve pas
- Le moment exact. Aucun enregistrement ne contient d'horodatage. Voir dater les enregistrements FSEvents.
- Qui ou quoi. Aucun utilisateur ni processus n'est enregistré. FSEventsParser décode le champ supplémentaire du format 3SLD comme un identifiant d'utilisateur ; considérez cette interprétation comme non confirmée.
- Chaque étape. Les modifications rapprochées d'un même chemin sont fusionnées en un seul enregistrement :
Created;Modified;Removedsur une même ligne ne vous dit pas dans quel ordre elles ont eu lieu. - Le contenu. Seuls les noms sont conservés. Combinez avec les instantanés APFS, Time Machine ou le carving pour récupérer les données.
- Les partages réseau et volumes en lecture seule. Ils ne sont pas journalisés.
Là où il fait la différence
- Persistance. Un plist de LaunchAgent créé dans
~/Library/LaunchAgents, même s'il a été supprimé ensuite. - Préparation et nettoyage. Des dizaines de documents apparaissant dans un dossier caché, puis supprimés d'un seul coup.
- Téléchargements. Une archive restée dix minutes dans
Downloads, avec l'ajout d'un attribut de quarantaine, puis le retrait d'un attribut sur son contenu extrait. - Autorisations de confidentialité. Des écritures dans la base TCC au moment où Terminal a obtenu l'Accès complet au disque (Full Disk Access).
- Exfiltration par USB. Un montage de
Volumes/EXFILsur le Mac et, sur la clé elle-même, la liste des fichiers écrits.
L'exemple d'exfiltration commenté illustre ces cinq cas dans une investigation fictive.
Bien le lire
- Filtrez d'abord par chemin. Un Mac actif produit des centaines de milliers d'enregistrements par jour. Commencez par
Users/*/Downloads,Library/LaunchAgents,Users/Shared,private/tmpetVolumes/, puis élargissez. - Suivez les node IDs à travers les renommages. Un renommage correspond à deux enregistrements (ancien et nouveau chemin) qui partagent un node ID en 2SLD et 3SLD.
- Conservez l'incertitude. Écrivez « entre 10:09:55 et 10:23:18 UTC », pas « à 10:23:18 ».
- Corrélez. Les événements de quarantaine, les Unified Logs, les horodatages APFS et la référence des flags permettent d'affiner le récit.
- Collectez correctement. Les dates de modification sont votre seule horloge : voir comment collecter .fseventsd.
FAQ
Qu'est-ce que FSEvents en analyse forensique macOS ?
Un journal persistant des modifications du système de fichiers, écrit par le démon fseventsd dans un dossier caché .fseventsd sur chaque volume. Chaque enregistrement contient un chemin, un identifiant d'événement et des flags tels que Created, Removed ou Renamed.
FSEvents enregistre-t-il les fichiers supprimés ?
Oui. Une suppression est journalisée sous forme d'enregistrement portant le flag Removed et le chemin complet : FSEvents conserve donc souvent le nom et l'emplacement de fichiers qui n'existent plus.
FSEvents contient-il des horodatages ?
Non. Les enregistrements ne portent qu'un identifiant d'événement. L'heure est estimée à partir des dates de modification des fichiers journaux, ce qui donne une fenêtre plutôt qu'un instant précis.