Vulnerabilidad en Entra ID: Autenticación de aplicaciones anidadas permitió eludir MFA y políticas de acceso condicional

El 22 de junio de 2026, el investigador de NetSPI Thomas Byrne reveló públicamente una vulnerabilidad en el marco de Autenticación de Aplicaciones Anidadas (NAA) de Microsoft Entra ID, también conocido como BroCI, que permitía a los atacantes eludir cualquier Política de Acceso Condicional (CAP), incluyendo los requisitos de autenticación multifactor (MFA), las comprobaciones de cumplimiento del dispositivo y los controles basados en la ubicación . La falla fue corregida por Microsoft del lado del servidor como un problema de gravedad media, pero su divulgación marcó un momento significativo para la seguridad de las identidades, ya que se reveló junto con un segundo método de elusión independiente y una serie de cambios de aplicación por parte de Microsoft.

La Vulnerabilidad: Cómo NAA Permitía Eludir Todos los Controles

La Autenticación de Aplicaciones Anidadas es un mecanismo personalizado de inicio de sesión único (SSO) de OAuth de Microsoft diseñado para permitir que una aplicación "anfitriona", como el Portal de Azure, realice intercambios de tokens de forma silenciosa para aplicaciones secundarias anidadas sin volver a solicitar credenciales al usuario . Funciona incrustando parámetros especiales (brk_client_id, brk_redirect_uri) en las solicitudes de token OAuth estándar a login.microsoftonline.com .

Byrne descubrió que este mecanismo tenía una falla crítica. La vulnerabilidad afectaba específicamente a los flujos en los que el cliente ADIbizaUX —el componente de gestión de IAM del Portal de Azure— intermediaba un token de actualización del Portal de Azure en caché para solicitar un token de acceso para la API de Microsoft Graph . Normalmente, los intercambios de tokens de actualización están sujetos a la evaluación de Acceso Condicional, pero NetSPI descubrió que al usar el flujo NAA con ADIbizaUX contra el recurso de Microsoft Graph, las Políticas de Acceso Condicional no se evaluaban en absoluto . Se emitía un token de acceso independientemente de las políticas configuradas. También se encontró que otros dos ID de cliente de la extensión del portal de Microsoft Intune presentaban el mismo comportamiento de elusión .

El Escenario de Ataque: Persistencia Posterior al Compromiso Sin Detección

El ataque requiere una condición previa específica —un token de actualización del Portal de Azure robado— pero es muy efectivo para la persistencia posterior al compromiso y el movimiento lateral . El escenario se desarrolla en cuatro pasos:

1. Compromiso inicial: Un atacante roba un token de actualización válido del Portal de Azure, por ejemplo, mediante phishing, ataques de proxy adversario en el medio (AITM) dirigidos a login.microsoftonline.com u otros métodos de robo de tokens .
2. Intermediación de tokens vía NAA: El atacante utiliza el token de actualización del Portal de Azure robado y el flujo de intermediación NAA (a través de ADIbizaUX o las extensiones del portal de Intune) para intercambiarlo silenciosamente por un token de acceso a Microsoft Graph .
3. Elusión de todos los controles: El token de Graph se emite sin ninguna evaluación de Acceso Condicional —sin solicitud de MFA, sin verificación de cumplimiento del dispositivo, sin restricción de ubicación— incluso si esas políticas están configuradas explícitamente .
4. Persistencia y movimiento lateral: ADIbizaUX posee amplios permisos de Graph previamente consentidos y expone APIs no documentadas para gestionar usuarios, grupos, directores de servicio, aplicaciones, directorios e incluso políticas de Acceso Condicional, todo ello sin registro, lo que significa que las acciones pasan completamente desapercibidas .

La vulnerabilidad tiene limitaciones. El token de actualización del Portal de Azure robado tiene una vida útil fija de 24 horas y no es renovable, lo que limita la ventana de persistencia . El atacante ya debe tener el token de actualización de la víctima, lo que convierte esta técnica en una técnica de escalada y persistencia posterior al compromiso, no en una ejecución remota de código . No obstante, la elusión fue clasificada como de gravedad media por el Centro de Respuesta de Seguridad de Microsoft (MSRC) .

Respuesta de Microsoft: Corrección del Lado del Servidor Sin CVE

