TCC Bypass

Transparency, Consent and Control (TCC) is the macOS subsystem that gates access to sensitive resources — the camera, microphone, screen recording, Full Disk Access, Accessibility, Contacts — behind an explicit, user-visible consent prompt the first time an app requests one. Every grant is recorded in a per-user (and a system-wide) SQLite database, TCC.db. Malware that wants silent access to these resources has two options that avoid ever showing that prompt: directly manipulate the TCC database to insert a grant row for itself (only possible if it can write there, which System Integrity Protection makes hard by default), or ride on a process that already holds the grant — for example injecting into, or scripting, an app the user has already approved for Accessibility or Full Disk Access, inheriting its standing permission instead of requesting a new one.

How it works

The per-user database lives at ~/Library/Application Support/com.apple.TCC/TCC.db and records approvals per bundle identifier and per service:

SELECT client, service, auth_value FROM access
WHERE service = 'kTCCServiceAccessibility';

A direct-write bypass (viable pre-SIP, or via a documented SIP exemption/known CVE) inserts a row for the attacker's own bundle ID so no prompt is ever shown on first use:

INSERT INTO access (service, client, client_type, auth_value, auth_reason)
VALUES ('kTCCServiceAccessibility', 'com.attacker.helper', 0, 2, 0);

Where direct writes are blocked, the more durable technique is to piggyback: script or inject into an application the user has already granted Accessibility or Automation rights to (many productivity and remote-support tools hold broad TCC grants), and drive sensitive actions — reading the screen, controlling other apps via Apple Events — through that already-trusted process instead of the attacker's own.

Detection & analysis

Static analysis:

• A sample that reads or opens TCC.db directly, or shells out to sqlite3 against that path, has no legitimate reason to — flag it regardless of whether the write itself would succeed under the current SIP policy.
• Check which of the sample's imports/entitlements correspond to Accessibility/Automation APIs (AXIsProcessTrusted, Apple Events sends via NSAppleScript/osascript) without a matching, user-facing feature that would justify requesting them.

Dynamic analysis:

• Monitor file-integrity events (EndpointSecurity ES_EVENT_TYPE_AUTH_OPEN/ NOTIFY_WRITE) on both the per-user and system TCC.db paths; any write from a process other than tccd itself is anomalous.
• Watch for a process suddenly exercising a TCC-gated capability (screen capture, Accessibility API calls) with no corresponding consent-prompt event in the UI layer immediately before it — the absence of the expected prompt is itself the signal.

Detection rule hint:

Alert on any process other than tccd opening either TCC.db for write, and separately alert when a process exercises Accessibility, screen-recording or Full-Disk-Access-gated behaviour without a corresponding kTCCServiceX authorization-request UI event having fired for that bundle ID in the same session.