Investigar el abuso de permisos TCC en macOS
Cómo abusan los atacantes de los permisos TCC de macOS, qué deja cada técnica en TCC.db y cómo pivotar al registro unificado, launchd, cuarentena y shell.
Resumen. Para casi todo lo que quieren hacer en macOS, los atacantes necesitan permisos TCC: acceso total al disco para leer datos del usuario; Accesibilidad, grabación de pantalla y monitorización de entrada para observar y controlar la sesión, y Automatización de Finder o System Events para actuar como el usuario. Cada vía deja una fila característica en TCC.db: qué cliente, qué servicio, cómo se decidió y cuándo. Este artículo relaciona las técnicas habituales con lo que encontrará y con los artefactos a los que pivotar después. Los ejemplos proceden de la muestra ficticia FIN-MBP-03 de TCC Parser.
Mantenga la perspectiva: casi todas las filas descritas a continuación aparecen también en Macs limpios. Un hallazgo es una pregunta que responder, no una respuesta.
Las técnicas y sus rastros
| Técnica | Cómo se ve en TCC.db | Dónde |
|---|---|---|
| Acceso total al disco para un terminal o intérprete | kTCCServiceSystemPolicyAllFiles, cliente com.apple.Terminal, /bin/bash, /usr/bin/osascript y similares, auth_value = 2 | BD del sistema |
| Capacidades de vigilancia | kTCCServiceAccessibility, kTCCServiceScreenCapture, kTCCServiceListenEvent, kTCCServicePostEvent | BD del sistema |
| Automatización de Finder, System Events o Terminal | kTCCServiceAppleEvents, destino com.apple.finder, com.apple.systemevents, com.apple.Terminal | BD por usuario |
| Clientes identificados por ruta o ad hoc | client_type = 1, ruta en /tmp, /private/var/tmp, /Users/Shared, una carpeta oculta con punto o Descargas, csreq con solo cdhash | Ambas |
| Acceso a carpetas y volúmenes para preparar datos | kTCCServiceSystemPolicyDocumentsFolder, ...DesktopFolder, ...DownloadsFolder, ...RemovableVolumes | BD por usuario |
| Limpieza | Filas eliminadas con tccutil reset, visibles solo en el WAL o en copias antiguas | Ambas |
| Edición directa de la base de datos | Filas sin actividad de tccd correspondiente, códigos de motivo o requisitos anómalos | Depende de las protecciones |
"BD del sistema" y "BD por usuario" reflejan dónde suelen estar estos servicios; el reparto ha cambiado entre versiones, así que consulte las dos.
Acceso total al disco para terminales e intérpretes
El camino más corto hacia los datos del usuario es obtener acceso total al disco para algo que ejecute comandos arbitrarios. Los permisos suelen atribuirse a la app responsable, así que una concesión a Terminal cubre cada script, binario y comando de una línea lanzado desde ella. Busque acceso total al disco en manos de com.apple.Terminal, de terminales de terceros o de intérpretes identificados por ruta, y lea auth_reason: un motivo originado por el usuario (habitualmente 2 consentimiento del usuario o 3 fijado por el usuario) significa que alguien hizo clic.
En la muestra, el acceso total al disco para com.apple.Terminal se concedió a las 10:11:37 UTC, seis minutos después del inicio de la ventana de intrusión.
Accesibilidad, grabación de pantalla, monitorización de entrada
Son los servicios de vigilancia y control. Accesibilidad permite a un programa hacer clic y teclear en otras apps, incluso aceptar cuadros de diálogo; grabación de pantalla ve la pantalla; monitorización de entrada observa las pulsaciones de teclas; Post Event inyecta entrada. El malware suele solicitarlos desde un binario auxiliar, a veces tras conseguir que el usuario apruebe una solicitud convincente.
Una fila denegada también es evidencia. En la muestra, al helper /Users/dana.whitlock/Library/Caches/.sync/sync-helper se le concedió Accesibilidad a las 10:19:05 y se le denegó grabación de pantalla a las 10:24:40. La denegación muestra que la solicitud se produjo, aunque fallara.
En Sequoia y posteriores, revise ~/Library/Group Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist: fechas de recordatorio muy lejanas en el futuro indican que alguien suprimió el recordatorio periódico de grabación de pantalla.
Automatización de Finder, System Events y Terminal
La automatización mediante Apple Events permite a una app enviar órdenes a otra. Controlar Finder significa copiar y mover archivos como el usuario; controlar System Events, automatizar acciones de la interfaz y del sistema; controlar Terminal, ejecutar comandos a través de una app que puede tener acceso total al disco. Estas filas están en la base de datos del usuario, con el destino en indirect_object_identifier y su requisito de código en indirect_object_code_identity.
En la muestra, Terminal obtuvo permiso para controlar System Events a las 10:14:02 y Finder a las 10:16:48, ambos en la base de datos de dana.whitlock.
Clientes identificados por ruta y con firma ad hoc
Las apps legítimas casi siempre se registran por bundle ID, con un requisito ligado a Apple o a un Team ID. Un cliente registrado por ruta absoluta (client_type 1) en una carpeta temporal, compartida u oculta, con un csreq que solo contiene un cdhash, es un programa pequeño, sin firmar o con firma ad hoc, que alguien colocó y ejecutó. Eso describe también a muchas herramientas de desarrollo, así que compruebe la ruta, el archivo y cómo llegó. Más detalles en decodificar los requisitos de código csreq.
Preparación de datos: carpetas y volúmenes extraíbles
Las concesiones de Documentos, Escritorio, Descargas y volúmenes extraíbles a un terminal o a un helper, con pocos minutos de diferencia, esbozan la fase de recolección. En la muestra: Documentos y Escritorio para Terminal hacia las 10:18, Descargas para el sync-helper a las 10:21:44 y volúmenes extraíbles para Terminal a las 10:38:55, que la historia vincula a un volumen USB llamado "EXFIL".
Limpieza con tccutil
Un intruso que conoce TCC puede eliminar concesiones al marcharse con tccutil reset. La fila desaparece de la base de datos, pero copias anteriores de su página pueden quedar en TCC.db-wal o en páginas liberadas. En la muestra, la concesión de Accesibilidad del helper ya no está en el estado actual y se recupera del WAL; la historia sitúa la eliminación a las 10:47:12 UTC. Vea recuperar permisos TCC eliminados del WAL.
Edición directa de TCC.db
System Integrity Protection impide modificar la base de datos del sistema, incluso a root. Con SIP desactivado, un proceso root puede escribir en ella directamente. La base de datos por usuario está protegida por TCC, no por SIP, y la investigación pública ha mostrado en el pasado formas de manipularla. Indicios que revisar, con cautela: filas cuyo last_modified no tiene actividad com.apple.TCC correspondiente en el registro unificado, códigos de motivo que no encajan con la forma en que debería haberse hecho la concesión y requisitos de código ausentes o anómalos. Anote en el caso el estado de SIP del Mac (con csrutil status en un sistema en vivo o a partir de su herramienta de triaje).
MDM y PPPC
Un perfil PPPC malicioso o inesperado puede preconceder muchos servicios sin solicitud. No puede conceder en silencio la cámara, el micrófono ni la grabación de pantalla. Las filas con un auth_reason que se interpreta habitualmente como política MDM (6), un policy_id o una entrada en MDMOverrides.plist deberían corresponder a un perfil que su equipo de MDM reconozca. En la muestra, com.example.edr.agent tiene acceso total al disco mediante un perfil PPPC, lo esperable para un agente EDR.
Construir la cronología
Ordene las filas y fíjese en los huecos y las ráfagas. La muestra, en UTC, el 2026-09-14:
| Hora | Base de datos | Evento |
|---|---|---|
| 10:11:37 | Sistema | Acceso total al disco permitido para Terminal |
| 10:14:02 | dana.whitlock | Terminal puede controlar System Events |
| 10:16:48 | dana.whitlock | Terminal puede controlar Finder |
| ~10:18 | dana.whitlock | Acceso a Documentos y Escritorio para Terminal |
| 10:19:05 | Sistema | Accesibilidad permitida para el sync-helper identificado por ruta |
| 10:21:44 | dana.whitlock | Acceso a Descargas para el sync-helper |
| 10:24:40 | Sistema | Grabación de pantalla denegada para el sync-helper |
| 10:38:55 | dana.whitlock | Acceso a volúmenes extraíbles para Terminal |
| 10:47:12 | Sistema | Fila de Accesibilidad del sync-helper eliminada (solo en el WAL) |
En TCC Parser, Findings (hallazgos) señala una ráfaga de cambios de permisos de las 10:11:37 a las 10:24:40, seguida de un hueco de 14 minutos hasta las 10:38:55. Un intervalo de 10:05 a 10:50 (el botón Use the sample's incident window de la pestaña Findings) acota todas las pestañas a la intrusión.
Hacia dónde pivotar
TCC.db indica lo que era posible. Otros artefactos indican lo que ocurrió:
| Pregunta | Artefacto |
|---|---|
| ¿Quién pidió qué y qué proceso era el responsable? | Registro unificado, subsystem == "com.apple.TCC" |
| ¿Cómo llegó el helper? | Base de datos de eventos de cuarentena, historial de descargas, marcas de tiempo del sistema de archivos |
| ¿Cómo persiste? | LaunchAgents y LaunchDaemons (~/Library/LaunchAgents, /Library/LaunchAgents, /Library/LaunchDaemons) e ítems de inicio |
| ¿Qué se ejecutó en Terminal? | Historial de shell (~/.zsh_history, ~/.zsh_sessions/) |
| ¿Se modificó y eliminó un permiso? | Telemetría del EDR; eventos de modificación de TCC de Endpoint Security desde macOS 15.4 |
| ¿Qué salió del Mac? | Historial del navegador, evidencia de medios extraíbles, registros de red |
En la historia de la muestra, esos pivotes llevan a una descarga en cuarentena tools.zip desde https://files.example/…, un LaunchAgent falso com.example.updater.plist, archivos preparados en ~/Library/Caches/.sync/ y una visita a transfer.example. Nada de eso está en TCC.db; es adonde apuntan las filas TCC.
Una consulta inicial para el registro unificado, sobre un archivo de logs recopilado o en un sistema en vivo:
log show --info --predicate 'subsystem == "com.apple.TCC"' \
--start "2026-09-14 10:00:00" --end "2026-09-14 11:00:00"
El formato de los mensajes varía según la versión y algunos valores pueden aparecer ocultos como <private>. La retención es limitada, así que recopile los logs cuanto antes.
Redactar el informe
- Describa capacidades, no acciones: "Terminal tenía acceso total al disco desde las 10:11:37 UTC", y después cite el artefacto que muestra el uso.
- Cite la base de datos y la cuenta de cada fila, e indique cuándo una fila se recuperó del WAL.
- Matice las interpretaciones de
auth_reasoncomo documentadas por la comunidad. - Anote las concesiones que usted mismo hizo durante la recolección para que no se confundan con actividad del atacante.
Preguntas frecuentes
¿El acceso total al disco para Terminal es un indicio de compromiso?
No por sí solo. Desarrolladores y administradores lo conceden con frecuencia. Cobra importancia cuando la hora de la concesión coincide con otra actividad sospechosa, cuando el puesto del usuario no lo requiere o cuando le siguen concesiones de Automatización, carpetas o volúmenes extraíbles para la misma app.
¿Puede un malware concederse permisos TCC a sí mismo?
Normalmente hace falta una solicitud aceptada por el usuario, una política MDM o una decisión del sistema. Las técnicas para lograrlo incluyen engañar al usuario para que apruebe una solicitud, aprovechar los permisos de una app que ya los tiene y editar la base de datos directamente donde las protecciones lo permiten, por ejemplo la base de datos del sistema cuando SIP está desactivado.
¿Dónde encuentro evidencia de que se usó un permiso?
No en TCC.db, que solo guarda decisiones. Revise el registro unificado (subsistema com.apple.TCC para las solicitudes), la evidencia de ejecución de procesos, el historial de shell, las marcas de tiempo del sistema de archivos y la telemetría del EDR.
¿Cómo distingo un permiso concedido por MDM de uno concedido por el usuario?
Revise auth_reason (el 6 se interpreta habitualmente como política MDM), policy_id y la tabla policies, y MDMOverrides.plist. Confírmelo con los perfiles de configuración instalados. Un perfil PPPC que no sabe explicar es un hallazgo.