CVE-2025-55241: Entra ID suplantación de token de actor podía comprometer a cualquier administrador global

Qué fue CVE-2025-55241: la falla de suplantación por token Actor en Entra ID

CVE-2025-55241 es una vulnerabilidad de elevación de privilegios en Microsoft Entra ID basada en la suplantación mediante token Actor de Entra ID, descubierta por el investigador de seguridad independiente Dirk-jan Mollema y reportada al Microsoft Security Response Center (MSRC) el 14 de julio de 2025. La puntuación CVE otorgada por el propio Microsoft fue CVSS 10.0 (Crítico); el recálculo independiente de NVD la situó en 9.8 (Crítico), con una clasificación CWE-287 (autenticación incorrecta). Microsoft asignó el CVE el 4 de septiembre de 2025 y declaró que no se requería ninguna acción por parte del cliente, ya que la corrección ya se había desplegado en todos los tenants.

La falla combinaba dos elementos: un tipo de token interno de Microsoft, no documentado, llamado "token Actor", y un fallo de validación de tenant en la API Azure AD Graph heredada (graph.windows.net). Combinados, permitían que el poseedor de un token Actor de su propio tenant (controlado por el atacante) se autenticara como cualquier usuario —incluidos administradores globales— en cualquier otro tenant de Entra ID, sin necesitar las credenciales de ese usuario, sin activar el MFA y sin generar el rastro de auditoría en el que los defensores normalmente confían. Mollema describió la exposición como capaz de comprometer "todos los tenants de Entra ID del mundo", con excepción de las nubes nacionales/soberanas.

🚨 Peligro: no hay evidencia de explotación activa, según Microsoft y Mollema. Esta es una explicación retrospectiva de una vulnerabilidad que Microsoft ya corrigió globalmente, no una amenaza activa que requiera una acción de emergencia hoy.

Cronología de la divulgación

• 14 de julio de 2025 — Mollema reporta el problema al MSRC; el MSRC abre un caso el mismo día.
• 17 de julio de 2025 — Microsoft despliega en producción una corrección para el fallo de validación de tenant en la API Azure AD Graph.
• 23 de julio de 2025 — El MSRC confirma a Mollema que el problema principal está resuelto.
• 6 de agosto de 2025 — Microsoft despliega mitigaciones adicionales que restringen la emisión de tokens Actor para la API Azure AD Graph exclusivamente a servicios internos de Microsoft.
• 4 de septiembre de 2025 — Microsoft asigna formalmente el CVE-2025-55241 y declara que no se requiere ninguna acción del cliente.
• 17 de septiembre de 2025 — Mollema publica el análisis técnico completo, incluyendo guía de detección.

Cómo funcionaba la elusión mediante token Actor

Los tokens Actor son emitidos por el Access Control Service (ACS) de Microsoft para la delegación servicio a servicio —el mecanismo que permite que backends propios de Microsoft, como Exchange Online, "actúen como" un usuario al llamar a otros servicios de Microsoft en nombre de ese usuario. Según el análisis de Mollema, los tokens Actor incluyen una declaración (claim) trustedfordelegation y, una vez emitidos, permiten efectivamente suplantar a cualquier usuario de un tenant durante un máximo de 24 horas. Se trata de un mecanismo interno legítimo y de larga data —la vulnerabilidad estaba en cómo un consumidor heredado de estos tokens los validaba, no en la existencia del mecanismo en sí.

Dos fallos de diseño hacían esto explotable más allá de los límites de un tenant:

Origen de tenant no validado

La API Azure AD Graph heredada no verificaba correctamente que el ID de tenant incluido en las declaraciones de suplantación de un token Actor coincidiera con el tenant realmente consultado. Como la carga útil de suplantación se transportaba en un JWT sin firmar, un atacante podía sustituir el ID de su propio tenant por el de un tenant objetivo sin invalidar la firma del token —porque no había ninguna que romper. Eso permitía repetir un token emitido para el tenant del atacante como si procediera de cualquier otro tenant del planeta.

