El token que no pide MFA: las apps conectadas a tu Microsoft 365

Más de setecientas organizaciones quedaron potencialmente expuestas en agosto de 2025 y a ninguna le robaron una contraseña. Nadie saltó un segundo factor, nadie explotó un CVE en su infraestructura. El atacante se llevó los tokens OAuth de un chatbot comercial que esas empresas habían conectado a su CRM tiempo atrás, y con ellos pidió los datos por la API, educadamente, exactamente igual que hacía esa aplicación cada mañana. El 13 de julio de 2026 Microsoft publicó el mapa completo de un año largo de esta técnica. Vale la pena leerlo aunque no tengas Salesforce, porque la pieza que falla no es de Salesforce: es el consentimiento, y esa la tienes tú también.

Gestionamos tenants de Microsoft 365 y llevamos años empujando a los clientes hacia lo mismo: MFA obligatorio, acceso condicional, y últimamente fuera el SMS y dentro las passkeys. Ese trabajo había que hacerlo y lo volveríamos a hacer. Pero aquí viene la parte incómoda, y preferimos decirla nosotros: nada de eso toca esta clase de ataque. No porque esté mal montado, sino porque el ataque no pasa por el inicio de sesión.

Un año, dos cadenas y ninguna contraseña

El informe de Microsoft cubre de mediados de 2025 a mediados de 2026 y describe dos cadenas de ataque contra instancias de SaaS de clientes: el abuso de consentimiento a base de llamadas de teléfono y el compromiso de proveedores integrados. Ninguna de las dos es un fallo de software; las dos son abusos de un mecanismo que funciona exactamente como está diseñado. Verás por ahí que fueron «tres vías», contando los permisos mal configurados de usuarios invitados: eso viene de la cobertura de prensa. En el texto de Microsoft, el acceso de invitado está en las recomendaciones de bastionado, no entre las cadenas de entrada.

Fíjate en lo que tienen en común. No hay una contraseña robada al cliente final. No hay un inicio de sesión raro desde un país raro. En los dos casos, el atacante entra usando una autorización que la propia víctima concedió, meses o años antes, probablemente en una tarde de martes y probablemente sin pensarlo dos veces.

El MFA responde a otra pregunta

Un token OAuth no es una contraseña. Es un permiso ya firmado. Cuando un usuario pulsa «Aceptar» en esa pantalla de consentimiento que casi nadie lee, la plataforma emite a la aplicación un pase para actuar en su nombre, y además un token de refresco para que pueda renovarlo sola, sin volver a molestar a nadie. A partir de ahí la aplicación llama a la API tantas veces como quiera. No hay pantalla de login. No hay reto de MFA. No hay inicio de sesión interactivo que pueda parecer sospechoso, porque no hay inicio de sesión.

Dicho de la forma más corta que se nos ocurre: el MFA protege el momento en que alguien demuestra quién es. El consentimiento decide qué puede hacer un tercero en tu nombre a partir de entonces. Son dos preguntas distintas, y el sector lleva cinco años contestando en masa la primera. La segunda casi nadie la ha revisado nunca.

Ahora tradúcelo a tu tenant

En Microsoft 365 esto se llama «aplicaciones empresariales», y por debajo, entidades de servicio. Cada herramienta que alguien ha conectado alguna vez —el firmador de PDF, el CRM, la app de fichajes, el conector de la gestoría, el asistente de reuniones que resume las actas— tiene ahí su ficha con sus permisos. Hay dos familias, y la diferencia importa mucho más de lo que parece:

• Permisos delegados: la aplicación actúa en nombre de un usuario y hereda lo que ese usuario puede hacer. La letra pequeña, que ha cambiado hace poco y conviene tener al día: por defecto cualquier usuario puede conceder los permisos que no requieren aprobación de administrador, pero los tenants nuevos arrancan con la política gestionada por Microsoft («deja que Microsoft gestione tus ajustes de consentimiento»), que ya excluye lo goloso: Mail.Read, Mail.ReadWrite, Files.Read.All, Sites.Read.All, los permisos de calendario y de chat, y EWS, IMAP y POP en Exchange Online. Traducido: en un tenant creado hace poco un usuario ya no puede regalar su buzón; en uno de 2019 que nadie ha tocado, depende de qué ajuste tenga puesto. Compruébalo antes de dar nada por hecho.
• Permisos de aplicación: la aplicación actúa sola, sin usuario detrás. No hay nadie a quien pedirle un MFA. Y como no hay usuario, las políticas de acceso condicional que escribiste para tu gente no le aplican. Existe acceso condicional para identidades de carga de trabajo, sí, pero requiere licencias específicas y —esto es lo que casi nadie sabe— la propia documentación avisa de que no cubre aplicaciones SaaS de terceros ni aplicaciones multiinquilino. Justo las de esta historia.

