Se revelan el tercer y cuarto caso de vulnerabilidades de evasión de registros de inicio de sesión en Azure Entra ID

 (trustedsec.com)
1 puntos por GN⁺ 2026-03-22 | 1 comentarios | Compartir por WhatsApp
  • Desde 2023 se han descubierto un total de 4 vulnerabilidades de evasión de registros de inicio de sesión de Azure Entra ID, y las dos más recientes fueron confirmadas como problemas graves que permiten emitir tokens válidos
  • GraphGoblin evade la generación de registros en el flujo OAuth2 ROPC repitiendo el parámetro scope, y Graph**** provoca la omisión total de registros con una cadena de User-Agent de más de 50 mil caracteres
  • En ambas vulnerabilidades, se señaló como causa una falla de registro por exceder la longitud de una columna SQL, y Microsoft ya las corrigió tras ser reportadas
  • Microsoft clasificó este problema como de nivel “medio (Medium)” y lo corrigió discretamente sin recompensa ni reconocimiento oficial; según CVSS, se evalúa en nivel High (7.5~8.7 puntos)
  • Como persisten defectos causados por fallas repetidas de validación de entradas, se señala como tarea esencial para los responsables de seguridad el cruce de verificación de logs y el refuerzo de reglas de detección basadas en KQL

Se revelan vulnerabilidades de evasión de registros de inicio de sesión en Azure Entra ID

  • Desde 2023 se han descubierto un total de 4 vulnerabilidades de evasión de registros de inicio de sesión de Azure Entra ID
    • Los dos primeros casos solo permitían verificar la validez de contraseñas, pero los dos más recientes alcanzan un nivel grave al permitir incluso la emisión de tokens válidos
    • Todas las vulnerabilidades ya fueron corregidas por Microsoft

  • Resumen de GraphNinja y GraphGhost

    • GraphNinja: al intentar iniciar sesión especificando el endpoint de otro tenant, se puede saber si la contraseña es válida, pero no se genera ningún log
      • Un atacante puede enviar la solicitud de autenticación a un tenant externo y confirmar mediante la respuesta si la contraseña es correcta
      • Posteriormente, Microsoft introdujo registro adicional para resolver este problema
    • GraphGhost: si se usa un Client ID incorrecto, el flujo de autenticación falla después de validar la contraseña, y en los logs solo aparece como fallo
      • La información de que la contraseña era correcta no queda registrada en los logs del administrador
      • Microsoft lo corrigió agregando a los logs de inicio de sesión si la contraseña fue validada o no

  • Vulnerabilidad GraphGoblin

    • GraphGoblin evade la generación de logs en el flujo OAuth2 ROPC repitiendo el parámetro scope
      • Si se repite miles de veces algo como "openid openid openid ...", se emite un token válido pero no queda ningún registro en los logs de inicio de sesión de Entra ID
    • Se señaló como causa una falla de INSERT por exceder la longitud de una columna SQL
      • Se presume que el guardado del log falló porque la cadena repetida de scopes superó la longitud del campo en la base de datos
    • Microsoft tuvo dificultades para reproducir el problema, pero lo corrigió después de recibir evidencia en video

  • Graph****** (evasión basada en User-Agent)

    • Si se introduce una cadena de más de 50,000 caracteres en el campo User-Agent, no se genera ningún log
      • La solicitud de autenticación se procesa normalmente y se emite el token, pero el log se omite por completo
      • Se presume una falla de registro por exceder la longitud de una columna SQL
    • Fue descubierta el 28 de septiembre de 2025, y el 8 de octubre Microsoft ya la había corregido antes del reporte

  • Resumen de la cronología

    • 2025-09-20: primer hallazgo de GraphGoblin
    • 2025-09-26: reporte de GraphGoblin a Microsoft
    • 2025-09-28: descubrimiento de Graph******
    • 2025-10-08: corrección completada de Graph******
    • 2025-11-21: Microsoft logra reproducir GraphGoblin e inicia la corrección

