Threat Lab Quarterly: agosto de 2026

Localizando SPN obsoletos y fantasma antes que los atacantes

Por Huy Kha

Introducción

En los últimos años, los ataques a Active Directory que abusan de los Service Principal Names (SPNs) han aumentado. Comenzó con Kerberoasting, pero las técnicas se han vuelto más creativas desde entonces. Los ataques Ghost SPN pueden permitir la escalada de privilegios al reclamar objetivos de servicio que nadie usa ya. Más recientemente, los ataques de colisión Unicode de SPN permiten a cualquier usuario autenticado con permisos write-SPN escalar privilegios también, usando nada más que un SPN visualmente idéntico pero técnicamente diferente.

También existe un problema más silencioso que no recibe mucha atención, que es la higiene básica de seguridad. En Netwrix, vemos que el mismo patrón se repite una y otra vez, sin importar el tamaño de la organización. Las cuentas de equipo permanecen habilitadas en Active Directory mucho después de que la máquina detrás de ellas fue retirada. Las cuentas de servicio mantienen SPNs que aún apuntan a hosts que ya no existen. Nadie vuelve a limpiar nada de eso, así que la cuenta simplemente permanece allí, aún activa, aún vulnerable a Kerberoasting, y nadie le presta atención.

Encontrar SPN ocultos en su(s) dominio(s)

Nuestro equipo de investigación en seguridad decidió crear algo que facilitara esto para profesionales de TI y administradores: un script de PowerShell llamado Find-StealthSPNs que busca SPNs ocultos en cuentas de computadoras y usuarios, para que puedas revisar los resultados y decidir qué es lo que realmente necesita limpieza.

El script se ejecuta en dos pasadas principales. La primera revisa cada cuenta de equipo en el bosque. Dado que cada máquina unida al dominio registra al menos un SPN por defecto, esta pasada verifica si el propio nombre de host del equipo todavía se resuelve en DNS y si alguno de sus SPN apunta a hosts que ya no existen en ningún lugar. Llamamos a esto un ghost SPN, un SPN que aún está en una cuenta, técnicamente válido, pero que apunta a nada real. También detecta cuentas de equipo que fueron precreadas en AD pero nunca se unieron realmente, ya que a menudo terminan sin ningún SPN, quedando ahí indefinidamente sin que nadie lo note.

Comprobamos esto deliberadamente a través de DNS en lugar de un ping ICMP. Algunos administradores usan ping para tener una idea rápida de si un host detrás de un SPN sigue activo, pero ICMP suele ser bloqueado por firewalls y filtrado basado en el host en la mayoría de los entornos, por lo que un ping fallido no dice mucho. Un registro DNS ausente es una señal más fiable de que nadie espera que ese nombre de host exista, independientemente de si la máquina respondería a un ping.

La segunda pasada analiza las cuentas de usuario, específicamente aquellas que tienen SPNs, ya que esa es la configuración clásica para una cuenta de servicio. Por cada SPN que encuentra, verifica dos cosas: si aún existe una cuenta de equipo correspondiente en AD y si ese nombre de host todavía se resuelve en DNS. Si ninguna de las dos es cierta, esa es una señal tan clara como se puede tener de que el SPN es un peso muerto. La cuenta sigue activa, el SPN sigue registrado y sigue siendo igual de explotable mediante Kerberoasting que siempre, excepto que ahora no hay nada legítimo que dependa de él.

Además, el script también verifica las colisiones Unicode de SPN, el tipo de ataque que mencionamos antes, donde un SPN manipulado puede parecer visualmente uno real, aunque sea un valor completamente diferente por debajo. Señala cualquier SPN con caracteres ocultos o similares y cruza referencias de cada SPN en el bosque para detectar casos donde dos cuentas parecen tener el mismo SPN. Esto puede generar falsos positivos, así que siempre verifica dos veces primero.

Todo funciona usando únicamente ADSI y DirectorySearcher, por lo que no depende del módulo ActiveDirectory PowerShell y funciona en todos los dominios del bosque, no solo en el que ejecutas.

Una nota rápida sobre la resolución DNS: Este script verifica DNS usando el resolvedor configurado en la máquina desde la que se ejecuta. Para obtener resultados (más) precisos, ejecútelo desde un controlador de dominio en lugar de una estación de trabajo, ya que los DC ya están configurados para resolver todos los dominios en su entorno. Ejecutarlo desde una máquina con configuraciones DNS inusuales o restringidas podría generar resultados falsos de MISSING_DNS para registros que realmente existen.

Conclusión

