Analyse forensique de TCC.db : le guide de l'enquêteur

En bref. Transparency, Consent and Control (TCC) est le framework macOS qui décide si un programme peut utiliser la caméra, le micro, l'écran, les périphériques d'entrée, les API d'accessibilité, les dossiers protégés, l'ensemble du disque ou d'autres apps via les Apple Events. Le démon tccd enregistre chaque décision sous la forme d'une ligne dans une base SQLite, TCC.db : une pour le système et une par utilisateur. Chaque ligne indique quel client, quel service, autorisé ou refusé, pour quelle raison, et quand la ligne a changé pour la dernière fois. C'est un registre d'autorisations, pas un journal d'utilisation. TCC Parser décode ces bases dans votre navigateur, y compris les versions antérieures des lignes restées dans le fichier WAL ; rien n'est envoyé.

Ce guide est le point d'entrée de la série. Chaque section renvoie vers un article plus détaillé.

Ce qu'est TCC et pourquoi il intéresse les enquêteurs

La plupart des actions intéressantes qu'un logiciel malveillant ou un intrus veut mener sur un Mac touchent une ressource protégée par TCC : lire Mail, Messages ou les données du navigateur (il faut l'accès complet au disque, ou Full Disk Access), observer l'écran (enregistrement de l'écran), capturer les frappes (surveillance de l'entrée), cliquer à travers les boîtes de dialogue (Accessibilité), ou piloter le Finder et System Events pour agir à la place de l'utilisateur (automatisation Apple Events). Quand un programme demande l'une de ces capacités, tccd affiche une invite à l'utilisateur, applique une politique ou refuse, puis enregistre le résultat.

TCC.db fait donc partie des endroits où l'intention devient visible. Un utilitaire identifié par son chemin, logé dans un dossier de cache caché, qui demande l'Accessibilité, ou Terminal qui obtient l'accès complet au disque quelques minutes après un téléchargement suspect : c'est le genre de chose que la base capture bien.

Ce qu'une ligne peut prouver, et ce qu'elle ne peut pas prouver

Une ligne peut montrer	Une ligne ne peut pas montrer
Qu'un client (bundle ID ou chemin absolu) détient un service, ou s'est vu le refuser	Que la capacité a réellement été utilisée, ni à quelle fréquence
Si la décision est autorisée, refusée, inconnue ou limitée (auth_value)	Ce qui a été capturé, lu ou tapé
Un code de raison pour la décision (auth_reason, documenté par la communauté)	Qui se trouvait physiquement au clavier
L'exigence de signature de code que le client doit satisfaire (csreq)	Que le binaire présent aujourd'hui sur le disque est celui qui a été approuvé
Pour l'Automatisation, quelle app est contrôlée	Chaque état antérieur de la ligne (seulement le dernier, sauf si le WAL en conserve davantage)
Quand la ligne a changé pour la dernière fois (`last_modified`, secondes Unix UTC)	Quand l'autorisation a été accordée pour la première fois, si la ligne a changé depuis

Deux conséquences structurent chaque rapport. D'abord, une autorisation est une capacité, pas une activité : écrivez « détenait l'accès complet au disque depuis 10:11:37 UTC », et non « a lu la messagerie de l'utilisateur ». Ensuite, l'absence est une preuve faible : des lignes sont supprimées par tccutil reset, par les réinitialisations dans les Réglages Système et lors de la suppression d'apps. Voir récupérer des autorisations TCC supprimées dans le WAL.

Où se trouvent les bases

Base	Chemin	Contenu habituel
Système	`/Library/Application Support/com.apple.TCC/TCC.db`	Accès complet au disque, Accessibilité, enregistrement de l'écran, surveillance de l'entrée, outils de développement, clients Endpoint Security
Par utilisateur	`~/Library/Application Support/com.apple.TCC/TCC.db`	Caméra, micro, contacts, calendriers, photos, Automatisation, Bureau/Documents/Téléchargements, volumes amovibles et réseau
Autorisations MDM	`/Library/Application Support/com.apple.TCC/MDMOverrides.plist`	Autorisations PPPC poussées par un serveur de gestion

La colonne « Contenu habituel » est indicative : la répartition se fait par service et a évolué d'une version à l'autre, donc interrogez toujours chaque copie. Lire l'un de ces fichiers sur un Mac allumé exige que le processus qui effectue la copie dispose de l'accès complet au disque, et la protection de l'intégrité du système (SIP) protège en plus la base système contre toute modification, même par root. Les fichiers compagnons TCC.db-wal et TCC.db-shm comptent aussi. Détails de collecte et pièges des outils : TCC.db sous macOS : emplacement et acquisition.

Lire une ligne

La table qui compte est access. Sous Big Sur et ultérieur, les colonnes que vous utiliserez le plus sont :

Colonne	Ce qu'il faut y lire
`service`	Le service TCC, par exemple `kTCCServiceSystemPolicyAllFiles`
`client`	Bundle ID ou chemin absolu du programme
`client_type`	`0` bundle ID, `1` chemin absolu (client_type)
`auth_value`	`0` refusé, `1` inconnu, `2` autorisé, `3` limité
`auth_reason`	La raison (consentement de l'utilisateur, défini par l'utilisateur, politique MDM, etc. ; documenté par la communauté)
`csreq`	Exigence de code compilée qui identifie le client
`indirect_object_identifier`	Pour l'Automatisation : l'app contrôlée
`last_modified`	Secondes d'époque Unix, UTC

Mojave et Catalina utilisaient allowed et prompt_count au lieu de auth_value et auth_reason ; Sonoma a ajouté pid, pid_version, boot_uuid et last_reminded. Vérifiez toujours .schema access sur votre copie. L'évolution complète, et les tables plus petites autour d'access, sont décrites dans la table access de TCC selon les versions de macOS.

Les services qui comptent le plus

Identifiant de service	Nom dans les Réglages Système	Pourquoi c'est important
`kTCCServiceSystemPolicyAllFiles`	Accès complet au disque	Lit les données utilisateur protégées : Mail, Messages, Safari, les autres fichiers TCC.db
`kTCCServiceAccessibility`	Accessibilité	Pilote l'interface : clics, frappes, validation de boîtes de dialogue
`kTCCServiceScreenCapture`	Enregistrement de l'écran	Voit tout ce qui s'affiche à l'écran
`kTCCServiceListenEvent`	Surveillance de l'entrée	Observe les événements clavier et souris
`kTCCServicePostEvent`	(entrée synthétique)	Injecte des événements d'entrée
`kTCCServiceAppleEvents`	Automatisation	Contrôle une autre app ; cible dans `indirect_object_identifier`
`kTCCServiceSystemPolicyDocumentsFolder` et services voisins	Fichiers et dossiers	Bureau, Documents, Téléchargements
`kTCCServiceSystemPolicyRemovableVolumes`	Volumes amovibles	Clés USB et supports similaires
`kTCCServiceEndpointSecurityClient`	(Endpoint Security)	Agents de sécurité ; un nouveau venu mérite un examen

Qui a décidé : l'utilisateur, le système ou le MDM

auth_reason permet de distinguer un clic de l'utilisateur d'une politique. Parmi les valeurs couramment citées : 2 consentement de l'utilisateur (réponse à une invite), 3 défini par l'utilisateur (interrupteur basculé dans les Réglages Système), 4 défini par le système et 6 politique MDM. Apple ne documente pas ces entiers ; traitez-les comme des hypothèses et confirmez-les sur un Mac de test de la même version ou dans le journal unifié avant de vous appuyer dessus.

Sur les Mac gérés, les autorisations poussées par un profil Privacy Preferences Policy Control (PPPC) apparaissent dans MDMOverrides.plist, et des lignes peuvent référencer la table policies via policy_id. Un agent EDR légitime qui détient l'accès complet au disque via le MDM, c'est normal. Un profil PPPC inattendu est en soi un constat.

Une méthode reproductible

Collectez l'intégralité du dossier com.apple.TCC pour le système et pour chaque utilisateur, avec -wal et -shm, depuis un processus qui détient l'accès complet au disque (ou depuis une image montée). Calculez l'empreinte de ce que vous avez collecté.
Vérifiez le schéma de chaque base avant de l'interroger : les jeux de colonnes diffèrent selon la version.
Passez en revue les autorisations à fort impact : accès complet au disque, Accessibilité, enregistrement de l'écran, surveillance de l'entrée, Post Event, outils de développement, Endpoint Security. Demandez-vous qui les détient et si cela correspond au rôle de l'utilisateur.
Examinez les clients identifiés par chemin (client_type = 1) et les clients situés dans des dossiers temporaires, partagés ou cachés. Les apps légitimes sont presque toujours des bundle ID.
Décodez csreq. Une exigence réduite à un cdhash épingle un build précis, ce qui est typique du code signé ad hoc. Voir décoder les exigences de code csreq dans TCC.db.
Lisez les lignes d'Automatisation dans chaque base utilisateur : quelle app peut contrôler le Finder, System Events ou Terminal.
Récupérez l'historique depuis TCC.db-wal et les pages libérées : autorisations supprimées et modifiées.
Construisez une chronologie à partir de last_modified et corrélez-la avec le journal unifié (subsystem == "com.apple.TCC"), les événements de quarantaine, les tâches launchd et l'historique du shell.

L'article enquêter sur l'abus des autorisations TCC déroule cette méthode sur une intrusion réaliste et fictive.

Outils

sqlite3 sur une copie, avec vos propres requêtes. Suffisant pour des vérifications ponctuelles ; le décodage des blobs et des codes de raison reste à votre charge.
Plugin TCC de mac_apt : prend en charge les structures de Catalina et de Big Sur et ultérieur, depuis une image ou en mode artefact seul.
Plugin macostcc de Plaso : attend les colonnes allowed/prompt_count d'avant Big Sur, il vise donc les bases de Mojave et Catalina.
Velociraptor MacOS.System.TCC : requêtes en live sur l'ensemble d'un parc.
TCC Parser : déposez le dossier ou un ZIP de triage dans le navigateur ; il décode toutes les versions du schéma, les exigences de code et les codes de raison, signale les lignes notables, récupère l'historique du WAL et exporte en CSV, CSV Timesketch et JSON. La prise en main pas à pas se trouve dans comment analyser TCC.db dans votre navigateur.

Apple et macOS sont des marques d'Apple Inc. TCC Parser est un outil indépendant, ni affilié à Apple ni approuvé par Apple.

Pièges

Collecte incomplète. Sans l'accès complet au disque, la copie échoue ou revient vide. Une TCC.db absente d'un paquet de triage relève en général d'un problème de collecte.
Oublier le WAL. Plusieurs collecteurs ne copient que TCC.db. Des modifications récentes peuvent encore se trouver dans TCC.db-wal.
Processus responsable. Les autorisations sont souvent attribuées à l'app qui a lancé un outil (Terminal) plutôt qu'au script qui les a utilisées. Une autorisation accordée à Terminal couvre tout ce qui y est exécuté.
Bundle ID ou binaire. Une ligne par bundle ID s'applique à tout code qui satisfait l'exigence enregistrée. Comparez l'exigence avec le binaire présent sur le disque.
Surinterpréter les codes de raison. Les significations d'auth_reason sont documentées par la communauté, pas officielles.

Questions fréquentes

TCC.db montre-t-elle chaque utilisation de la caméra ou chaque lecture de mes fichiers par une app ?

Non. TCC.db stocke des décisions permanentes : quel client a été autorisé ou refusé pour quel service, et quand cette décision a changé pour la dernière fois. Les utilisations individuelles n'y sont pas enregistrées. Les traces requête par requête se trouvent dans le journal unifié, sous le sous-système com.apple.TCC, et l'historique d'utilisation dans d'autres artefacts.

Une ligne absente prouve-t-elle qu'une autorisation n'a jamais été accordée ?

Non. tccutil reset, une réinitialisation dans les Réglages Système ou la suppression de l'app effacent des lignes. Des versions antérieures d'une ligne peuvent survivre un temps dans TCC.db-wal ou dans des pages libérées, et des copies plus anciennes de la base peuvent exister dans des snapshots APFS ou des sauvegardes Time Machine.

Quelle base TCC faut-il examiner, celle du système ou celle de l'utilisateur ?

Les deux, à chaque fois. Les services à fort impact comme l'accès complet au disque, l'Accessibilité et l'enregistrement de l'écran se trouvent en général dans la base système, tandis que la caméra, le micro, l'Automatisation et l'accès aux dossiers se trouvent en général dans la base de chaque utilisateur. La répartition se fait par service et a évolué d'une version à l'autre : interrogez toutes les copies.

Dans quel fuseau horaire est exprimé last_modified ?

last_modified est en secondes d'époque Unix, donc en UTC. Ce n'est pas du temps absolu Mac. Il en va de même pour last_reminded (Sonoma et ultérieur) et pour expired_at dans la table expired.