Vulnerabilidad en Microsoft Entra ID permite eludir Políticas de Acceso Condicional mediante Autenticación de Aplicaciones Anidadas (NAA) 

Se ha emitido un informe de inteligencia de amenazas basado en una reciente investigación de la firma de seguridad NetSPI, la cual ha revelado un método para eludir por completo las Políticas de Acceso Condicional (CAP) de Microsoft Entra ID. La técnica abusa del marco de Autenticación de Aplicaciones Anidadas (Nested App Authentication – NAA) utilizado por Microsoft para el inicio de sesión único (SSO), permitiendo a un atacante obtener tokens de acceso válidos para la API de Microsoft Graph sin ser sometido a las evaluaciones de seguridad (como verificación de IP, estado del dispositivo o MFA) que dictan las políticas. 


Veredicto Analítico 
  • Estado: Confirmado (El problema fue reportado al Microsoft Security Response Center – MSRC, quienes lo clasificaron como una vulnerabilidad de severidad media). 
  • Riesgo para SOC TDIR: Medio-Alto. Aunque el ataque requiere que el adversario ya posea un token de actualización (refresh token) inicial (obtenido típicamente mediante phishing o robo de sesión), esta técnica proporciona un mecanismo de persistencia sigilosa extremadamente poderoso. Permite moverse por el entorno en la nube ignorando todas las vallas de seguridad condicionales establecidas por la organización. 
  • Urgencia operativa: Media. Dado que la mitigación recae principalmente en la arquitectura de Microsoft (Cloud/Backend), el equipo de defensa debe enfocarse en la detección proactiva de anomalías en los registros de auditoría de Entra ID. 
  • Base del veredicto: Abuso de los flujos de re-emisión de tokens OAuth (SSO Broker) en clientes nativos como ADIbizaUX (Azure Portal). 

Hallazgos Clave 
  • Componente Afectado: Motor de evaluación de Políticas de Acceso Condicional de Microsoft Entra ID y el flujo de Autenticación de Aplicaciones Anidadas (NAA). 
  • Cliente Específico Abusado: El cliente de primera parte ADIbizaUX, que es un componente altamente utilizado del Portal de Azure para la gestión de identidad y acceso. 
  • Naturaleza del Fallo: El marco NAA permite que aplicaciones “anfitrionas” (como el Portal de Azure) actúen como intermediarios. Intercambian silenciosamente su token de actualización en caché por un nuevo token de acceso para una aplicación secundaria. Bajo ciertas condiciones (al usar ADIbizaUX), la validación de las Políticas de Acceso Condicional se omite de forma inadvertida durante la re-emisión del token para Microsoft Graph. 
  • Limitación Ofensiva: Los tokens generados tienen una vida útil fija (usualmente 24 horas) y comportamiento no renovable, limitando la ventana, pero otorgando tiempo suficiente para la extracción de datos o la post-explotación en el tenant. 

Análisis Técnico 
  • Mecanismo de Explotación: El atacante, poseyendo un token de actualización comprometido, formula una petición OAuth 2.0 modificada. Utiliza parámetros específicos de intermediación (brokering) como brk_client_id y brk_redirect_uri para simular que la petición proviene del flujo NAA legítimo del Portal de Azure (ADIbizaUX). 
  • Efecto de Omisión: Al procesar esta solicitud específica hacia Microsoft Graph, Entra ID confía erróneamente en el contexto del intermediario y no re-evalúa las Políticas de Acceso Condicional (ej. no exige que la IP coincida con una ubicación nombrada, o que el dispositivo esté marcado como “Compliant” en Intune). El atacante recibe un token de acceso válido de Microsoft Graph. 

TTPs (MITRE ATT&CK)
  • Acceso Inicial / Persistencia: Uso de material de autenticación robado o alternativo (Use Alternate Authentication Material: Application Access Token – T1550.003). 
  • Evasión de Defensas: Subversión de controles de identidad en la nube (Bypass Conditional Access / Subvert Trust Controls – T1562). 
  • Acceso a Credenciales: Falsificación de flujos de tickets/tokens web (Steal or Forge Authentication Certificates/Tokens). 

Recomendaciones Operativas 

Para Ingeniería de Seguridad en la Nube y TI 

  • Revocación Continua de Acceso (CAE): Asegurarse de que Continuous Access Evaluation (CAE) esté habilitada en el entorno (si el licenciamiento lo permite). CAE permite que Entra ID revoque tokens de acceso casi en tiempo real frente a eventos críticos (como el cambio de contraseña o anomalías de red severas), mitigando en parte la vida útil de 24 horas del token comprometido. 
  • Restricción de Consentimiento de Aplicaciones: Reforzar las políticas para evitar que los usuarios puedan otorgar consentimiento a aplicaciones de terceros (Illicit Consent Grant), dado que la obtención de tokens iniciales suele derivar de campañas de phishing de OAuth. 

Para el SOC (Monitoreo y Detección) 

  • Auditoría de Inicios de Sesión y Tokens: Inspeccionar los Sign-in Logs de Microsoft Entra ID. Buscar patrones anómalos donde el AppDisplayName sea ADIbizaUX (o sus Client IDs asociados) solicitando acceso al recurso de Microsoft Graph API desde direcciones IP inusuales, o nodos de VPN anónima (Tor/Proxies residenciales), especialmente si las banderas de Acceso Condicional marcan “Not Applied” (No aplicado) en contextos donde deberían ser obligatorias. 
  • Correlación de Phishing Previo: Este ataque es de “Fase 2”. Si se detecta a un usuario cayendo en phishing (Ej. ataques AiTM / EvilGinx que roban cookies de sesión), se deben invalidar inmediatamente todos los refresh tokens de la cuenta mediante el comando de PowerShell Revoke-EntraUserAllRefreshToken (o equivalente en el portal de Azure), bloqueando al atacante antes de que intente el bypass de NAA. 

Related Post