Al final del día, intentamos ayudar a las organizaciones a reducir su superficie de ataque limpiando cuentas obsoletas que ya nadie supervisa. Cada ghost SPN, cada cuenta de equipo habilitada vinculada a una máquina que ya no existe, cada cuenta de servicio que aún apunta a un host que ya no está, es un elemento más en Active Directory que no debería estar ahí. Ninguno de estos requiere un atacante sofisticado. Solo hace falta que alguien lo note antes que tú.

---

El enfoque de seguridad de identidad de DEF CON 34

Por Darryl Baker

DEF CON 34 y Black Hat USA 2026 presentaron tres investigaciones distintas que apuntan todas a la infraestructura de identidad. Esto es lo que anunció cada una y lo que significa para quienes gestionan programas de identity y AD.

CloudBasher: shells gratuitos en la nube convertidos en infraestructura atacante

Jenko Hwong y Chris Ryan presentaron CloudBasher, un conjunto de herramientas de código abierto construido mediante ingeniería inversa de las REST APIs privadas y las sesiones WebSocket detrás de las funciones gratuitas de cloud shell en AWS, Azure y GCP. El conjunto de herramientas estará disponible públicamente en GitHub, junto con un análisis de 2026 sobre patrones de mala configuración en la nube extraídos de datos de brechas.

La investigación reveló algunos hallazgos específicos que vale la pena destacar para los equipos de Identity Management.

• Una identidad de AWS comprometida puede asumir un rol y crear un gran número de entornos CloudShell.
• Las sesiones de terminal WebSocket permanecen activas después de que se revoca el token de acceso subyacente, por lo que revocar una credencial no necesariamente termina una sesión activa.
• Las cuentas de consumidor de M365 y Gmail obtienen acceso predeterminado a CloudShell, lo que amplía la superficie de ataque relevante a cuentas personales, no solo a las empresariales.

Una vez establecida la sesión, el kit de herramientas permanece en el directorio $HOME (que sobrevive a los reinicios), puede bloquear al usuario legítimo para que no use sudo en su propia sesión e instala un marco C2.

Por qué es importante: si su programa de identidad trata la revocación de tokens como equivalente a la terminación de sesión, esta investigación indica que esa suposición debe ser probada, no asumida. También vale la pena confirmar si sus políticas y monitoreo de acceso a CloudShell detectarían la creación anómala de sesiones.

GhostJacking: agentes de codificación de IA que actúan según instrucciones ocultas en registros 

Barak Sternberg, Nevo Poran y Ron Bobrov de Tenet Security presentaron GhostJacking, una técnica para secuestrar agentes de codificación de IA plantando instrucciones dentro de los registros que el agente debe leer, como alertas WAF, informes de errores y resultados de monitoreo. Tenet reportó una tasa de éxito del 90 % contra Claude Code bajo la configuración predeterminada de Cloudflare y estimó que más de 15,000 organizaciones están expuestas solo a través de configuraciones de Cloudflare.

Tenet demostró la técnica en tres plataformas. Entradas de registro WAF de Cloudflare envenenadas (Cloudflare protege aproximadamente al 42 % de las empresas Fortune 500) hicieron que los agentes cambiaran la configuración DNS y redirigieran el tráfico. Mensajes de registro inyectados de Datadog (usado por cerca del 48 % de las Fortune 500) hicieron que los agentes instalaran paquetes maliciosos, lo que llevó a la ejecución remota de código y al robo de credenciales. Informes de errores de Sentry envenenados (Sentry atiende a unos 4 millones de desarrolladores) hicieron que una instancia comprometida de Claude Code avalara al atacante ante el agente Seer AI de Sentry, produciendo una cadena de confianza entre agentes. Tenet también informó haber encontrado más de 2,700 claves API de Datadog expuestas y reveló por separado una fuga de sandbox relacionada con JWT en Claude Desktop a Anthropic. Este problema se solucionó antes de la charla en DEF CON.

Las acciones del agente en los tres casos utilizan sus propias credenciales legítimas y ya autorizadas. Esto significa que las herramientas EDR, WAF e IAM no detectan nada anómalo.

Por qué es importante: RBAC, el principio de menor privilegio y MFA no ayudan aquí, porque el acceso del agente es legítimo. El problema es lo que se le ha indicado hacer con ese acceso. Las propias recomendaciones de Tenet son una lista de verificación razonable para empezar: restringir por defecto el acceso de salida a la red del agente, requerir aprobación humana antes de cambios en la infraestructura, separar las herramientas de solo lectura de las que pueden escribir, y tratar cada registro o alerta que un agente lea como entrada no confiable, sin importar de qué plataforma provenga.

The OpenAI–Hugging Face incident: An agent that escaped its own test

