La falla que permitió apagar la seguridad de macOS desde dentro

Un usuario estándar abre sesión en un Mac corporativo. No posee privilegios administrativos, no controla el kernel, no explota una vulnerabilidad remota y tampoco necesita introducir un controlador clandestino en las profundidades del sistema operativo. Desde la perspectiva convencional, se encuentra varios niveles por debajo de las herramientas encargadas de vigilarlo. El agente de seguridad opera con permisos elevados, el sistema de administración mantiene políticas que el usuario no debería alterar y las extensiones responsables de observar procesos, archivos y conexiones están protegidas por la arquitectura de macOS.

Sin embargo, la defensa termina apagándose.

No porque el atacante haya vencido su mecanismo de autoprotección mediante fuerza bruta, sino porque logró algo más elegante y perturbador: hacer que un componente privilegiado reconociera como legítima una orden que nunca debió aceptar. El software no tuvo que ser reemplazado por una copia falsa. Su firma no fue falsificada. La cadena criptográfica que acreditaba su procedencia podía continuar siendo válida. Lo que falló fue la interpretación de esa identidad dentro de una conversación entre procesos.

Investigadores demostraron que una cuenta sin permisos administrativos podía aprovechar debilidades en la validación de servicios XPC (mecanismo de comunicación entre procesos utilizado por macOS) para interactuar con funciones privilegiadas pertenecientes a herramientas empresariales de seguridad y administración. La técnica permitió descargar un sensor de protección de endpoints, desactivar persistentemente un agente de gestión y terminar componentes responsables de producir telemetría. Una tercera solución empresarial también habría resultado vulnerable.

El caso asociado al agente de administración fue registrado como CVE-2026-39118 y corregido en versiones posteriores. Los proveedores involucrados incorporaron mitigaciones y protecciones adicionales. Pero reducir esta historia a dos fabricantes, una actualización pendiente o una falla más de macOS sería desperdiciar lo verdaderamente importante.

La investigación expuso una debilidad más amplia: una parte de la industria todavía utiliza la identidad del software como sustituto de su intención.

Una firma puede demostrar quién publicó un componente. Una huella criptográfica puede indicar que un ejecutable corresponde a una versión conocida. Ninguno de esos atributos demuestra, por sí solo, que una solicitud concreta fue originada por el flujo legítimo de la aplicación, que el contexto de ejecución permanece íntegro o que el proceso que habla en su nombre continúa representando aquello que el sistema cree reconocer.

La defensa no fue destruida desde afuera. Fue persuadida desde dentro.

El privilegio vive detrás de una conversación aparentemente inocente

Las aplicaciones modernas rara vez funcionan como un único bloque de código. La interfaz que el usuario ve suele ser apenas la capa visible de una arquitectura compuesta por procesos, servicios auxiliares, extensiones y daemons (programas persistentes que funcionan en segundo plano). Algunos componentes operan con los permisos del usuario. Otros necesitan capacidades mucho más amplias para instalar software, modificar configuraciones, controlar servicios o interactuar con subsistemas protegidos.

En macOS, XPC permite que estos elementos se comuniquen sin convertir toda la aplicación en un monolito privilegiado. Una aplicación gráfica puede enviar una solicitud a un servicio que funciona como root (cuenta con el máximo nivel de privilegio local), recibir una respuesta y continuar operando sin que su interfaz principal posea acceso irrestricto al sistema. Desde la perspectiva del diseño seguro, esta separación tiene sentido: reduce la cantidad de código ejecutándose con privilegios y concentra las operaciones críticas en procesos más pequeños.

El problema aparece cuando el servicio privilegiado debe decidir quién está autorizado para hablarle.

Una interfaz XPC no es simplemente una tubería por la que circulan datos. Puede funcionar como una API administrativa local (interfaz que expone operaciones privilegiadas dentro del equipo). Detrás de ella pueden existir métodos capaces de instalar paquetes, ejecutar procesos, detener agentes, cambiar políticas, desmontar extensiones o eliminar componentes. Si la autenticación del cliente es insuficiente, la misma arquitectura creada para contener privilegios se transforma en un mecanismo para entregarlos.