Y ahora el detalle que nos parece el más interesante de toda la documentación, porque va justo en sentido contrario. Junto a esa política gestionada viene activada de serie otra, la de clientes de correo, que devuelve exactamente esos permisos de correo al usuario para seis aplicaciones concretas: Apple Mail, Thunderbird, Spark, eM Client y los clientes de correo de Android y de Samsung. Es decir, que la puerta que Microsoft cerró en la política principal la deja entornada para media docena de clientes populares, y ninguno de ellos es tuyo ni lo administras tú. No decimos que esté mal —es una decisión de usabilidad razonable y son aplicaciones conocidas—, decimos que probablemente no lo sabías, que aparece en la documentación oficial y que es el tipo de cosa que hay que mirar antes de afirmar que en tu tenant nadie puede conceder acceso a su buzón.

Y no acaba ahí: los permisos delegados y de aplicación no son la única vía de acceso. La propia documentación de Microsoft recuerda que también conceden acceso los roles de directorio, el RBAC de Exchange para aplicaciones y el consentimiento específico de recurso de Teams. Es decir: hay más de una lista que mirar, y no están en la misma pantalla.

El inventario que casi nadie tiene

La versión de clic está en el centro de administración de Entra, en Aplicaciones empresariales → Todas las aplicaciones → la aplicación que sea → Permisos, con dos pestañas: consentimiento de administrador y consentimiento de usuario. Aviso importante que sale en la documentación y sorprende a todo el mundo la primera vez: los consentimientos de la pestaña de usuario no se pueden revocar desde el portal. Para eso hay que ir a Graph o a PowerShell. Y como esa pantalla es una ficha por aplicación, se navega fatal cuando hay doscientas, nosotros arrancamos siempre por la lista completa:

Connect-MgGraph -Scopes "Directory.Read.All","Application.Read.All"

# Precargamos las entidades de servicio en memoria: si no, se hace
# una llamada a Graph por cada concesion y acabas con throttling
$sp = @{}
Get-MgServicePrincipal -All | ForEach-Object { $sp[$_.Id] = $_.DisplayName }

# Consentimientos delegados del tenant: quien los dio, a quien y para que
Get-MgOauth2PermissionGrant -All | ForEach-Object {
    [pscustomobject]@{
        App      = $sp[$_.ClientId]
        Alcance  = $(if ($_.ConsentType -eq 'AllPrincipals') { 'TODO EL TENANT' } else { 'un usuario' })
        Permisos = $_.Scope
    }
} | Sort-Object App | Export-Csv .\consentimientos.csv -NoTypeInformation -Encoding UTF8

Esa consulta contesta tres cosas de golpe: qué aplicaciones tienen permiso, si el permiso lo dio un administrador para toda la organización o un usuario suelto para sí mismo, y qué alcances concretos incluye. La primera vez que la ejecutas en un tenant de una empresa de cincuenta personas suele salir una lista más larga de lo que nadie esperaba, con un par de nombres que ya no reconoce ni quien los autorizó. Y ahí empieza la conversación que interesa.

Los permisos de aplicación, los que actúan sin usuario, van en otra consulta, y esta tarda un rato porque recorre todas las entidades de servicio del directorio:

# Permisos de aplicacion: los que no necesitan a nadie delante.
# Ojo: saldran tambien muchas apps de primera parte de Microsoft;
# el trabajo esta en las que NO reconozcas.
Get-MgServicePrincipal -All | ForEach-Object {
    $roles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id
    if ($roles) {
        # Editor = tenant que publica la app, NO es el publicador verificado
        [pscustomobject]@{ App = $_.DisplayName; Editor = $_.PublisherName; Asignaciones = $roles.Count }
    }
} | Sort-Object Asignaciones -Descending

Qué mirar en cada línea

Tener la lista no es tener el trabajo hecho. Estos son los criterios con los que la recorremos, y varios salen tal cual de la guía de investigación de Microsoft. Un aviso antes de seguir, porque nos parece de justicia decirlo: los filtros bonitos —uso en la comunidad, última autorización, número de usuarios que la autorizaron— viven en Defender for Cloud Apps y en el gobierno de aplicaciones, que no entra en cualquier plan. Si tu licencia no lo incluye, el criterio sirve igual; lo que cambia es que la información la sacas de Graph y del registro de auditoría en vez de una pantalla que te lo da masticado.

