Enquêter sur l'abus des autorisations TCC sous macOS

En bref. Sur macOS, les attaquants ont besoin d'autorisations TCC pour l'essentiel de ce qu'ils veulent faire : l'accès complet au disque pour lire les données de l'utilisateur, l'Accessibilité, l'enregistrement de l'écran et la surveillance de l'entrée pour observer et piloter la session, et l'Automatisation du Finder ou de System Events pour agir à la place de l'utilisateur. Chaque voie laisse une ligne caractéristique dans TCC.db : quel client, quel service, comment la décision a été prise, et quand. Cet article fait correspondre les techniques courantes à ce que vous trouverez, et aux artefacts vers lesquels pivoter ensuite. Les exemples proviennent de l'échantillon fictif FIN-MBP-03 de TCC Parser.

Gardez du recul : presque toutes les lignes décrites ci-dessous se rencontrent aussi sur des Mac sains. Un constat est une question à résoudre, pas une réponse.

Les techniques et leurs traces

« Base système » et « base utilisateur » indiquent où ces services se trouvent en général ; la répartition a évolué d'une version à l'autre, donc interrogez les deux.

Accès complet au disque pour les terminaux et interpréteurs

Le chemin le plus court vers les données de l'utilisateur consiste à obtenir l'accès complet au disque pour quelque chose qui exécute des commandes arbitraires. Les autorisations sont généralement attribuées à l'app responsable : une autorisation accordée à Terminal couvre donc chaque script, binaire et commande en une ligne lancés depuis celui-ci. Cherchez l'accès complet au disque détenu par com.apple.Terminal, des terminaux tiers ou des interpréteurs identifiés par chemin, et lisez auth_reason : une raison liée à l'utilisateur (couramment 2 consentement de l'utilisateur ou 3 défini par l'utilisateur) signifie que quelqu'un a cliqué.

Dans l'échantillon, l'accès complet au disque a été accordé à com.apple.Terminal à 10:11:37 UTC, six minutes après le début de la fenêtre d'intrusion.

Accessibilité, enregistrement de l'écran, surveillance de l'entrée

Ce sont les services de surveillance et de contrôle. L'Accessibilité permet à un programme de cliquer et de taper dans d'autres apps, y compris pour valider des boîtes de dialogue ; l'enregistrement de l'écran voit l'écran ; la surveillance de l'entrée observe les frappes ; Post Event injecte des saisies. Les malwares les demandent en général depuis un binaire auxiliaire, parfois après avoir amené l'utilisateur à valider une invite convaincante.

Une ligne refusée est aussi une preuve. Dans l'échantillon, l'utilitaire /Users/dana.whitlock/Library/Caches/.sync/sync-helper a obtenu l'Accessibilité à 10:19:05 et s'est vu refuser l'enregistrement de l'écran à 10:24:40. Le refus montre que la demande a eu lieu, même si elle a échoué.

Sous Sequoia et ultérieur, vérifiez ~/Library/Group Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist : des dates de rappel très lointaines indiquent que quelqu'un a supprimé le rappel périodique de l'enregistrement de l'écran.

Automatisation du Finder, de System Events et de Terminal

L'automatisation Apple Events permet à une app d'envoyer des commandes à une autre. Contrôler le Finder, c'est copier et déplacer des fichiers en tant qu'utilisateur ; contrôler System Events, c'est scripter l'interface et des actions système ; contrôler Terminal, c'est exécuter des commandes via une app qui détient peut-être l'accès complet au disque. Ces lignes se trouvent dans la base utilisateur, avec la cible dans indirect_object_identifier et son exigence de code dans indirect_object_code_identity.

Dans l'échantillon, Terminal a été autorisé à contrôler System Events à 10:14:02 et le Finder à 10:16:48, les deux dans la base de dana.whitlock.

Clients identifiés par chemin et signés ad hoc

Les apps légitimes sont presque toujours enregistrées par bundle ID, avec une exigence liée à Apple ou à un Team ID. Un client enregistré par chemin absolu (client_type 1) dans un dossier temporaire, partagé ou caché, avec un csreq réduit à un cdhash, est un petit programme non signé ou signé ad hoc que quelqu'un a déposé et exécuté. Cette description correspond aussi à beaucoup d'outils de développement : vérifiez donc le chemin, le fichier et la façon dont il est arrivé. Détails dans décoder les exigences de code csreq dans TCC.db.

Préparation des données : dossiers et volumes amovibles

Des autorisations sur Documents, Bureau, Téléchargements et les volumes amovibles accordées à un terminal ou à un utilitaire, à quelques minutes d'intervalle, esquissent la phase de collecte. Dans l'échantillon : Documents et Bureau pour Terminal vers 10:18, Téléchargements pour le sync-helper à 10:21:44, et volumes amovibles pour Terminal à 10:38:55, que le scénario relie à un volume USB nommé « EXFIL ».

Nettoyage avec tccutil

Un intrus qui connaît TCC peut supprimer des autorisations en partant avec tccutil reset. La ligne disparaît de la base, mais des copies antérieures de sa page peuvent subsister dans TCC.db-wal ou dans des pages libérées. Dans l'échantillon, l'autorisation Accessibilité de l'utilitaire a disparu de l'état courant et est récupérée depuis le WAL ; le scénario situe la suppression à 10:47:12 UTC. Voir récupérer des autorisations TCC supprimées dans le WAL.