En los productos analizados, los investigadores identificaron funciones internas con capacidad suficiente para descargar agentes, terminar procesos de seguridad o modificar el estado operacional del software. Estas funciones no eran necesariamente errores en sí mismas. Un producto de seguridad necesita instalarse, actualizarse, reiniciarse y, en determinadas circunstancias, desactivarse de manera controlada. Un sistema de administración necesita ejecutar tareas que un usuario normal no debería poder realizar.

La vulnerabilidad surge cuando la frontera que protege esas funciones confunde apariencia con autorización.

El daemon recibe una petición. Examina la identidad del proceso remoto. Comprueba atributos relacionados con la firma del código. Concluye que está conversando con un componente perteneciente a la aplicación legítima y permite la operación. Desde el punto de vista del servicio, todo parece correcto. Desde el punto de vista del atacante, acaba de obtener una interfaz privilegiada sin convertirse en administrador.

Esto modifica la manera en que entendemos la escalada de privilegios (proceso mediante el cual un actor obtiene capacidades superiores a las inicialmente disponibles). No siempre requiere corromper memoria, explotar el kernel o ejecutar comandos mediante una configuración defectuosa. A veces basta con convencer al componente correcto de que la solicitud proviene de alguien autorizado.

Una frontera de privilegios no es segura porque reconozca al interlocutor. Es segura cuando puede demostrar que ese interlocutor tiene autoridad para ejecutar esa operación, en ese contexto y en ese momento.

La firma correcta en el contexto equivocado

La firma de código es una de las bases de la seguridad moderna de macOS. Permite relacionar un ejecutable con una identidad de desarrollo, verificar que su contenido no haya sido alterado de manera incompatible con su firma y aplicar políticas vinculadas con su procedencia. Gatekeeper, la notarización, los entitlements (permisos especiales declarados por una aplicación) y numerosos controles del sistema dependen de esta infraestructura.

Pero una firma no es una declaración de inocencia. Tampoco constituye una prueba de intención.

El sistema puede determinar que un proceso corresponde a código firmado por un desarrollador específico. Puede comparar su identificador, su Team ID (identificador asignado al equipo de desarrollo) o su CDHash (huella criptográfica derivada del código firmado). Lo que no puede inferir automáticamente es si el proceso continúa ejecutándose dentro de un contexto operacional legítimo, si alguno de sus recursos fue manipulado o si un atacante consiguió utilizar un componente auténtico como contenedor.

La técnica descrita por los investigadores combinó el comportamiento de la caché de confianza asociada al CDHash con una forma de inyección mediante archivos NIB. Un archivo NIB es un recurso utilizado por aplicaciones de macOS para describir elementos de interfaz y objetos que deben instanciarse al cargar determinadas vistas. Aunque su origen está relacionado con la presentación visual, estos recursos pueden influir en la creación y conexión de objetos dentro del proceso.

La cadena conceptual es más importante que la mecánica puntual. Primero se ejecuta un componente legítimamente firmado para que el sistema reconozca su identidad. Luego se manipulan recursos que pueden cargarse durante su ejecución. El resultado es un proceso que conserva atributos suficientes para ser tratado como confiable, pero dentro del cual el atacante ha introducido un comportamiento no previsto.

El servicio XPC no ve necesariamente un binario extraño llamando a su puerta. Ve la identidad de la aplicación que espera reconocer.

Este caso no invalida la firma de código. La devuelve a su lugar correcto. Es una señal fundamental, pero no suficiente. Debe combinarse con validación estricta del cliente, restricciones de entitlements, comprobación dinámica del proceso, control granular de los métodos expuestos y autorización específica para cada operación sensible.

La misma confusión aparece en otros dominios. Un token legítimo puede haber sido robado. Una sesión autenticada puede estar controlada por un adversario. Un certificado válido puede proteger una infraestructura comprometida. Una cuenta real puede ejecutar una instrucción fraudulenta. La autenticidad de una credencial demuestra únicamente aquello para lo cual fue diseñada.