Identificadores de usuario predecibles (netId)

El objetivo de la suplantación dentro del tenant de destino se resolvía mediante netId, un identificador heredado de Microsoft Passport que aún persiste en algunos componentes internos de Entra. A diferencia de un ID de objeto de Entra (un GUID aleatorio), los valores netId se incrementan de forma predecible. Mollema descubrió que podían obtenerse por fuerza bruta en "minutos a horas" para un tenant objetivo, y también podían recolectarse directamente de los atributos alternativeSecurityIds de usuarios invitados en relaciones de confianza B2B, o de tokens filtrados en registros, tickets de soporte y capturas de pantalla públicas.

En conjunto: un atacante que pudiera solicitar un token Actor desde cualquier tenant que controlara —incluido un tenant gratuito o de prueba— podía reescribir el ID del tenant objetivo y emparejarlo con un netId resuelto, y la API Azure AD Graph heredada aceptaba la suplantación resultante. Eso otorgaba acceso de lectura y escritura a los datos del directorio, la capacidad de crear entidades de servicio, cambiar asignaciones de roles y modificar políticas de acceso condicional actuando como el usuario que el token afirmaba ser, hasta llegar a un administrador global.

Por qué el MFA, el acceso condicional y el registro no podían detectarlo

Esta es la parte que convertía la falla en crítica y no simplemente grave: la elusión operaba por debajo de los controles en los que los tenants confían para detectar el compromiso de una cuenta.

• El MFA y el acceso condicional no aplican. Los tokens Actor son un mecanismo de delegación servicio a servicio, no un inicio de sesión interactivo —no pasan en absoluto por el motor de políticas de acceso condicional, por lo que el MFA por usuario, el riesgo de inicio de sesión y los requisitos de cumplimiento de dispositivos simplemente no se evalúan. Un recordatorio de que el MFA por sí solo nunca fue un control completo —solo cubre las rutas de autenticación a las que realmente está conectado.
• Solicitar el token no genera ningún registro. Según el análisis de Mollema, obtener un token Actor no produce ninguna entrada de registro visible para el tenant —un atacante podía preparar el ataque sin dejar ningún rastro en el tenant objetivo.
• La API Graph heredada registra de forma insuficiente. graph.windows.net es anterior a la profundidad de registro que ofrecen Microsoft Graph y el pipeline de auditoría moderno de Entra, por lo que incluso las acciones realizadas con el token de suplantación solo se capturaban parcialmente.
• El token era, en la práctica, irrevocable durante su vigencia. Al ser un JWT autocontenido y sin firmar, válido hasta 24 horas, un token Actor filtrado o falsificado no podía invalidarse a mitad de camino como sí puede hacerse con un token de sesión comprometido.

Detección: qué buscar

Como la corrección de Microsoft cerró la ruta de acceso subyacente, la detección aquí es retrospectiva —revisar el historial de auditoría de Entra en busca de señales de que la técnica se usó contra su tenant antes de la corrección— en lugar de un control de monitoreo en vivo. Mollema publicó una consulta KQL exactamente para esto: los cambios impulsados por token Actor siguen apareciendo en AuditLogs, pero con una discrepancia reveladora entre el nombre visible del servicio que actúa y el contexto real que inició la acción.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

Qué no detecta esta consulta

Esta consulta, adaptada del análisis publicado por Mollema, señala las modificaciones de directorio realizadas mediante suplantación por token Actor. No detecta el reconocimiento de solo lectura —enumeración de usuarios o grupos, recolección de secretos, revisión de políticas— que la API heredada no registraba con suficiente detalle para reconstruirse a posteriori. Trate un resultado limpio de esta consulta como evidencia de que no encontró actividad de escritura por esta vía, no como prueba de que el tenant nunca fue leído.

Remediación