NetSPI informó el problema al MSRC el 17 de marzo de 2026 . El MSRC lo clasificó como una vulnerabilidad de gravedad media e implementó una corrección del lado del servidor. Las pruebas posteriores al parche confirmaron que los flujos NAA que antes tenían éxito ahora devuelven correctamente errores de acceso bloqueado AADSTS53003 cuando se aplica una política de Acceso Condicional . Microsoft no asignó un CVE para este problema específico y la corrección no requirió ninguna acción por parte del cliente .

Contexto Más Amplio: Dos Elusiones de Acceso Condicional Reveladas el Mismo Día

El 22 de junio de 2026, los investigadores revelaron dos métodos separados de elusión de Acceso Condicional de Entra en el mismo día :

Hallazgo	Fuente	Mecanismo	Respuesta de Microsoft
Elusión de NAA / BroCI	NetSPI (Thomas Byrne)	Abuso de la intermediación de tokens de Autenticación de Aplicaciones Anidadas a través de ADIbizaUX y las extensiones del portal de Intune	Corrección de gravedad media del MSRC; ahora devuelve AADSTS53003
Elusión por exclusión de recursos	Dirk-jan Molenaar (dirkjanm.io)	Las políticas dirigidas a "Todos los recursos" con al menos un recurso excluido podían ser eludidas para tokens de Graph utilizando solo ámbitos básicos de OIDC/directorio	Microsoft lo reconoció y comenzó a implementar la aplicación de ámbitos básicos a partir del 15 de junio de 2026; adhesión anticipada disponible en el Centro de Administración de Entra

Cambios en la Aplicación del Acceso Condicional de Microsoft en 2026

Además de corregir la elusión de NAA, Microsoft ha ido cerrando progresivamente las brechas en la aplicación del Acceso Condicional a lo largo de 2026:

• 27 de marzo de 2026 – junio de 2026 (de forma gradual): Microsoft cambió la forma en que se aplican las políticas de CA dirigidas a "Todos los recursos" cuando esas políticas incluyen exclusiones de recursos. Anteriormente, los inicios de sesión que solicitaban solo ámbitos básicos de OIDC (como openid, profile, User.Read) podían eludir el Acceso Condicional por completo si una política tenía alguna exclusión de recursos. El cambio de aplicación garantiza que las políticas con exclusiones sigan evaluándose en el ámbito de "Todos los recursos" . Microsoft notificó a los inquilinos afectados a través de la entrada del Centro de mensajes MC1223829 .

• 15 de junio de 2026: Microsoft comenzó la aplicación de la aplicación de ámbitos básicos específicamente para la elusión por exclusión de recursos, cerrando la ruta de elusión de tokens de Graph que Dirk-jan Molenaar divulgó .

• 31 de marzo de 2026: Microsoft hizo cumplir la jubilación de la autenticación sin director de servicio para aplicaciones multiinquilino que no son de Microsoft. Todas las aplicaciones deben autenticarse utilizando un director de servicio registrado; de lo contrario, los flujos de inicio de sesión fallarán .

• Junio de 2026: Microsoft anunció actualizaciones de seguridad más amplias de Entra ID, incluida la sustitución de controles personalizados por MFA externo, la aplicación coherente del Acceso Condicional durante el registro de credenciales y la exigencia de métodos de autenticación registrados explícitamente para el autoservicio de restablecimiento de contraseña (SSPR) .

Conclusiones Clave para Defensores

• La elusión de NAA se ha corregido del lado del servidor. No se necesita ninguna acción por parte del inquilino para el hallazgo específico de NetSPI .
• Para la elusión por exclusión de recursos, habilite la opción de aplicación de ámbitos básicos en el Centro de Administración de Entra para garantizar una evaluación adecuada de la CA .
• Supervise el código de error AADSTS53003, que ahora bloquea correctamente los intercambios de tokens NAA no autorizados .
• Las API no documentadas de ADIbizaUX que pueden operar sin registro siguen siendo una preocupación: las organizaciones deben monitorear de cerca los registros de inicio de sesión del Portal de Azure y los patrones de emisión de tokens .
• Con la autenticación sin director de servicio retirada a partir del 31 de marzo de 2026, asegúrese de que todas las aplicaciones multiinquilino tengan directores de servicio registrados .