La firma prueba procedencia. La autorización debe probar legitimidad operacional. Mezclarlas es pedirle a la criptografía que responda una pregunta que nunca se le formuló.

El antivirus no fue vencido: fue utilizado

Existe una diferencia sustancial entre matar un proceso de seguridad y conseguir que el propio producto ejecute su mecanismo legítimo de desactivación. En el primer caso, el atacante se enfrenta a la autoprotección del agente, a las restricciones del sistema operativo y a las detecciones diseñadas para identificar intentos de manipulación. En el segundo, solicita una operación que el producto ya sabe realizar y que, bajo determinadas condiciones, considera administrativa.

La investigación mostró que un usuario estándar podía utilizar interfaces XPC expuestas por soluciones empresariales para alcanzar ese segundo escenario. En uno de los casos, el sensor de seguridad podía descargarse completamente, eliminando capacidades de observación sobre procesos, red y comportamiento del endpoint. En otro, una cadena de llamadas permitía desactivar de forma persistente el agente de administración y terminar su extensión basada en Endpoint Security Framework (infraestructura de macOS que permite a herramientas autorizadas observar y responder a eventos del sistema).

La elegancia del ataque radica en que no intenta reproducir el funcionamiento interno del producto. Lo invoca.

Una herramienta de seguridad necesita tener la capacidad de detenerse. De lo contrario, las actualizaciones, reparaciones y tareas de mantenimiento serían imposibles. El problema no es que exista una función para descargar un sensor. El problema es que esa función pueda alcanzarse desde una identidad insuficientemente validada, a través de una interfaz que hereda demasiada confianza y exige demasiado pocas pruebas.

Esto expone una contradicción incómoda. Cuanto más poderosa es una herramienta defensiva, mayor es el daño potencial si sus mecanismos de administración se convierten en capacidades ofensivas. Un agente con permisos para observar todos los procesos también dispone de capacidades extraordinarias dentro del sistema. Un producto capaz de terminar aplicaciones maliciosas puede ser inducido a terminar componentes legítimos. Una plataforma diseñada para imponer políticas puede transformarse en una vía para desmontarlas.

Los controles de seguridad no son objetos pasivos. Son software privilegiado con una superficie de ataque propia.

Durante años, gran parte de la evaluación de estas herramientas se concentró en cuánto detectaban, qué técnicas reconocían y qué tan rápido respondían. Mucho menos espacio recibió una pregunta anterior: qué ocurre cuando el agente se convierte en el objetivo.

La respuesta tradicional ha sido la autoprotección. Se impide que usuarios comunes detengan servicios, eliminen archivos, descarguen extensiones o modifiquen configuraciones. Pero la autoprotección suele concentrarse en acciones externas evidentes. Este caso demuestra que también debe protegerse contra el abuso semántico de sus propias funciones.

No basta con impedir que alguien rompa el agente. Hay que impedir que el agente acepte romperse.

Cuando el sensor desaparece, el silencio deja de ser neutral

Cuando un sensor deja de reportar, el centro de operaciones recibe una ausencia. En algunos entornos esa ausencia genera una alerta inmediata. En otros se mezcla con decenas de causas operacionales: equipos apagados, dispositivos suspendidos, fallas de conectividad, cambios de red, certificados vencidos, actualizaciones incompletas o agentes temporalmente degradados.

Los atacantes conocen esa ambigüedad.

La desaparición de telemetría no siempre produce el mismo impacto que una detección de malware, una ejecución sospechosa o una conexión hacia infraestructura conocida. Los sistemas defensivos están diseñados para interpretar señales; el silencio, en cambio, es una señal difícil de clasificar. Puede significar compromiso o simplemente que alguien cerró la tapa del portátil.

Esta incertidumbre convierte la neutralización silenciosa del agente en una capacidad especialmente valiosa. Si el adversario elimina visibilidad antes de desplegar herramientas adicionales, recolectar credenciales o extraer información, las acciones posteriores pueden ocurrir en un territorio que el SOC (centro de operaciones de seguridad) cree seguir controlando.

