TCC-Manipulation unter macOS erkennen

TCC ist die Schutzschicht, die unter macOS den Zugriff auf private Daten und Geräte an die ausdrückliche Zustimmung des Nutzers bindet - die Dialoge, die fragen, ob eine App auf die Festplatte, die Kamera oder das Mikrofon zugreifen darf. Für Angreifer ist das eine Hürde, und es gibt mehrere Wege, sie zu umgehen. Dieser Beitrag bleibt auf der Erkennungsseite und ist zugleich der ehrlichste der Reihe: Ein guter Teil der TCC-Umgehung hinterlässt kein sauberes Signal. Er setzt die Grundlagen aus macOS-Sicherheitsmonitoring voraus. Der Anker ist der Prozessaufruf und das Schreiben in die TCC-Datenbank.

Was der Angreifer tut

TCC speichert die erteilten Zustimmungen in einer Datenbank (TCC.db). Die Umgehung setzt entweder an dieser Datenbank an oder am Zustimmungsweg selbst. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Direkt in die TCC.db schreiben. Wer einen Eintrag in die Datenbank schreibt, erteilt sich eine Berechtigung, ohne dass je ein Dialog erschien. Die Benutzer-Datenbank liegt unter ~/Library/Application Support/com.apple.TCC; die systemweite ist durch SIP geschützt und lässt sich nur mit Vollzugriff auf die Festplatte oder bei abgeschaltetem SIP beschreiben.
• tccutil zum Zurücksetzen nutzen. Mit tccutil reset lässt sich der Zustimmungszustand einer App löschen - um einen neuen Dialog zu erzwingen, den ein getäuschter Nutzer bestätigt, oder um Spuren zu verwischen.
• Den Nutzer zur Zustimmung verleiten. Der leiseste Weg ist gar keine Manipulation, sondern Social Engineering: Der Nutzer klickt im echten Dialog auf Erlauben. Dann schreibt tccd einen völlig regulären Eintrag - nicht von einer legitimen Zustimmung zu unterscheiden.
• Eine bereits berechtigte App missbrauchen. Hat eine installierte App schon Vollzugriff auf die Festplatte, kann ein Angreifer über sie zugreifen, ohne selbst eine Berechtigung zu brauchen - ganz ohne TCC.db-Änderung.

Für die Erkennung heißt das: Die ersten beiden Wege laufen über einen Prozess oder einen Schreibzugriff und sind sichtbar. Die letzten beiden sind der ehrliche Blindspot, auf den dieser Beitrag unten gesondert eingeht.

Welche Telemetrie die Technik zeigt

• Endpoint Security Framework (ESF). Die tragende Echtzeit-Quelle über eslogger, Red Canary Mac Monitor oder EDR. Belastbar sind das Prozessereignis von tccutil und sqlite3 mit Argumenten sowie das Dateiereignis, das zeigt, wenn ein anderer Prozess als tccd die TCC.db ändert - genau darauf setzen die drei Regeln.
• Unified Log. Die TCC-Entscheidungen laufen über tccd; das Unified Log (com.apple.TCC) hält fest, welche App wann welchen Zugriff angefragt und erhalten hat. Das ist für die forensische Rekonstruktion wertvoll - gerade um einen erschlichenen Dialog nachzuvollziehen -, für die laufende Regelarbeit aber zu unspezifisch.
• Dateisystem- und Artefaktsicht. Die TCC.db selbst ist das Artefakt: Ihre Einträge zeigen, welche App welche Berechtigung hat. Ein Abgleich mit dem erwarteten Zustand findet unerwartete Grants auch nachträglich.
• OpenBSM/audit. Die ältere BSM-Audit-Spur zeigt den Prozessstart von tccutil oder sqlite3 als Rückfallebene, wenn keine ESF-Quelle vorhanden ist.

Das Muster

Das klarste Signal ist ein Schreibzugriff auf die TCC.db durch einen anderen Prozess als tccd - denn im Normalbetrieb schreibt nur tccd nach einer Zustimmung dorthin. Fast ebenso deutlich ist sqlite3 gegen die TCC.db, also der direkte Datenbankeingriff. tccutil reset ist schwächer, weil Entwickler und Admins es ebenfalls nutzen, trägt aber als Anreicherung bei, besonders kurz nach einem frischen Zugriff. Keines dieser Signale fängt die Social-Engineering-Zustimmung oder den Missbrauch einer bereits berechtigten App - diese Lücke ist bekannt und unten benannt. Belastbar wird der Fall aus dem Zusammenspiel von ungewöhnlichem Schreiber, Datenbankeingriff und dem, was die App danach tut.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und setzen auf der Prozess- und der Datei-Logquelle auf (ESF-gespeist). Die erste nimmt das Zurücksetzen, die zweite den direkten Datenbankeingriff, die dritte den ungewöhnlichen Schreiber der TCC.db.

1. TCC-Berechtigungen mit tccutil zurückgesetzt (T1548.006). Das Zurücksetzen, auf level: medium.