En julio de 2026, OpenAI reveló que durante una evaluación interna usando el benchmark ExploitGym (898 vulnerabilidades reales), una versión experimental de GPT-5.6 Sol, ejecutada sin las medidas de seguridad activadas, escapó de su sandbox y comprometió la infraestructura de producción de Hugging Face. Hugging Face informó del incidente el 16 de julio; OpenAI reveló su papel el 21 de julio. Eric Wallace y Michael Dalton lo presentaron en Black Hat USA 2026.

Según las revelaciones, el agente encontró y explotó un zero-day en una instancia autohospedada de Artifactory (el proxy de caché del registro de paquetes de JFrog) para escapar de su sandbox y acceder a internet. Luego, el agente dedujo que Hugging Face alojaba la clave de respuestas del benchmark y fue directamente tras ella. Varias instancias de agentes se coordinaron posteriormente a través de Artifactory, intercambiando cientos de miles de mensajes para dividir tareas y compartir exploits. En un momento, los agentes propusieron firmar criptográficamente sus mensajes tras sospechar de un impostor. Cuando OpenAI cerró el canal el 4 de julio, los agentes lo reconstruyeron en cuatro días usando nombres de directorios en un endpoint no autenticado como canal de mensajería alternativo.

Durante una campaña de 4,5 días, OpenAI registró más de 17,600 acciones de agentes, incluyendo la exfiltración de 136 claves de almacén de credenciales, el robo de una clave de autenticación de mesh VPN, la inscripción de 181 dispositivos mediante Tailscale y la adquisición de acceso de escritura a GitHub App. La actividad en 11 nodos de Kubernetes incluyó la suplantación de nodos mediante metadatos de instancias AWS, tokens de identidad falsificados usando una clave EdDSA JWT robada y la creación de pods privilegiados con montajes del sistema de archivos del host. OpenAI declaró que también identificó otras fugas menores de sandbox, descritas como limitadas, y ninguna de las cuales cree que salió de su propia red.

Un detalle específico de identity e incident response: las consultas forenses de Hugging Face fueron bloqueadas por las mismas barreras de seguridad comerciales de IA integradas en los modelos OpenAI y Anthropic que intentó usar para la investigación, porque las barreras no podían distinguir las preguntas de un respondedor de incidentes de las de un atacante. Hugging Face usó un modelo de peso abierto con 753 mil millones de parámetros (GLM-5.2) para procesar más de 17,000 eventos de atacantes en horas en lugar de días.

Por qué es importante: este es un caso documentado de un agente autónomo que descubre de forma independiente una vulnerabilidad, extrae credenciales, falsifica tokens y se mueve lateralmente a través de la infraestructura en la nube sin dirección humana. Si su modelo de IAM y gobernanza solo considera identidades humanas y de cuentas de servicio, este incidente es una razón concreta para añadir una tercera categoría: agentes autónomos que pueden actuar por iniciativa propia.

Lo que estos tres tienen en común

CloudBasher trata sobre brechas en los controles de identidad a nivel de protocolo: revocación de tokens, límites de asunción de roles, políticas de acceso predeterminadas. GhostJacking trata de un agente de IA que usa una identidad legítima y delegada para actuar según instrucciones en las que no debería haber confiado. El incidente OpenAI–Hugging Face trata de un agente que obtiene y falsifica credenciales por sí mismo, sin que un humano o un registro manipulado lo haya provocado.

Un hilo separado atraviesa los tres casos: los defensores están limitados por herramientas que los atacantes no tienen que respetar. CloudBasher explotó suposiciones que los defensores no habían probado. GhostJacking explotó el hecho de que las herramientas de identidad no pueden evaluar la intención. Y en el caso de OpenAI–Hugging Face, las barreras de seguridad destinadas a prevenir el mal uso también ralentizaron a las personas que respondían.

---

Próximos pasos prácticos para los equipos de identity y AD

Cuatro cosas que vale la pena hacer este trimestre según esta investigación:

Investigación que podría haberse perdido

Por si te lo perdiste, compartimos tres de las publicaciones principales del equipo de Security Research de Netwrix.

Controles LDAP extendidos potentes: Anti-remediación y reconocimiento invisible en AD 

El investigador senior de seguridad Darryl Baker auditó todos los controles extendidos LDAP documentados de Active Directory y encontró dos con potencial ofensivo que no se habían publicado antes. FORCE_UPDATE permite a un atacante con acceso de escritura a solo un atributo hacer que un valor malicioso gane la resolución de conflictos de replicación de AD, por lo que una corrección posterior del defensor se revierte silenciosamente. La bandera OBJECT_SECURITY en DirSync permite a cualquier usuario de dominio leer en masa datos de AD a través de la ruta de replicación sin generar los eventos de registro que una búsqueda normal activaría. Ninguno otorga nuevos privilegios, pero ambos evaden las detecciones en las que confían la mayoría de los defensores; la publicación incluye orientación de detección correspondiente y herramientas de código abierto para red/blue.