La propia corrección de Microsoft no requería ninguna acción del cliente: el MSRC confirmó que el problema de validación de tenant quedó resuelto el 23 de julio de 2025, y para el 6 de agosto de 2025 restringió aún más la emisión de tokens Actor para la API Azure AD Graph exclusivamente a servicios internos de Microsoft. Eso cierra esta cadena específica. La remediación duradera para los tenants consiste en reducir la dependencia de la superficie heredada y los patrones de privilegios que esta falla explotaba:

1. Elimine las dependencias de Azure AD Graph. Audite sus registros de aplicaciones y entidades de servicio en busca de las que aún llamen a Azure AD Graph y migrarlas a Microsoft Graph; cada dependencia que elimina es una superficie menos expuesta al siguiente fallo de validación de una API heredada.
2. Elimine las asignaciones permanentes de administrador global. El peor escenario de esta falla era la suplantación completa de un administrador global. Trasladar los roles de administración a una activación justo a tiempo mediante Privileged Identity Management (PIM) reduce el número de cuentas que una suplantación exitosa podría llegar a usar de forma significativa.
3. Exija MFA resistente al phishing en cada rol privilegiado, no solo en el inicio de sesión interactivo en general —esto no detiene una elusión mediante token servicio a servicio como los tokens Actor, pero sí cierra la vía mucho más común que los atacantes realmente usan para llegar a las cuentas de administrador.
4. Bloquee la autenticación heredada en todo el tenant mediante acceso condicional. La autenticación heredada no admite la validación moderna de tokens ni la aplicación del acceso condicional, y los tenants que aún permiten autenticación heredada o dejan brechas abiertas en el acceso condicional amplían la misma categoría de exposición que hizo tan grave esta vulnerabilidad: rutas de autenticación que el plano de control moderno no puede ver.
5. Revise la retención y las alertas de AuditLogs de Entra para el patrón de iniciador anómalo descrito arriba, de modo que cualquier futura elusión por suplantación de un servicio propio genere una alerta en lugar de silencio. Una auditoría de seguridad de Entra ID más amplia cubre esto junto con el resto de la postura de su tenant, incluyendo los ajustes predeterminados con los que se entregan los nuevos tenants.

Por qué la API heredada importaba más allá de este CVE

Microsoft ha estado retirando graph.windows.net por etapas desde su anuncio de descontinuación en 2019: las aplicaciones nuevas quedaron bloqueadas desde su primer uso a partir del 31 de agosto de 2024, y desde el 1 de febrero de 2025 se requiere en todo el tenant una activación opcional (opt-in) para el acceso extendido, con las apps que no la activan perdiendo el acceso por completo. Microsoft ha declarado claramente que no realiza más inversión en Azure AD Graph más allá de correcciones de seguridad, y que toda nueva funcionalidad va a Microsoft Graph. CVE-2025-55241 es una ilustración concreta de por qué esa migración importa más allá de una casilla de cumplimiento: una superficie de API descontinuada, poco registrada y poco mantenida es exactamente donde un fallo de validación como este pasa desapercibido durante más tiempo.

Cómo lo detecta EtcSec

La auditoría de Entra ID de EtcSec no tiene visibilidad sobre la infraestructura interna de tokens Actor de Microsoft —ese plano de control está enteramente dentro de la infraestructura de Microsoft y nunca fue algo que una auditoría del lado del tenant pudiera observar o corregir directamente. Lo que EtcSec sí verifica, de forma continua, es el conjunto de condiciones del lado del tenant que determinan cuánto daño puede causar cualquier elusión de tipo suplantación (esta u la siguiente): asignaciones permanentes de administrador global (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), cuentas de administrador sin MFA fuerte (PA_GLOBAL_ADMIN_NOT_MFA), y tenants que aún permiten rutas de autenticación heredada fuera de la aplicación del acceso condicional (CA_NO_LEGACY_AUTH_BLOCK).