Respuesta y evaluación de Microsoft

  • Microsoft clasificó esta vulnerabilidad como de nivel “medio (Medium)” y no ofreció recompensa ni reconocimiento público
    • En los dos casos anteriores (2023~2024) sí hubo recompensa y reconocimiento
    • En esta ocasión, a pesar de tratarse de un problema grave que permite emitir tokens válidos, se evaluó como no importante
  • Según CVSS v3.1 se evalúa con 7.5 puntos (High), y según v4.0 con 8.7 puntos (High)
    • La puntuación alta se debe al impacto sobre la integridad (Integrity)
    • La omisión de logs se considera una afectación directa a un componente de seguridad
  • Microsoft completó la corrección dos semanas después de reproducir el problema
    • En el pasado, la corrección de GraphNinja tomó 7 meses y la de GraphGhost, 5 meses

Cómo detectar la evasión de logs

  • Mediante una consulta KQL se pueden comparar los Session ID o UniqueTokenIdentifier de los logs de Graph Activity y los logs de Sign-In
    • Si una sesión existe en Graph Activity pero no en los logs de Sign-In, puede considerarse un inicio de sesión evadido
    • Sin embargo, se requiere una licencia E5 para recopilar logs de Graph Activity
  • Ejemplo de consulta KQL: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Si es necesario, también se puede comparar con base en SessionId
    • A partir de los resultados de detección, se puede configurar una Azure Log Search Alert Rule

Resumen de las cuatro evasiones de logs de inicio de sesión

Momento del hallazgo Método Emisión de token Reconocimiento de Microsoft
2023-08 / 2024-05 Sin generación de log de validación de contraseña al especificar un tenant ID externo X X
2024-12 / 2025-04 Inducir fallo de autenticación con un Client ID incorrecto X X
2025-09-20 Desbordamiento de columna SQL al repetir el scope O X
2025-09-28 Desbordamiento de columna SQL con una cadena larga de User-Agent O N/A

Críticas al proceso de seguridad de Microsoft

  • Se encontraron defectos en múltiples parámetros de la función de registro de inicio de sesión de Entra ID

    • Se repitieron vulnerabilidades en campos clave como tenant ID, client ID, scope, user-agent
    • No se trata de un ataque complejo, sino de un problema simple de falla en la validación de entradas
    • Se cuestiona la falta de revisión de seguridad y control de calidad de Microsoft
    • Durante años se han repetido defectos similares en la misma área
    • También se plantea la posibilidad de omisiones relacionadas con la adopción de generación de código por IA o con procesos de gestión del código

  • Falta de transparencia pública

    • En los cuatro casos no se asignó CVE ni hubo aviso oficial
    • Microsoft, como CNA, decide de forma exclusiva si divulga o no sus propias vulnerabilidades