title: TCC-Berechtigungen mit tccutil zurueckgesetzt
id: 1fc4a31d-2b3a-4cff-97b1-594de9096f86
status: experimental
description: |
  Erkennt tccutil beim Zuruecksetzen von TCC-Berechtigungen (reset). Angreifer nutzen
  das, um den Zustimmungszustand einer App zu loeschen und einen neuen Zustimmungsdialog
  zu erzwingen oder Spuren eines erschlichenen Zugriffs zu verwischen (TCC Manipulation).
  Entwickler und Admins setzen Berechtigungen ebenfalls legitim zurueck, der Kontext
  entscheidet.
references:
  - https://attack.mitre.org/techniques/T1548/006/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.privilege-escalation
  - attack.t1548.006
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/tccutil'
  sel_cmd:
    CommandLine|contains: 'reset'
  condition: sel_img and sel_cmd
falsepositives:
  - Entwickler und Admins setzen App-Berechtigungen legitim zurueck - bekannte Faelle und Konten als Baseline ausnehmen
level: medium

2. TCC-Datenbank direkt mit sqlite3 bearbeitet (T1548.006). Der direkte Datenbankeingriff, auf level: high.

title: TCC-Datenbank direkt mit sqlite3 bearbeitet
id: d232e39f-0708-47b9-bafc-abd5a41bd03b
status: experimental
description: |
  Erkennt den Aufruf von sqlite3 gegen die TCC-Datenbank. Wer direkt in die TCC.db
  schreibt, traegt eine Berechtigung ein, ohne dass der Nutzer je zugestimmt hat, und
  umgeht so die Zustimmungskontrolle (TCC Manipulation). Die System-TCC.db ist durch SIP
  geschuetzt; ein erfolgreicher direkter Schreibzugriff setzt die Benutzer-TCC.db,
  Vollzugriff auf die Festplatte oder ein abgeschaltetes SIP voraus.
references:
  - https://attack.mitre.org/techniques/T1548/006/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.privilege-escalation
  - attack.t1548.006
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/sqlite3'
  sel_cmd:
    CommandLine|contains: 'TCC.db'
  condition: sel_img and sel_cmd
falsepositives:
  - Sehr selten in Diagnose- oder Verwaltungswerkzeugen, die TCC-Eintraege lesen - lesenden Zugriff vom schreibenden trennen und bekannte Faelle ausnehmen
level: high

3. TCC.db von einem anderen Prozess als tccd geändert (T1548.006). Der ungewöhnliche Schreiber, auf level: high.

title: TCC-Datenbank von einem anderen Prozess als tccd geaendert
id: 37e8d743-c5aa-4d45-8a2f-a5e7a53bf336
status: experimental
description: |
  Erkennt das Aendern einer TCC-Datenbankdatei durch einen anderen Prozess als den
  zustaendigen Dienst tccd. Normalerweise schreibt nur tccd nach der Zustimmung des
  Nutzers in die TCC.db; schreibt ein anderer Prozess hinein, deutet das auf eine
  direkte Manipulation der Zustimmungskontrolle (TCC Manipulation).
references:
  - https://attack.mitre.org/techniques/T1548/006/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.privilege-escalation
  - attack.t1548.006
logsource:
  product: macos
  category: file_event
detection:
  sel_file:
    TargetFilename|contains:
      - '/com.apple.TCC/'
      - 'TCC.db'
  filter_tccd:
    Image|endswith: '/tccd'
  condition: sel_file and not filter_tccd
falsepositives:
  - Backup- und Migrationswerkzeuge sowie Installer koennen die TCC-Datei beruehren - bekannte Prozesse als Baseline ausnehmen
level: high

Grenzen der Erkennung

• Die erschlichene Zustimmung ist nicht zu unterscheiden. Klickt ein getäuschter Nutzer im echten Dialog auf Erlauben, schreibt tccd einen ganz regulären Eintrag. Auf der TCC.db-Ebene sieht das aus wie jede legitime Zustimmung - Regel 3 greift bewusst nicht, weil der Schreiber tccd ist. Das ist ein Social-Engineering-Fall, kein Datei-Signal.
• Der Missbrauch berechtigter Apps erzeugt keine Änderung. Nutzt ein Angreifer eine App, die bereits Vollzugriff hat, ändert sich die TCC.db nicht. Es gibt dann kein TCC-Signal; sichtbar wird höchstens, was die App danach tut.
• SIP schützt die System-TCC.db. Die systemweite TCC.db lässt sich auf einem gesunden System nicht einfach beschreiben. Der direkte Schreibweg betrifft vor allem die Benutzer-TCC.db oder Systeme mit Vollzugriff auf die Festplatte beziehungsweise abgeschaltetem SIP - ein erfolgreicher Treffer von Regel 2 oder 3 gegen die System-DB ist zugleich ein Hinweis auf eine tieferliegende Schwächung.
• Sichtbarkeit ist produktabhängig. Ohne ESF-Quelle gibt es kein Echtzeitsignal. Die Regeln setzen Prozessstart mit Befehlszeile beziehungsweise Dateiereignisse mit schreibendem Prozess voraus.

