En tres años, el mismo investigador encontró cuatro formas de autenticarse en Azure Entra ID sin que quedara un solo registro. Cuatro bypass distintos, todos corregidos — pero el patrón revela algo que Microsoft debería explicar mejor.
La autenticación en la nube depende de sus logs tanto como de sus contraseñas. Si puedes validar credenciales sin generar trazas, los equipos de seguridad están ciegos. Eso es exactamente lo que encontró el investigador nyxgeek de TrustedSec a lo largo de 2023-2026, y esta semana publicó el episodio final: un tercer y cuarto bypass en los registros de inicio de sesión de Azure Entra ID (antes Azure AD).
¿Qué eran estos bypass y por qué importaban?
Los cuatro bypass comparten la misma mecánica de fondo: una autenticación HTTP POST al endpoint de tokens de Entra ID (login.microsoftonline.com) vía flujo OAuth2 ROPC, diseñada para devolver credenciales válidas sin generar una entrada en los sign-in logs que los administradores monitorean.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀Los primeros dos — GraphNinja y GraphGhost — ya habían sido documentados:
- GraphNinja (reportado agosto 2023, corregido mayo 2024): bastaba con apuntar la autenticación al GUID de un tenant externo. El intento fallaba como “usuario no encontrado” allá, pero confirmaba si la contraseña era válida. Ningún log quedaba en el tenant víctima.
- GraphGhost (reportado diciembre 2024, corregido abril 2025): enviando parámetros de autenticación deliberadamente inválidos, el flujo fallaba después de validar la contraseña. El resultado: un log de “fallo” que no revelaba el vector real, mientras el atacante ya sabía cuál contraseña funcionaba.
Los bypass tres y cuatro, publicados esta semana, son peores: no solo confirmaban contraseñas — devolvían tokens completamente funcionales. Autenticación exitosa, tokens listos para usar la Graph API, sin ningún registro visible para el administrador.
¿Por qué ocurre esto repetidamente?
La respuesta incómoda es que Entra ID es un sistema enorme construido sobre años de decisiones de diseño, con rutas de autenticación no siempre consistentes entre sí. El investigador tomó apenas dos semanas para que Microsoft corrigiera el cuarto bypass — frente a los siete meses que tardó GraphNinja. Eso sugiere que la velocidad de corrección mejora, pero también que los vectores existen en código que nadie estaba mirando con atención suficiente.
El problema de fondo no es solo técnico: es de visibilidad. Las organizaciones configuran sus SIEMs y sus alertas asumiendo que los sign-in logs son completos. Si hay huecos sistemáticos en ese registro, las detecciones basadas en umbrales de intentos fallidos —el estándar de facto para detectar password sprays— pierden valor. Un atacante que sepa qué endpoint explotar puede hacer un spray invisible.
Para referencia en ciberseguridad LATAM, ya cubrimos cómo Azure WAF en modo Detection también da falsa sensación de protección: el patrón de configuración silenciosa que no defiende de nada es más común de lo que parece.
Por qué importa para tu empresa
Si tu organización usa Microsoft 365, Azure AD o Entra ID — y la mayoría de empresas medianas en LATAM ya lo hacen — tu postura de seguridad tiene que asumir que el historial de logs puede tener huecos históricos. Estos bypass ya fueron corregidos, pero la exposición acumulada de 2023-2026 es real.
Lo que deberías hacer ahora:
- Verificar que tienes Entra ID actualizado: los parches para el tercer y cuarto bypass llegaron en semanas, pero requieren que el tenant esté en producción actual.
- Auditar logs históricos con KQL para detectar autenticaciones anómalas a tenants externos o con parámetros de scope inusuales — nyxgeek publica consultas de detección en su blog.
- No depender solo de “intentos fallidos” como señal de spray. Correlacionar con IPs, dispositivos y comportamiento de cuenta.
- Revisar tus licencias E5 si tienes Entra ID P2: las capacidades de auditoría avanzada son la capa de defensa más relevante contra vectores como este.
El patrón que emerge de estos cuatro bypass es que la capa de autenticación tiene más superficie de la que sus usuarios ven. Esto no es exclusivo de Microsoft — cualquier sistema de identidad en la nube tiene rutas no triviales — pero tres años de bypass continuos en el mismo componente es una señal de que merece revisión más profunda, no solo parches sucesivos.
Si manejas infraestructura cloud y quieres entender los riesgos de ciberseguridad en LATAM en 2026, también vale la pena revisar cómo el cibercrimen evolucionó y qué están haciendo las empresas para responder.
