Principales resultados
- Tras probar 38 aplicaciones adicionales desde nuestra investigación inicial, Semperis encontró dos que eran vulnerables al abuso de nOAuth. Hemos comunicado nuestros hallazgos sobre esas dos aplicaciones a los proveedores de software.
- Una de las aplicaciones vulnerables tenía permisos que permitirían a un atacante volver a Microsoft 365, lo que refuerza la idea de que nOAuth puede poner en peligro no solo los datos de la aplicación SaaS, sino también el patrimonio de Microsoft 365 de una organización.
- En nuestro último caso con el Centro de Respuesta de Seguridad de Microsoft, MSRC ha calificado esta vulnerabilidad como moderada. Sin embargo, Semperis mantiene nuestra calificación de GRAVE. nOAuth sigue siendo difícil de detectar para los clientes de aplicaciones vulnerables e imposible de defender para los clientes de aplicaciones vulnerables. El abuso está documentado públicamente y es de baja complejidad una vez que se encuentra una aplicación vulnerable.
Este artículo es una continuación de nuestra investigación original sobre nOAuth. Aunque parece que fue ayer cuando publicamos esos hallazgos en TROOPERS25 y en fwd:cloudsec 2025, nuestra investigación comenzó en otoño de 2024.
Tras realizar investigaciones adicionales sobre nOAuth seis meses después de nuestra charla original y, de nuevo, un año después de nuestra investigación inicial, hemos descubierto que el riesgo de abuso de nOAuth sigue existiendo y que muchas organizaciones aún desconocen esta vulnerabilidad.
Durante octubre y noviembre de 2025, probamos 38 aplicaciones adicionales para detectar abusos de nOAuth y encontramos 2 que eran vulnerables. Durante nuestra investigación anterior, probamos 104 aplicaciones y encontramos 9 vulnerables. Eso significa que, en porcentaje acumulativo, aproximadamente el 8 % de las aplicaciones disponibles son vulnerables a nOAuth.
Comprender cómo se integran las aplicaciones SaaS con Microsoft 365
Microsoft Graph API es la API unificada para acceder a todo Microsoft 365: Exchange Online, SharePoint, OneDrive y la mayoría de los demás servicios de Microsoft 365. Las aplicaciones SaaS de terceros que desean integrarse con estos servicios solicitan acceso a Microsoft Graph para poder interactuar con los datos o servicios de los usuarios en su nombre.
Un ejemplo es Calendly, que solicita permisos para acceder al calendario del usuario con el fin de gestionar sus citas en Office 365 (Figura 1). Para mayor claridad, Calendly no es vulnerable a nOAuth. Simplemente lo utilizamos como aplicación de referencia para ayudarle a comprender el comportamiento habitual de las aplicaciones SaaS.
Cuando un usuario accede a la aplicación, siempre que se hayan concedido los permisos, la aplicación SaaS recibe un token de acceso OAuth 2.0 de Entra ID. A continuación, la aplicación utiliza ese token de acceso con la API de Microsoft Graph para acceder al servicio. En este ejemplo, el token de acceso proporcionado a Calendly tiene permisos Calendar.ReadWrite y Calendar.ReadWrite.Shared.
En muchos casos, la aplicación SaaS también recibe un token de actualización (Figura 2). Este token permite a la aplicación SaaS mantener el acceso a los datos del usuario, incluso si este no está utilizando activamente la aplicación.
¿Por qué las aplicaciones SaaS necesitan este tipo de acceso? En nuestro ejemplo, este acceso permite a Calendly reservar citas con clientes en tu calendario, incluso si no estás utilizando activamente la aplicación. De esta manera, la aplicación SaaS puede seguir haciendo «cosas» con tus datos entre bastidores.
Esto es excelente para la productividad, y no hay nada intrínsecamente incorrecto en los permisos solicitados. Pero cuando esos permisos se combinan con la vulnerabilidad a nOAuth, se crea el escenario perfecto para que los atacantes abusen de la aplicación y, potencialmente, vuelvan a Microsoft 365.
La diferencia entre autenticación y autorización
Para comprender plenamente cómo nOAuth puede facilitar el retorno a Microsoft 365, es necesario saber que OpenID Connect (OIDC) facilita la autenticación con un token de identificación, y OAuth 2.0 facilita la autorización con un token de acceso. Cuando un token de actualización acompaña a un token de acceso, la aplicación SaaS puede obtener nuevos tokens de acceso independientemente de si el usuario está autenticado.
Dejando a un lado los matices del lenguaje de identidad, OIDC facilita el inicio de sesión de un usuario en una aplicación. OAuth 2.0 facilita los permisos que una aplicación tiene sobre los datos de un usuario. Un token de actualización permite a la aplicación acceder a los datos del usuario, incluso si este no ha iniciado sesión (Figura 3).
Cuando un usuario accede por primera vez a una aplicación, es posible que se produzca un proceso de autenticación y autorización: la aplicación puede recibir un token de identificación del usuario y un token de acceso para que la aplicación pueda acceder a los recursos de Microsoft 365. Para el usuario final, este proceso suele ser transparente, excepto cuando la aplicación nunca se ha utilizado y se necesita su consentimiento.
Existen numerosos marcos y bibliotecas para gestionar tokens, pero en última instancia es el desarrollador de aplicaciones SaaS quien determina cómo se gestionan los tokens.
Cuando un usuario se autentica posteriormente, la aplicación puede (o no) intentar solicitar un nuevo token de acceso y actualización, si los tokens existentes siguen siendo válidos. Dado que la autenticación y la autorización se tratan esencialmente como funciones diferentes, esta desconexión entre los dos flujos permite a los atacantes pivotar.
Abuso de nOAuth para el cambio a Microsoft 365
Durante nuestra investigación inicial, descubrimos una aplicación vulnerable que tenía integraciones con Microsoft 365 con permisos Calendars.ReadWrite.Shared. Según la documentación de Microsoft, esta integración:
Permite a la aplicación crear, leer, actualizar y eliminar eventos en todos los calendarios de la organización a los que el usuario tiene permiso para acceder. Esto incluye calendarios delegados y compartidos.
Preocupante, pero no algo que permita un ataque como el compromiso del correo electrónico empresarial (BEC).
En esta ocasión, encontramos un conjunto de permisos mucho más amplio y preocupante (Figura 4):
- Calendarios.LeerEscribir
- Enviar correo electrónico
- Contactos.LeerEscribir
- Correo electrónico. Lectura y escritura
- acceso sin conexión
Como se mencionó anteriormente, estos permisos son preocupantes porque permiten a un atacante no solo comprometer al usuario dentro de la aplicación SaaS, sino también utilizar la interfaz de la aplicación para volver a Microsoft 365.
Recuerde que la autenticación y la autorización son funciones diferentes con tokens diferentes. El atacante básicamente obtiene control sobre el acceso de los usuarios en Microsoft 365 a través de esos tokens de acceso y actualización gestionados dentro de la aplicación SaaS (Figura 5).
En la aplicación SaaS vulnerable, este comportamiento se manifiesta en la capacidad del atacante para enviar correos electrónicos como el usuario comprometido (Figura 6).
Dado que el correo electrónico procede de un usuario legítimo del inquilino, el atacante dispone ahora de una forma eficaz de actuar como el usuario comprometido dentro de Exchange Online (Figura 7).
El atacante no tiene acceso directo al token de acceso, por lo que la interfaz de usuario de la aplicación SaaS determina cómo puede interactuar con los recursos de Microsoft 365. Aun así, estos hallazgos refuerzan nuestras preocupaciones de larga data con respecto a nOAuth y el potencial acceso a los datos y las rutas laterales que puede habilitar.
Investigar nOAuth es como intentar demostrar una negación.
Cuando publicamos nuestros hallazgos en junio de 2025, las preguntas más frecuentes que recibimos fueron cuántas aplicaciones en total podrían ser vulnerables. Esto es comprensible, ya que los números indefinidos no dan buenos titulares.
Sin embargo, era —y sigue siendo— imposible cuantificar cuántas aplicaciones podrían ser vulnerables. Una búsqueda del número de aplicaciones SaaS existentes arroja un resultado que oscila entre 70 000 y más de 300 000. El catálogo de aplicaciones Microsoft 365 Defenders Cloud incluye 36 932 aplicaciones SaaS, pero no todas ellas se integran con Entra ID para la autenticación.
No importa cómo se hagan los cálculos, siempre serán conjeturas. En el extremo inferior, si el 50 % de todas las aplicaciones utilizan Entra ID para la autenticación, entonces probar 142 (de 35 000) aplicaciones nos sitúa en un 0,4 % probado. En el extremo superior (de 150 000 aplicaciones), nos situaría en un 0,098 % probado.
En Troopers, afirmé que habíamos encontrado nueve aplicaciones vulnerables, y dudo que hayamos encontrado el 90 % de todas las aplicaciones vulnerables. Ahora, con nuestros nuevos descubrimientos, dudo que 11 sea el total de aplicaciones vulnerables que existen. Es simplemente imposible saberlo.
Microsoft sabría cuántas aplicaciones están configuradas con removeUnverifiedEmailClaim establecido en falso y cuántas aplicaciones están exentas para usar esta reclamación. Pero eso no indica si la aplicación es vulnerable.
En cuanto al tema de los permisos, aunque solo hemos encontrado abusos en aplicaciones que tienen integraciones con Exchange Online, las integraciones con SharePoint y OneDrive son igualmente populares. Sería ingenuo creer que solo un determinado porcentaje de aplicaciones con estas integraciones son vulnerables a nOAuth. Hay cientos de otros permisos de Microsoft Graph, muchos de los cuales serían muy preocupantes si un atacante se hiciera con ellos. De hecho, hacerlo es el objetivo principal de otro ataque muy común: las concesiones de consentimiento ilícitas.
Cronología y respuesta del MSRC
- 18 de noviembre de 2025: Con los nuevos hallazgos específicos de Microsoft 365 y esta capacidad de volver a pivotar, abrimos un caso con MSRC. Proporcionamos todos los detalles de los hallazgos, por escrito y en un vídeo que mostraba el ataque contra nuestro usuario de prueba. También pedimos a MSRC que eliminara la posibilidad de enviar una reclamación por correo electrónico sin verificar. Como comentamos en nuestra publicación original, hay otras formas de recibir la reclamación por correo electrónico.
- 3 de diciembre de 2025: MSRC respondió que el caso se considera de riesgo moderado y lo cerró. En su respuesta, MSRC declaró lo siguiente:
Tras una minuciosa investigación, hemos evaluado este caso como una vulnerabilidad de gravedad moderada. Se ha informado al respecto a nuestros respectivos equipos de productos/servicios, que podrían trabajar en la incorporación de mecanismos de defensa en profundidad adicionales, según sea necesario, en futuras versiones.
Por lo tanto, damos por cerrado este caso.
Por qué nOAuth sigue siendo importante
Seguiremos investigando las aplicaciones vulnerables a nOAuth y abogando por un cambio en Microsoft, por múltiples razones:
- El abuso de nOAuth está documentado públicamente.
- Las investigaciones han demostrado el acceso a información confidencial en plataformas como los sistemas de gestión de recursos humanos (HRMS).
- Las investigaciones han demostrado que existen posibles vías de movimiento lateral para volver a Microsoft 365.
- Los clientes de aplicaciones vulnerables no tienen defensa contra nOAuth.
- Los investigadores de seguridad han demostrado que determinar quiénes son los clientes de las aplicaciones SaaS es relativamente fácil.
- Utilizar plataformas como LinkedIn para dirigirse a usuarios privilegiados de aplicaciones SaaS y deducir sus direcciones de correo electrónico también es sencillo.
Instantánea de Semperis
Aunque las organizaciones empresariales no cuentan con defensas sólidas contra nOAuth, es importante comprender el riesgo relativo a sus datos. Antes de incorporar una nueva aplicación SaaS, pregunte al proveedor si conoce la investigación sobre nOAuth y remítale a nuestros blogs.
Para los proveedores y desarrolladores, seguir las especificaciones OpenID Connect de Microsoft es fundamental para garantizar que su aplicación no sea vulnerable a nOAuth. Para obtener más información, consulte nuestra investigación anterior.
Recursos relacionados
• Alerta de abuso de nOAuth: apropiación total de cuentas de aplicaciones SaaS entre inquilinos de Entra
• Sesión bajo demanda sobre nOAuth (TROOPERS25)