• Permisos que no encajan con lo que hace la aplicación. El ejemplo que usa la propia documentación es una app de reloj con acceso total a todos los buzones. Suena a chiste hasta que lo encuentras.
• Aplicaciones autorizadas por muy pocos usuarios. Contraintuitivo pero muy útil: cuanto más común y más usada es una aplicación, más probable es que sea legítima. Una que autorizó una sola persona merece una mirada.
• Fecha de última autorización antigua. Suele señalar aplicaciones que ya nadie usa y que nadie va a echar de menos si desaparecen. Son el mejor sitio para empezar a limpiar, porque el riesgo de romper algo es bajo.
• Nombre, publicador o web con pinta rara —así, en esos términos, lo plantea la guía—. No es una prueba de nada por sí sola, pero combinada con permisos altos cambia el orden de la cola. La exigencia de publicador verificado es otra cosa y vive en la configuración de consentimiento, no en esta pantalla.
• Quién dio el consentimiento y cuándo. Está en el registro de auditoría. Si el nombre que aparece ya no trabaja en la empresa, tienes dos problemas y no uno.

El botón que no hace lo que crees

Aquí está, para nosotros, lo más importante de todo el artículo, y es una frase de la documentación de Microsoft que deberían enmarcar: los cambios en la configuración de consentimiento de usuario solo afectan a los consentimientos futuros; los ya concedidos siguen intactos y los usuarios conservan el acceso con los permisos que se dieron antes.

Traducción a la vida real: si mañana desactivas el consentimiento de usuario y te vas a comer tranquilo, has cerrado la puerta por la que ya entró todo el mundo que iba a entrar. Lo que había concedido sigue concedido. Es una medida de higiene futura, no una limpieza. La limpieza es la otra, la aburrida: revisar la lista aplicación por aplicación y quitar lo que sobra.

Y cuando revoques, dos matices más que también están en la documentación y que conviene tener claros antes de decirle a un cliente «ya está resuelto». El primero: revocar el permiso no impide que el usuario vuelva a consentir la próxima vez que la aplicación se lo pida; si quieres que no vuelva, hay que impedir el consentimiento o sacar a la aplicación de en medio. El segundo, de física de tokens: un token de acceso ya emitido vive lo que le queda de vida —Microsoft documenta un valor aleatorio de entre 60 y 90 minutos, y dos horas para clientes tipo Teams y Microsoft 365 en tenants sin acceso condicional—, así que el corte no es instantáneo. El corte real llega cuando la aplicación intenta renovar y ya no puede.

Cerrar la puerta sin cerrar el negocio

La receta de manual es «desactiva el consentimiento de usuario» y a otra cosa. Nosotros la aplicamos, pero no el lunes a las nueve y sin avisar, y aquí nos vamos a mojar en contra de lo que se lee por ahí. Dos razones. La primera es de operación: rompes integraciones que la gente usa a diario y que no aparecen en ningún inventario tuyo, porque nadie te pidió permiso para montarlas. La segunda es más de fondo, y es la que de verdad nos preocupa: si bloqueas el camino y no ofreces ninguno, la alternativa que encuentra el usuario siempre es peor. Se lleva el fichero a su cuenta personal, se reenvía el correo a su Gmail, se instala la herramienta en el portátil de casa. Has ganado en la pantalla de consentimiento y has perdido el dato.

Por eso el orden que seguimos es este, y el ajuste duro va al final y acompañado. Primero el inventario, que además es la única parte que no rompe nada. Segundo, la limpieza de lo que ya no se usa, empezando por lo que lleva un año sin autorizarse. Tercero, endurecer por encima de lo que ya traes de serie: pasar de la política gestionada por Microsoft a la de publicador verificado más permisos que tú hayas clasificado como de bajo impacto, que no son lo mismo aunque las dos suenen a lo mismo en el desplegable. Y cuarto, el flujo de aprobación de administrador, para que cuando alguien necesite una herramienta nueva tenga un botón que pulsar y una persona que le conteste en un plazo razonable. Sin ese cuarto paso, los tres primeros duran seis semanas.

Hay un detalle más de la campaña que no queremos que pase desapercibido, porque es el que más se parece a lo que le puede ocurrir a una pyme mañana. Una de las dos cadenas empieza con una llamada de teléfono. Alguien se hace pasar por el soporte informático y consigue que un empleado autorice una aplicación con nombre creíble. Es el mismo guion de siempre, con otro objetivo: ya no quieren la contraseña, quieren el «Aceptar». Contra eso no hay ajuste que valga si la gente no sabe qué está firmando; y por eso a la formación de usuario le tenemos más respeto que a la mitad de los productos que se venden para esto. Lo mismo que contábamos del wifi de hotel y las credenciales de Microsoft 365: el eslabón atacado es la persona, no el protocolo.

Lo que no vamos a decirte

