Journaux unifiés macOS en forensique : guide pratique

En bref. Les journaux unifiés constituent la chronologie la plus détaillée qu'un Mac conserve : authentification, sudo, décisions de confidentialité (TCC), Gatekeeper, agents de lancement, accès à distance et montages de disques, chaque entrée avec un processus, un subsystem et un horodatage à la microseconde. Le hic : une entrée est répartie entre trois types de fichiers — .tracev3, uuidtext/dsc et timesync — et il vous les faut tous. Ce guide explique ce qui se trouve où et comment l'exploiter ; Unified Log Parser lit l'ensemble directement dans votre navigateur.

Qu'est-ce que la journalisation unifiée ?

Depuis macOS 10.12 Sierra, Apple fait passer la quasi-totalité de la journalisation par un seul système. Le noyau, les démons d'Apple et tout code tiers appelant os_log envoient leurs entrées à logd, qui les écrit dans des fichiers binaires compressés. Les fichiers texte de type syslog sous /var/log existent toujours, mais l'essentiel de ce qui compte dans une investigation se trouve dans le magasin unifié.

Chaque entrée comporte :

• l'heure, à la microseconde une fois convertie ;
• le processus (chemin de l'image et PID), le thread et l'identifiant utilisateur ;
• l'image émettrice : la bibliothèque ou le framework qui a journalisé (souvent différent du processus lui-même) ;
• un subsystem et une catégorie en notation DNS inversée, par exemple com.apple.TCC / access ;
• un type : Default, Info, Debug, Error ou Fault pour les messages, ainsi que les activités, signposts et state dumps ;
• le message, restitué à partir d'une chaîne de format et des valeurs enregistrées avec l'entrée.

Où se trouvent les fichiers

Une .logarchive produite par log collect ou sysdiagnose contient les mêmes dossiers, plus logdata.LiveData.tracev3, le tampon en mémoire au moment de la collecte. L'article sur le format tracev3 détaille la structure binaire.

Pourquoi il faut toujours trois types de fichiers

Une entrée .tracev3 ne stocke pas son texte. Elle stocke une référence vers une chaîne de format (un décalage dans un fichier uuidtext ou dans le fichier dsc du cache partagé) ainsi que les valeurs brutes des arguments. Sans les fichiers de chaînes, un parseur ne peut afficher que des nombres et des fragments : les entrées sont « non résolues ». Les heures sont stockées en Mach continuous time relatif au démarrage, puis converties en heure réelle grâce aux enregistrements timesync ; sans eux, les heures sont au mieux approximatives.

La règle de collecte est donc simple : prenez diagnostics et uuidtext, ou une .logarchive, qui contient les deux.

Ce que les journaux unifiés peuvent prouver

• Authentification et élévation de privilèges : commandes sudo avec l'utilisateur cible et la ligne de commande complète, mots de passe erronés, su, droits d'autorisation accordés par authd, modifications de comptes locaux.
• Accès à distance : sessions SSH (sshd, sshd-session) et Partage d'écran, avec l'adresse distante lorsqu'elle est journalisée.
• Décisions de confidentialité : demandes TCC et leurs résultats — par exemple l'accès complet au disque accordé à Terminal — sous le subsystem com.apple.TCC.
• Contexte d'exécution : évaluations et contournements Gatekeeper par syspolicyd, activité de XProtect et XProtect Remediator, attributs de quarantaine, lancements d'applications par LaunchServices.
• Persistance : chargement d'agents et de démons de lancement, enregistrement d'éléments de connexion par Background Task Management.
• Périphériques : volumes montés et éjectés par diskarbitrationd, connexion de périphériques USB.

L'article sur les requêtes de triage propose des recherches concrètes pour chacun de ces points.

Ce qu'ils ne peuvent pas prouver

• L'absence. Une entrée manquante peut signifier que le magasin a tourné, que le niveau n'a jamais été persisté (la plupart des entrées Info et Debug ne vivent qu'en mémoire), que la valeur a été masquée ou qu'Apple a changé le libellé dans cette version.
• Les valeurs masquées. <private> signifie que la valeur a été cachée au moment de la journalisation. Aucun parseur ne peut la retrouver ; la chaîne de format indique néanmoins de quel type d'événement il s'agissait.
• Un libellé exact d'une version à l'autre. Les messages ne sont pas une API. Une recherche mise au point sur une version de macOS peut manquer des événements sur une autre : privilégiez les filtres par subsystem, catégorie et processus, et lisez le contexte de chaque résultat.

Une méthode qui tient la route

1. Collectez tôt, avec uuidtext et timesync, et calculez l'empreinte de ce que vous avez collecté.
2. Documentez la couverture : première et dernière entrée de chaque session de démarrage, ainsi que les éventuels trous, avant d'affirmer qu'« il ne s'est rien passé ».
3. Resserrez sur le temps autour d'événements connus (un téléchargement malveillant, une connexion), puis élargissez.
4. Filtrez par processus et par subsystem plutôt que sur le seul texte des messages.
5. Lisez autour de chaque résultat : les entrées du même PID quelques secondes avant et après l'expliquent généralement.
6. Confirmez les entrées clés avec log show sur un Mac pour tout ce qui figure dans un rapport, et notez le parseur et la version utilisés.

Tout faire dans le navigateur

Unified Log Parser décode les fichiers tracev3 d'une .logarchive, d'une copie de l'arborescence /private/var/db ou d'une collecte UAC / Velociraptor, et ouvre aussi les exports de log show. Il offre une plage temporelle avec une bande de densité, des filtres par type, processus, subsystem et PID, des préréglages DFIR sélectionnés, et des exports CSV, NDJSON et Timesketch. Tout s'exécute localement grâce à WebAssembly ; le tutoriel pas à pas utilise l'échantillon synthétique FIN-MBP-03.

Pour aller plus loin : le projet macos-UnifiedLogs de Mandiant et les notes libyal sur le format Apple Unified Logging documentent les formats en profondeur.