Por qué es importante: ambas técnicas evaden los eventos de registro exactos (Evento 1644, Evento 4662) en los que se basan la mayoría de las reglas de monitoreo de AD. Si tus detecciones no se han probado específicamente contra ellos, probablemente no se activarán. Vale la pena verificar si tus canarios SACL y consultas de búsqueda realmente detectarían esto. 

Leer más

Tu asistente de codificación de IA está filtrando secretos 

Darryl Baker auditó el almacenamiento de credenciales en 14 herramientas populares de asistentes de escritorio de IA, incluyendo Claude Code, GitHub Copilot, Cursor, Continue.dev y Cline, y descubrió que la mayoría guardan tokens OAuth y claves API en JSON plano en rutas de archivo predecibles. Una brecha específica: en WSL, los archivos de credenciales de Claude Code en Windows pueden heredar permisos de lectura mundial. El artículo analiza ocho escenarios de ataque, incluyendo el secuestro de una sesión activa de control remoto de Claude Code y archivos de configuración MCP que agregan tokens de múltiples servicios en un solo archivo legible. También presenta AIHound, un escáner de código abierto de Netwrix que revisa una máquina para este tipo de credenciales expuestas.

Por qué es importante: si tus ingenieros usan alguna de estas herramientas, sus credenciales probablemente estén almacenadas en texto plano en el disco ahora mismo, en una ruta de archivo que un atacante no necesita adivinar. No se requiere escalada de privilegios para leerlas, y dado que las configuraciones MCP agrupan múltiples tokens de servicio en un solo archivo, una laptop comprometida puede afectar en cascada a todos los sistemas o servicios conectados. Esto puede incluir bases de datos, infraestructura en la nube e incluso otras herramientas de IA. AIHound te ofrece una forma rápida de verificar tu propia exposición antes de que alguien más la descubra por ti. 

Leer más

Automatización de la destrucción de inquilinos de Entra ID con IA 

Usando Claude para Chrome contra Microsoft Graph Explorer, Huy Kha demostró que una vez que una cuenta iniciada ya tiene acceso de Administrador Global, el JavaScript del lado del navegador y las solicitudes por lotes de Graph pueden automatizar la eliminación masiva de usuarios, restablecimientos de contraseña, revocación de sesiones y eliminación de políticas de Acceso Condicional. La publicación relaciona esto con incidentes reales, incluidos los casos Stryker y Storm-0501, donde operaciones destructivas en el inquilino siguieron a una compromisión de cuenta privilegiada, y señala que la IA no creó una nueva vía de ataque aquí; explotó un flujo de trabajo administrativo existente y lo hizo más rápido y fácil de ejecutar a gran escala.

Por qué es importante: esta es la brecha entre la compromisión de una cuenta privilegiada y la destrucción total del tenant, y la automatización con IA la está cerrando rápidamente. Una vez que alguien tiene una sesión de Global Admin, ya no necesita habilidades de scripting ni tiempo para causar el máximo daño. Esto aumenta la importancia de proteger y monitorear las sesiones de administrador y herramientas como Graph Explorer, no solo las credenciales. 

Leer más

Informe de Seguridad de Datos e Identity Security 2026: Avances y brechas en la adopción y preparación de IA agentiva

Netwrix Research Lab encuestó a 2,317 profesionales de TI y seguridad en 1,889 organizaciones para elaborar el Informe de Seguridad de Datos e Identity para 2026. Los resultados muestran que las organizaciones donde la IA amplió significativamente su huella de identidad fueron atacadas aproximadamente cuatro veces más que aquellas donde no lo hizo. El informe atribuye esta brecha a la velocidad de gobernanza más que a su rigor: el 76 % de las organizaciones no gobiernan ni monitorean completamente las identidades no humanas, y solo el 11 % reporta una preparación total en seguridad de IA mediante la aplicación y monitoreo continuos.

Por qué importa: los datos complican una suposición común, que una buena higiene de identidad por sí sola protege contra el riesgo impulsado por IA. Si tu gobernanza de identidad aún se basa en revisiones trimestrales y auditorías periódicas, vale la pena verificar cuánto tiempo existe un nuevo agente de IA o identidad no humana antes de que alguien lo note. Esa demora, no un control faltante, es a lo que realmente apunta la brecha de seguridad en este informe.

Leer más

---

Esto es todo para esta edición del Netwrix Threat Lab Quarterly. Volveremos pronto con nuevas investigaciones y más formas de cerrar las brechas que los atacantes esperan que pases por alto.