El estado mostrado por la consola central puede tampoco representar la condición real del endpoint. Un panel puede conservar durante cierto tiempo la última situación conocida. El dispositivo puede continuar figurando como registrado, administrado o protegido aunque alguno de sus componentes críticos haya dejado de funcionar. La diferencia entre estado administrativo y capacidad efectiva de observación crea una ventana peligrosa.

Un endpoint no está protegido porque aparezca en el inventario. Está protegido cuando sus controles funcionan, sus extensiones permanecen activas, su telemetría llega con continuidad y su estado puede comprobarse desde una fuente independiente.

Ese último elemento es crucial. Si el mismo agente encargado de defender el equipo es también la única entidad que informa que sigue vivo, el modelo contiene una circularidad evidente. Confiamos en el sensor para que confirme que el sensor no ha sido silenciado.

La resiliencia exige señales externas. El sistema de administración puede verificar la presencia de la extensión de seguridad. La plataforma de identidad puede detectar que un dispositivo continúa autenticándose mientras ha dejado de enviar telemetría. La red puede registrar actividad de un equipo cuyo agente aparece desconectado. El sistema operativo puede aportar evidencia sobre el estado de servicios críticos. Ninguna señal aislada es perfecta, pero su correlación reduce la dependencia de una única fuente de verdad.

Instalado no significa activo. Activo no significa íntegro. Íntegro no significa observable.

Qué debe ocurrir mañana a las nueve de la mañana

La respuesta inmediata comienza por abandonar la métrica cómoda de “agente instalado”. Un CISO debería pedir una visión separada de presencia, actividad, integridad y continuidad de telemetría. Un Mac puede conservar el paquete del producto y, al mismo tiempo, haber perdido su extensión, su servicio privilegiado o su capacidad para reportar eventos. La consola debe mostrar no solo que el dispositivo existe, sino cuándo transmitió su última señal útil, qué componentes se encuentran activos y si el estado coincide con la realidad observada desde otras plataformas.

El equipo de seguridad debería correlacionar la pérdida de telemetría con actividad residual del endpoint. Si un dispositivo continúa autenticándose, accediendo a recursos corporativos, resolviendo nombres o generando tráfico mientras su sensor aparece desconectado, la ausencia debe elevarse desde una incidencia operativa a una posible condición de evasión. No toda desconexión es un ataque, pero toda desconexión incongruente merece investigación.

Los administradores de macOS deberían revisar qué procesos privilegiados pertenecientes a herramientas de seguridad y administración exponen servicios XPC. La pregunta relevante no es únicamente si esos servicios existen, sino cómo validan a sus clientes, qué métodos publican y cuáles permiten modificar el estado del agente. Las funciones capaces de descargar extensiones, detener procesos, ejecutar comandos o alterar políticas deben recibir atención prioritaria.

También debe exigirse a los proveedores una respuesta específica. No basta con preguntar si el producto está “protegido contra manipulación”. La organización debería conocer cómo autentica el producto a los clientes XPC, si valida el binario exacto además del Team ID, qué entitlements exige, si la autorización ocurre en el servicio privilegiado y qué eventos genera cuando se solicita detener o descargar el agente. La frase “utilizamos firma de código” ya no constituye una respuesta suficiente.

Los equipos de detección deben incorporar hipótesis relacionadas con la degradación del control. Esto incluye cambios inesperados en extensiones de sistema, detenciones no planificadas de servicios, modificaciones de launch daemons (servicios iniciados automáticamente por macOS), desaparición abrupta de eventos y solicitudes administrativas fuera de ventanas de mantenimiento. El objetivo no es convertir cada reinicio en un incidente, sino identificar secuencias anómalas.

La política de acceso también debe reaccionar. Un dispositivo que ya no puede demostrar la operación de controles obligatorios no debería conservar indefinidamente el mismo nivel de confianza. La pérdida del EDR o del MDM puede traducirse en autenticación reforzada, acceso restringido, cuarentena lógica o bloqueo temporal de recursos sensibles. La seguridad del endpoint debe influir en la decisión de acceso y no limitarse a una consola aislada.