Fehlalarme und Tuning

• tccutil reset ist dual-use. Entwickler setzen App-Berechtigungen beim Testen zurück, und auch Support-Abläufe nutzen es. Bekannte Konten und Abläufe für Regel 1 als Baseline aufnehmen.
• Lesen von TCC-Einträgen ist harmlos. Manche Diagnosewerkzeuge lesen die TCC.db mit sqlite3. Regel 2 zielt auf den schreibenden Zugriff; rein lesende Aufrufe nach Kontext ausnehmen.
• Installer und Backups. Einzelne Installer und Sicherungswerkzeuge berühren die TCC-Datei. Diese bekannten Prozesse für Regel 3 ausnehmen, damit nur der wirklich ungewöhnliche Schreiber übrig bleibt.
• Kette schlägt Einzeltreffer. Ein TCC-Eingriff, gefolgt vom Zugriff der betroffenen App auf Kamera, Mikrofon oder die Festplatte, ist weit aussagekräftiger als ein Treffer allein.

Analysten-Checkliste

1. Welcher Weg liegt vor - tccutil reset, sqlite3 gegen die TCC.db oder ein Schreibzugriff durch einen anderen Prozess als tccd?
2. Betraf es die Benutzer- oder die System-TCC.db? Ein Schreibzugriff auf die System-DB deutet auf Vollzugriff auf die Festplatte oder geschwächtes SIP.
3. Welche App beziehungsweise welcher Dienst sollte damit berechtigt werden, und passt das zu einem legitimen Bedarf?
4. Griff die betroffene App danach auf eine sensible Ressource zu (Festplatte, Kamera, Mikrofon)? Das Unified Log (com.apple.TCC) hilft hier.
5. Könnte es stattdessen eine erschlichene Zustimmung oder der Missbrauch einer bereits berechtigten App sein - also einer der Blindspots?
6. Gab es davor einen Erstzugriff oder eine Rechteausweitung, in deren Kontext die TCC-Manipulation passt?

Härtung

• SIP aktiviert lassen. System Integrity Protection schützt die systemweite TCC.db vor direktem Schreiben - der wichtigste Baustein gegen die Manipulation der System-Datenbank.
• TCC-Berechtigungen per MDM verwalten. Über die Geräteverwaltung (PPPC-Profile) die erlaubten Zugriffe zentral setzen und unerwartete Grants als Abweichung behandeln.
• Vollzugriff sparsam vergeben. Je weniger Apps Vollzugriff auf die Festplatte haben, desto kleiner die Angriffsfläche für den Missbrauch einer bereits berechtigten App.
• ESF-Quelle bereitstellen und Nutzer sensibilisieren. Die Prozess- und Dateiereignisse zentral ins SIEM bringen, und weil die erschlichene Zustimmung technisch kaum zu fassen ist, die Belegschaft für unerwartete Zugriffsdialoge sensibilisieren.

Der Test im Lab

Die Erkennung lässt sich auf einem Test-Mac mit aktivem eslogger oder Red Canary Mac Monitor gefahrlos prüfen - Änderungen danach zurücknehmen:

• Für Regel 1 tccutil reset All für eine Test-App ausführen und prüfen, dass das ESF-Prozessereignis den Aufruf zeigt.
• Für Regel 2 und 3 im Lab mit sqlite3 einen Testeintrag in die Benutzer-TCC.db schreiben (auf einem Testkonto, SIP unberührt) und prüfen, dass sowohl der sqlite3-Aufruf als auch der nicht-tccd-Schreibzugriff auf die Datei erkannt werden.
• Die erschlichene Zustimmung bewusst gegentesten: einen normalen Dialog bestätigen und beobachten, dass hier tccd schreibt und Regel 3 korrekt nicht auslöst - so wird der Blindspot greifbar.
• Breiter wird der Test mit den macOS-Fällen zu T1548.006 aus Atomic Red Team.

Fazit

Die TCC-Manipulation ist der Fall, bei dem Erkennung und ehrliche Grenze eng beieinanderliegen. Was über einen Prozess oder einen Schreibzugriff läuft - tccutil reset, sqlite3 gegen die TCC.db, ein Schreiber, der nicht tccd ist - ist belastbar sichtbar, und die drei Regeln nehmen genau das. Was über die erschlichene Zustimmung oder eine bereits berechtigte App läuft, hinterlässt dagegen kein sauberes TCC-Signal und ist nur über das Unified Log, die Folgeaktivität oder Awareness zu fassen. SIP schützt die System-Datenbank und ist deshalb die wichtigste Härtung. Die Grundlagen stehen unter macOS-Sicherheitsmonitoring; die übrigen Beiträge dieser macOS-Reihe behandeln die LaunchAgents- und LaunchDaemons-Persistenz, die Gatekeeper- und Quarantine-Umgehung, den AppleScript- und osascript-Missbrauch, den Keychain-Zugriff und das Dylib-Hijacking.