No vamos a decirte que desconectes las integraciones. Sería un titular cómodo y una tontería: el valor de tener el CRM hablando con el correo es real y lo hemos montado nosotros muchas veces. Tampoco vamos a decirte que Microsoft lo hace mal. El mecanismo de consentimiento es correcto y es infinitamente mejor que la alternativa, que era repartir contraseñas. Lo que falla no es el mecanismo, es que nadie lo trata como lo que es: una lista de terceros con llave de tu casa, que debería revisarse igual que revisas quién tiene acceso VPN o quién sigue siendo administrador de dominio.

Una última cosa, y es la que más nos cuesta escribir: no tenemos un número de cuántas aplicaciones con permiso de lectura de correo hay en el tenant medio de una pyme española. No lo hemos medido y no nos lo vamos a inventar. Lo que sí podemos contar es la cara que se pone al otro lado de la mesa cuando abrimos esa pantalla por primera vez con un cliente delante y aparece una aplicación que autorizó alguien que ya no trabaja allí. Nunca hemos tenido que explicar por qué esa revisión merecía la pena; se explica sola.

Gestionamos entornos de Microsoft 365 con el inventario de aplicaciones conectadas dentro de la revisión periódica, no como una emergencia cuando el proveedor de turno sale en un titular; y lo hacemos con el mismo criterio con el que planteamos un modelo Zero Trust, que en el fondo dice esto mismo: ningún acceso permanente por defecto, ni siquiera el de una aplicación que un día te resultó útil. No vendemos licencias de nadie ni tenemos comisión por integrar una herramienta u otra, así que cuando decimos «esta app sobra» es porque sobra.

Cerramos con la pregunta que de verdad importa, y no es si tienes MFA. Es esta: si mañana el proveedor de una de las aplicaciones que tienes conectadas al tenant apareciera en un titular, ¿cuánto tardarías en decir qué permisos le diste, quién se los dio y a qué datos podía llegar? Si la respuesta pasa por «habría que mirarlo», el trabajo del que habla este artículo está sin hacer. Se hace en una mañana, y es mucho mejor hacerlo un martes cualquiera que el día del titular.

Y si tu lista de deberes de agosto ya venía llena, avisamos: el 31 de agosto vence el plazo real de EWS en Exchange Online, que también va de aplicaciones con acceso a tu correo. Se hacen bien los dos de una sentada, porque la lista de partida es prácticamente la misma.

Fuentes (verificadas): las dos cadenas de ataque, las fechas y los incidentes de Salesloft Drift (agosto de 2025), Gainsight (noviembre de 2025) y Klue (junio de 2026) proceden del análisis «Defending SaaS-based applications against ShinyHunters OAuth abuse» publicado por Microsoft Security el 13 de julio de 2026, y de su cobertura en The Hacker News, de donde salen las cifras de más de 700 organizaciones potencialmente expuestas y más de 200 instancias afectadas. La campaña de agosto de 2025 y su ventana del 8 al 18 de agosto están documentadas por Google Threat Intelligence. Lo relativo a Microsoft 365 sale de la documentación oficial: el consentimiento de usuario por defecto, las políticas de consentimiento y la advertencia de que los cambios solo afectan a consentimientos futuros, de «Configurar cómo los usuarios dan su consentimiento a las aplicaciones»; la política gestionada por Microsoft como valor por defecto de un tenant nuevo, la lista exacta de permisos que excluye y la política de clientes de correo activada de serie con sus seis aplicaciones (Apple Mail, Thunderbird, Spark, eM Client, Android y Samsung), de «Administrar directivas de consentimiento de aplicaciones»; la revisión y revocación de permisos, la imposibilidad de revocar los consentimientos de usuario desde el portal, el aviso de que revocar no impide volver a consentir y la mención a los roles de directorio, el RBAC de Exchange y el consentimiento específico de recurso de Teams, de «Revisar los permisos concedidos a aplicaciones empresariales»; los criterios de investigación de aplicaciones sospechosas, de «Investigar y corregir aplicaciones OAuth de riesgo»; el requisito de licencia y la exclusión de aplicaciones SaaS de terceros y multiinquilino, de «Acceso condicional para identidades de carga de trabajo»; y la duración del token de acceso (valor aleatorio de 60 a 90 minutos, y dos horas para clientes como Teams y Microsoft 365 en tenants sin acceso condicional), de «Tokens de acceso en la plataforma de identidad de Microsoft». Son criterio y opinión nuestros, no de las fuentes: que el MFA y el consentimiento responden a preguntas distintas, el orden en cuatro pasos, la objeción a desactivar el consentimiento de usuario sin ofrecer alternativa y todo lo que no vamos a decirte.