Modifications directes de TCC.db

La protection de l'intégrité du système (SIP) empêche la modification de la base système, même par root. Avec SIP désactivé, un processus root peut y écrire directement. La base utilisateur est protégée par TCC plutôt que par SIP, et des recherches publiques ont montré par le passé des moyens de l'altérer. Signes à vérifier, avec prudence : des lignes dont le last_modified n'a pas d'activité com.apple.TCC correspondante dans le journal unifié, des codes de raison qui ne correspondent pas à la manière dont l'autorisation aurait dû être accordée, et des exigences de code absentes ou étranges. Consignez l'état de SIP du Mac (via csrutil status sur un système allumé, ou via votre outil de triage) dans les notes du dossier.

MDM et PPPC

Un profil PPPC malveillant ou inattendu peut pré-autoriser de nombreux services sans invite. Il ne peut pas accorder silencieusement la caméra, le micro ou l'enregistrement de l'écran. Les lignes dont l'auth_reason est couramment interprété comme politique MDM (6), qui portent un policy_id ou qui ont une entrée dans MDMOverrides.plist doivent correspondre à un profil que votre équipe MDM reconnaît. Dans l'échantillon, com.example.edr.agent détient l'accès complet au disque via un profil PPPC, ce qui est attendu pour un agent EDR.

Construire la chronologie

Classez les lignes dans l'ordre et regardez les trous et les rafales. L'échantillon, en UTC, le 2026-09-14 :

Dans TCC Parser, Findings (constats) signale une rafale de modifications d'autorisations de 10:11:37 à 10:24:40, suivie d'un intervalle de 14 minutes avant 10:38:55. Une plage de temps de 10:05 à 10:50 (le bouton Use the sample's incident window de l'onglet Findings) restreint chaque onglet à l'intrusion.

Où pivoter ensuite

TCC.db indique ce qui était possible. D'autres artefacts indiquent ce qui s'est passé :

Dans le scénario de l'échantillon, ces pivots mettent au jour un téléchargement mis en quarantaine, tools.zip, provenant de https://files.example/…, un faux LaunchAgent com.example.updater.plist, des fichiers préparés dans ~/Library/Caches/.sync/ et une visite sur transfer.example. Rien de tout cela ne figure dans TCC.db ; c'est ce vers quoi les lignes TCC vous orientent.

Une requête de départ pour le journal unifié, sur une archive de journaux collectée ou sur un système allumé :

log show --info --predicate 'subsystem == "com.apple.TCC"' \
  --start "2026-09-14 10:00:00" --end "2026-09-14 11:00:00"

Les formats de message varient selon la version et certaines valeurs peuvent être masquées sous la forme <private>. La rétention est limitée : collectez les journaux tôt.

Rédiger le rapport

• Énoncez des capacités, pas des actions : « Terminal détenait l'accès complet au disque depuis 10:11:37 UTC », puis citez l'artefact qui en montre l'utilisation.
• Citez la base et le compte pour chaque ligne, et précisez quand une ligne a été récupérée dans le WAL.
• Présentez les interprétations d'auth_reason avec prudence, comme documentées par la communauté.
• Notez vos propres autorisations accordées pendant la collecte pour qu'elles ne soient pas prises pour une activité de l'attaquant.

Questions fréquentes

L'accès complet au disque accordé à Terminal est-il un signe de compromission ?

Pas en soi. Développeurs et administrateurs l'accordent couramment. Il devient significatif lorsque l'heure de l'autorisation coïncide avec d'autres activités suspectes, lorsque le rôle de l'utilisateur ne le justifie pas, ou lorsqu'il est suivi d'autorisations d'Automatisation, d'accès aux dossiers ou aux volumes amovibles pour la même app.

Un malware peut-il s'accorder lui-même des autorisations TCC ?

Normalement, il faut une invite validée par l'utilisateur, une politique MDM ou une décision du système. Pour y parvenir, les techniques consistent notamment à pousser l'utilisateur à valider une invite, à emprunter les autorisations d'une app qui les possède déjà, ou à modifier directement la base lorsque les protections le permettent, par exemple la base système quand SIP est désactivé.

Où trouver la preuve qu'une autorisation a été utilisée ?

Pas dans TCC.db, qui ne stocke que des décisions. Consultez le journal unifié (sous-système com.apple.TCC pour les requêtes), les traces d'exécution de processus, l'historique du shell, les horodatages du système de fichiers et la télémétrie EDR.

Comment distinguer une autorisation accordée par le MDM d'une autorisation accordée par l'utilisateur ?

Vérifiez auth_reason (6 est couramment interprété comme politique MDM), policy_id et la table policies, ainsi que MDMOverrides.plist. Confirmez avec les profils de configuration installés. Un profil PPPC que vous ne savez pas expliquer est un constat.

Articles liés

• Analyse forensique de TCC.db : le guide de l'enquêteur
• Comment analyser TCC.db dans votre navigateur
• Récupérer des autorisations TCC supprimées dans TCC.db-wal