Por último, las organizaciones deben verificar versiones y correcciones efectivamente desplegadas. Una actualización disponible no equivale a una actualización instalada. El inventario debe distinguir entre versión declarada, versión activa y componentes realmente cargados. La deuda de parchado suele esconderse detrás de dispositivos que llevan semanas suspendidos, equipos fuera de línea o instalaciones degradadas que la consola interpreta como saludables.

El control que no puede demostrar que sigue funcionando no debería seguir concediendo confianza.

La autoprotección necesita una segunda generación

La primera generación de autoprotección buscaba impedir que malware y usuarios desactivaran el agente mediante acciones directas. Protegía archivos, servicios, procesos, configuraciones y extensiones. Su adversario implícito era alguien que intentaba romper el producto desde afuera.

La segunda generación debe asumir algo más sofisticado: el atacante puede utilizar las relaciones internas del producto, sus canales de administración y su propia identidad para alcanzar el mismo objetivo.

Esto exige una arquitectura menos confiada. Los servicios privilegiados deben autenticar estrictamente cada conexión. Las operaciones sensibles deben autorizarse de manera individual. La identidad de firma debe combinarse con requisitos de proceso, entitlements, contexto de ejecución y, cuando sea posible, pruebas vinculadas a una sesión administrativa válida. Las funciones destructivas deberían generar evidencia centralizada incluso cuando sean invocadas por componentes legítimos.

Una solicitud para detener un sensor no debería tratarse como una operación rutinaria únicamente porque proviene de una aplicación firmada. Debería activar controles proporcionales al daño que puede producir. La plataforma debe determinar si existe una política que autoriza la acción, si la orden provino del plano central, si coincide con una ventana de mantenimiento, si el solicitante es el binario exacto esperado y si el usuario posee la autoridad correspondiente.

También es necesario separar capacidad operativa de autoridad. Un módulo puede ser técnicamente capaz de solicitar que el agente se detenga, pero no debería poseer automáticamente autoridad para hacerlo. Esa autoridad puede depender de una política, una credencial efímera, una confirmación desde el plano central o un canal fuera de banda (mecanismo independiente del canal principal).

La continuidad de la defensa debe verificarse desde múltiples capas. El sistema de administración puede comprobar el estado del sensor. El sensor puede informar la condición del sistema de administración. La plataforma de identidad puede elevar el riesgo cuando un equipo pierde controles obligatorios. El acceso a recursos sensibles puede degradarse si el dispositivo deja de demostrar cumplimiento.

Aquí aparece una idea más amplia que la protección de un producto específico: la seguridad del endpoint debe ser verificable, no presumida.

El dispositivo no debería recibir confianza permanente porque alguna vez instaló un agente. Debe demostrar continuamente que sus controles obligatorios permanecen activos, actualizados e íntegros. Una arquitectura de Zero Trust (modelo donde la confianza se verifica de forma continua) aplicada al endpoint debe desconfiar incluso de la aparente salud de sus propios componentes.

La lección más incómoda es también la más fértil: el software de seguridad no merece confianza automática por ser software de seguridad. Debe ganársela mediante las mismas propiedades que exige al resto del ecosistema: autenticación sólida, autorización contextual, mínimo privilegio, observabilidad independiente y resistencia frente a componentes comprometidos.

Las herramientas afectadas fueron corregidas. Esa es la respuesta inmediata. La respuesta madura consiste en aceptar que la falla no vivía únicamente en una versión vulnerable, sino en una costumbre arquitectónica: permitir que una identidad reconocida funcionara como explicación suficiente.

No lo es.

Una identidad legítima puede transmitir una orden ilegítima. Una defensa activa puede participar en su propia desaparición.

El endpoint del futuro no será aquel cuyo agente resulte imposible de detener. Será aquel donde ninguna pieza, por confiable que parezca, pueda ordenar su desaparición sin demostrar primero que posee la autoridad y el contexto necesarios para hacerlo.