Conclusión

  • Los logs de inicio de sesión de Azure Entra ID son datos clave para la detección de intrusiones en organizaciones de todo el mundo
    • Si faltan logs, todo el sistema de detección de ataques puede quedar inutilizado
  • Las cuatro vulnerabilidades descubiertas podían detectarse mediante fuzzing simple de entradas
  • Microsoft necesita explicaciones públicas y un proceso de revisión de seguridad más transparente frente a estos defectos repetitivos
  • Los administradores y responsables de seguridad deben reforzar sus defensas mediante verificación cruzada de logs y reglas de detección basadas en KQL

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-22
Comentarios en Hacker News

  • Hace recordar el informe sobre el incidente de Microsoft publicado por CISA
    Fue el caso en el que hackers respaldados por un Estado comprometieron a Microsoft y se infiltraron en varias agencias, incluido el Departamento de Estado de EE. UU.
    Lo sorprendente es que no fue Microsoft, sino un administrador de sistemas del Departamento de Estado, quien detectó anomalías en los logs de correo y descubrió la intrusión
    Enlace al informe de CISA

  • En un artículo de ProPublica y ArsTechnica que critica de frente a Azure, se dice que expertos federales en ciberseguridad describieron la nube de Microsoft como “pésima”
    Enlace al artículo

    • En realidad, un experto describió así la calidad de la documentación, y parece que ProPublica lo extrapoló a Azure en general
    • Ars solo lo republicó bajo licencia
    • Los ingenieros de seguridad de Azure que conozco están casi en colapso mental. De unos 12, la mitad está quemada y el resto tiene un nivel demasiado bajo
    • Bloomberg y CNBC no cubrieron este caso. Ojalá alguien se los hiciera llegar por su red de contactos en medios

  • El estado actual de la ciberseguridad es demasiado precario para sistemas de los que depende toda la civilización
    Es como salir al océano en un barco agujereado tapando las filtraciones con cinta duct tape

    • Lo peor es que la industria responde como si la solución fuera levantar más torretas de ametralladora para tapar esos agujeros

  • En la discusión sobre logs SQL, parece que el atacante envió una entrada demasiado larga y el INSERT falló por exceder la longitud de la columna
    Por eso no quedó registrado el intento de inicio de sesión

    • Eran dos servicios separados. El servicio de validación detectó el fallo y pidió al servicio de logs que lo registrara, pero aunque el servicio de logs falló, el de validación respondió igual
      Parece un problema estructural de un flujo de autenticación diseñado con demasiada complejidad

  • He tenido experiencias donde el log de auditoría de Azure registraba algo distinto de lo que realmente pasó
    Eliminé un client secret; la UI decía que estaba borrando B, pero la API actuó como si solo dejara A
    Al final quedó registrado como si yo lo hubiera hecho, cuando en realidad fue un bug del sistema
    Después de eso, no solo se me quebró la confianza en los logs de Azure, sino en la confiabilidad de los logs de auditoría en general
    Me parece arriesgado usarlos como evidencia en un juicio

    • Por eso prefiero una UI con paso de confirmación antes de aplicar cambios. Las interfaces de autoguardado “tipo videojuego” son demasiado peligrosas
    • El portal de Azure (tanto la versión nueva como la vieja) está lleno de bugs, así que tampoco sorprende. A veces aprietas mal un botón y termina cambiándose otro objeto
    • Este caso es un buen ejemplo educativo del riesgo de operaciones set vs operaciones delete en entornos de edición concurrente. El log era correcto; el problema era el diseño de la UI
    • Al final da miedo pensar que el usuario solo expresa una intención, pero la ejecución real la controla el frontend

  • Comparado con las vulnerabilidades recientes de EntraID, el bypass de logs parece menos importante

    • Pero si los logs clave de autenticación funcionan solo en modo ‘best-effort’, eso es un problema grave como base para auditorías de seguridad
    • Al final, los ataques exitosos y sigilosos suelen surgir de la combinación de varias vulnerabilidades

  • Si Microsoft ya metió una vulnerabilidad crítica hasta en Notepad, esto tampoco sorprende

  • Cuando evalué Azure VPN hace tiempo, no quedaba ningún log de éxito o fallo de conexión
    Cuando señalé el problema, Microsoft me dijo que lo registrara como una solicitud de nueva función
    Ahí fue cuando perdí por completo la confianza en Azure. Y con el tiempo no da la impresión de haber mejorado, sino de haber empeorado

  • Los administradores de TI siguen usando Microsoft porque no tienen alternativa

    • En entornos como el mío, donde hay que gestionar aplicaciones LOB basadas en .NET y varios SaaS, las soluciones de Microsoft son la opción más realista
      Con poco presupuesto y poco personal, uno solo lo mantiene en un estado lo bastante funcional como para cobrar y salir del trabajo
    • Los administradores más jóvenes tienden a odiar Microsoft. Puede que sea una diferencia generacional
    • Como dice la frase: “nadie fue despedido por comprar X”; elegir Microsoft implica poco riesgo para la carrera

  • Cuando Microsoft no pudo reproducir la vulnerabilidad de Azure y pidió evidencia en video, fue impresionante que se la demostraran con una sola línea de comando curl
    De verdad fue un momento muy satisfactorio