Una combinación peligrosa de componentes antiguos en el ecosistema de Microsoft podría haber abierto la puerta al control total de cualquier inquilino de Entra ID en el mundo.
Todo se reducía a dos piezas clave: unos tokens no documentados, conocidos como actor tokens, y una vulnerabilidad en la API heredada de Azure AD Graph (identificada como CVE-2025-55241). Juntas, estas fallas permitían que un atacante generara tokens válidos para el entorno Entra ID de cualquier empresa, sin restricciones.
¿El resultado? Un actor malicioso podría haber accedido a datos extremadamente sensibles (como correos electrónicos, archivos internos, configuraciones administrativas y más) sin activar ninguna alerta visible en los registros del entorno comprometido. La única huella sería lo que hiciera con ese acceso.
En TecnetOne queremos contarte cómo funcionaba este tipo de falla, por qué representa un riesgo real para las empresas y qué acciones puedes tomar para fortalecer la seguridad de tu infraestructura.
Microsoft Entra ID (antes conocido como Azure Active Directory o Azure AD) es el sistema central de identidad y control de acceso en la nube de Microsoft. Permite a las organizaciones gestionar quién puede acceder a qué, tanto dentro como fuera de su red corporativa.
Con Entra ID, las empresas proporcionan inicio de sesión único (SSO), autenticación multifactor (MFA) y políticas de seguridad para acceder a servicios críticos como:
Microsoft 365 (Outlook, Teams, SharePoint, etc.)
Aplicaciones personalizadas en la nube o locales
Plataformas SaaS como Salesforce, Google Workspace, Dropbox, SAP o AWS
Cada tenant de Entra ID representa una organización distinta, con su propio conjunto de usuarios, roles, políticas y aplicaciones. Por eso, comprometer un tenant es equivalente a comprometer toda la empresa: acceso a correos, archivos, identidades, bases de datos y más.
El fallo permitía que un atacante se hiciera pasar por una aplicación legítima y obtuviera permisos de administrador global, el rol más alto dentro de cualquier tenant de Entra ID. Esto significa:
Control total sobre usuarios y grupos
Modificación o eliminación de configuraciones de seguridad
Acceso a datos protegidos
Interacción con cualquier servicio autenticado vía Entra ID
Y todo esto, sin que nadie lo note… al menos, no de inmediato.
Uno de los descubrimientos más impactantes relacionados con la falla de Entra ID fue la posibilidad de suplantar a cualquier usuario dentro de un inquilino, gracias al uso de unos tokens poco conocidos llamados "tokens de actor" (actor tokens).
Estos tokens eran emitidos por un servicio heredado de Microsoft llamado Access Control Service (ACS). Originalmente, este sistema fue creado para permitir la autenticación con aplicaciones como SharePoint y todavía es utilizado internamente por Microsoft para ciertas comunicaciones entre servicios.
El origen del hallazgo surgió al investigar configuraciones híbridas de Exchange. Durante ese análisis, se observó que Exchange solicitaba estos tokens al comunicarse con otros servicios en nombre de un usuario. Es decir, el token le permitía a una aplicación o servicio "actuar" como si fuera ese usuario, con acceso a servicios como Exchange Online, SharePoint y, por extensión, Azure AD Graph API.
Lo más grave es que estos tokens de actor no estaban firmados digitalmente, lo que abría una gran brecha de seguridad:
Podían ser utilizados para suplantar a cualquier usuario del inquilino.
Tenían una validez de 24 horas, durante las cuales no podían ser revocados.
No dejaban rastros en los registros estándar de Entra ID, ni cuando eran emitidos ni cuando se usaban.
Saltaban por completo las políticas de acceso condicional configuradas por las empresas.
Solo quedaba confiar en los registros del servicio de destino para detectar si se habían utilizado.
Esto significa que un atacante que lograra generar uno de estos tokens podía operar durante un día completo con privilegios de otro usuario (incluyendo administradores) sin dejar evidencia clara en los logs de seguridad centralizados.
Además, dado que estos tokens podían ser creados sin intervención de Entra ID (lo que implica que no pasaban por sus mecanismos de validación), no existía forma efectiva de auditar su emisión desde la plataforma principal de identidad.
El error de Azure AD Graph indica que el token es válido pero el usuario no existe
Podría interesarte leer: Microsoft y Cloudflare Desmantelan RaccoonO365 de Phishing
El investigador Dirk-jan Mollema reportó la vulnerabilidad a Microsoft a mediados de julio de 2025. En respuesta, el equipo de seguridad de Redmond actuó con rapidez: investigaron el problema, aplicaron mitigaciones directamente en la nube y limitaron el uso de los tokens de actor que hacían posible este tipo de suplantación.
Poco después, Microsoft confirmó que había solucionado el fallo y asignó el identificador oficial CVE-2025-55241, además de publicar una guía de seguridad para que los administradores revisaran sus configuraciones. Según los informes disponibles, las correcciones técnicas se implementaron en julio, mientras que la divulgación pública del CVE y sus detalles ocurrió en septiembre de 2025.
En cuanto a su investigación interna, Microsoft indicó que no encontró evidencia de explotación activa de la vulnerabilidad, aunque como suele ocurrir en estos casos, la ausencia de evidencia no garantiza que no haya sido utilizada en algún entorno no monitoreado.
Aunque Microsoft ya implementó mitigaciones a nivel de plataforma, eso no significa que el riesgo esté completamente controlado. Cada organización debe asumir que las actualizaciones del proveedor son necesarias, pero no siempre suficientes. A continuación, te compartimos una serie de recomendaciones clave para reforzar la seguridad de tu entorno:
Verifica que tu tenant de Microsoft esté ejecutando las protecciones más recientes de Entra ID.
Asegúrate de que las mitigaciones aplicadas por Microsoft para CVE-2025-55241 estén implementadas correctamente en tu organización.
Revisa los roles administrativos y elimina cualquier administrador global innecesario.
Siempre que sea posible, implementa modelos de acceso con Just-In-Time (JIT) y Just-Enough Access (JEA) para reducir la exposición a accesos innecesarios.
Refuerza la telemetría a nivel de API para tener trazabilidad de los accesos, especialmente con servicios como Graph API.
Centraliza los registros en una solución SIEM (como el SOC de TecnetOne) y configura alertas específicas para detectar comportamientos anómalos entre inquilinos.
Asegúrate de tener políticas de acceso condicional bien definidas y actualizadas.
Revisa las aplicaciones o integraciones heredadas que aún puedan depender de tokens antiguos o de API obsoletas, como Azure AD Graph, que Microsoft está reemplazando por Microsoft Graph.
Aunque el problema ya fue solucionado técnicamente, esta situación es un claro recordatorio de los riesgos que pueden surgir cuando se mantienen componentes heredados o configuraciones no revisadas en la infraestructura de identidad.
Desde TecnetOne, recomendamos no depender únicamente de los parches automáticos. Una estrategia de seguridad robusta implica auditorías periódicas, monitoreo activo, gestión de parches, eliminación de accesos innecesarios y una migración ordenada hacia tecnologías modernas y seguras.