Robo de tokens en Microsoft 365: por qué la MFA sola no detiene el token spraying

Un experimento demuestra que la MFA no impide las sesiones robadas: más de 200.000 intentos de inicio de sesión fallidos, 497 inicios de sesión correctos y correos sobre salarios y bonos que desaparecen en reglas ocultas. El foco está en cómo reconocer este robo de tokens en Microsoft 365, por qué la amplia implantación de la plataforma hace rentable el ataque y qué hacer primero en una emergencia.

De qué trata el token spraying

Token spraying en Microsoft 365 es el nombre de una técnica que el proveedor de seguridad Huntress observó en una campaña. Los atacantes no adivinan contraseñas. Roban tokens de sesión después de que un empleado haya iniciado sesión correctamente con contraseña y autenticación multifactor (MFA), y poco después reproducen esos tokens desde su propia infraestructura. El nombre alude al password spraying, en el que se prueba una contraseña contra muchas cuentas. Aquí, las credenciales robadas se distribuyen ampliamente y se reutilizan.

La información sobre la campaña procede de Huntress y de un informe de The Hacker News. Se basa en observaciones entre clientes de un proveedor de seguridad y no dice nada sobre todos los inquilinos.

Robo de tokens en Microsoft 365: lo que observó Huntress

Huntress describe la campaña en el informe Token Replay and Spray. La fecha exacta de publicación del informe no es segura; lo documentado es el periodo de observación del 14/07/2026 al 22/09/2026. En ese tiempo, Huntress vio ataques a 79 organizaciones, más de 200.000 intentos de inicio de sesión fallidos y 497 inicios de sesión correctos. Se crearon al menos 48 dispositivos falsos en directorios de Entra. En 19 organizaciones se eliminaron los métodos de MFA existentes y se sustituyeron por uno nuevo.

Según los datos disponibles, la cifra de 97 cuentas comprometidas solo la menciona The Hacker News. No pudo confirmarse en el informe de Huntress y por eso se cita aquí como dato de ese informe. Además, las cifras de las distintas oleadas de ataques difieren ligeramente dentro de la exposición de Huntress. Para situarse basta el orden de magnitud: con 79 organizaciones afectadas, 497 inicios de sesión correctos y varias oleadas de ataques durante unas diez semanas, no fue un caso aislado, sino una serie.

En qué se diferencia el token spraying del password spraying

En el password spraying llaman la atención muchos intentos fallidos, porque la mayoría de las contraseñas son incorrectas. En el token spraying, las credenciales son válidas. Según Huntress, los intentos fallidos de la campaña procedían de redes de los atacantes, una gran parte de un proveedor de alojamiento en Alemania. Eso no dice nada sobre otros clientes de ese proveedor. Bloquear direcciones concretas tampoco ayuda mucho, porque los atacantes cambiaban de direcciones por oleadas y entre oleadas había una o dos semanas de calma.

Cómo el token replay socava la MFA

La técnica también se llama token replay, es decir, la reproducción de un token robado. El proceso puede describirse en cuatro pasos.

1. Cebo: Un empleado recibe un correo de phishing o es dirigido a un sitio ajeno mediante ingeniería social. Cómo ganan confianza estos correos se describe en el artículo sobre la autenticidad de los mensajes electrónicos.
2. Interceptación: Un relé adversary-in-the-middle (AiTM) se sitúa entre el empleado y la página real de inicio de sesión de Microsoft. La contraseña y la solicitud de MFA pasan por el relé, que después guarda el token. En el device code phishing, en cambio, se induce a la víctima a introducir un código en la página real de Microsoft, con el que el atacante obtiene un token.
3. Reproducción (replay): Entre unos minutos y aproximadamente una hora después, el atacante usa el token desde sus propios servidores. No hacen falta ni la contraseña ni una segunda solicitud de MFA.
4. Persistencia: El atacante registra su propia aplicación de autenticación, elimina los métodos de MFA existentes o crea un dispositivo falso. Ambas cosas sobreviven a un cambio de contraseña.

Lo importante es esto: la MFA no fue vulnerada. El empleado la completó correctamente. Lo que se roba es el resultado, el token. Por eso la MFA solo puede eludirse aquí si el token también funciona fuera del dispositivo del empleado. Los códigos, los SMS y las aprobaciones push ayudan contra el adivinado de contraseñas, pero no contra este tipo de robo.

Huntress encontró dos familias de herramientas. Una es un script que se identifica con el user agent «node» y solicita tokens a través de las aplicaciones Office y Authentication Broker. La otra reproduce sesiones de navegador. Los inicios de sesión del segundo tipo parecen accesos normales desde un navegador y llaman menos la atención.

Monocultivo Microsoft: por qué Microsoft 365 es el objetivo más rentable

Microsoft 365 se usa en innumerables empresas de Alemania y de todo el mundo. Desde el punto de vista de los atacantes, es un argumento económico: un ataque construido una vez puede repetirse contra un número muy grande de inquilinos. Las páginas de inicio de sesión son iguales en todas partes, los identificadores de aplicación son los mismos, y los códigos de error también. Lo que funciona en una empresa funciona, con pequeños ajustes, en muchas otras.

La campaña muestra esta escalabilidad. Los tokens robados se usaron de forma automatizada y en cuestión de minutos, repartidos entre 79 organizaciones. Según Huntress, los atacantes no priorizaban por el número de intentos fallidos, sino por dónde había credenciales válidas. Así trabaja un negocio de volumen, no una operación dirigida contra una sola empresa.

La implantación es el amplificador, no la única causa

No es una condena generalizada. Microsoft ofrece las contramedidas: acceso condicional, Security Defaults y Token Protection. El riesgo surge cuando estas herramientas no se usan o solo se usan en parte. Los atacantes adaptan su automatización a los ajustes predeterminados, porque se aplican a la mayoría de los inquilinos. Cada desviación, como un inicio de sesión vinculado al dispositivo o un flujo de código de dispositivo bloqueado, cuesta esfuerzo a los atacantes y elimina la base de la explotación masiva.

La difusión de Copilot y de otros servicios tras las mismas cuentas también aumenta la palanca de una cuenta comprometida. Una valoración crítica se encuentra en el artículo Copilot bajo la lupa. En Microsoft 365, una sola cuenta abre a la vez correo, archivos, calendario y chat.

El fraude de nóminas como objetivo: qué ocurre tras la toma de control

Tras la toma de control, los atacantes de la campaña crearon reglas ocultas en la bandeja de entrada. Estas movían o eliminaban correos con términos del tráfico de pagos, como salario, ingresos o bonos. Las carpetas de destino tenían nombres discretos como «RSS Feeds» o «Conversation History». En un caso, un correo sobre un salario se envió a un asesor fiscal externo. Las respuestas se marcaban como leídas y se apartaban para que la víctima no las notara.

Detrás está el business email compromise (BEC): se trata de desviar transferencias o de hacer cambiar cuentas de salario. En otro caso, un buzón se usó indebidamente para enviar spam a cientos de destinatarios externos hasta que Entra ID Protection clasificó la cuenta como de riesgo alto.

Para las pequeñas empresas esto es especialmente delicado. En contabilidad y recursos humanos suelen trabajar pocas personas. Una cuenta modificada se detecta tarde, y la nómina a menudo la gestionan terceros. La dirección decide entonces sobre la devolución de pagos y la información al banco, al asesor fiscal y a la gestoría de nóminas. Eso pertenece al plan de emergencia, no solo a la crisis.

Rastros típicos: nueva aplicación de autenticación, dispositivos desconocidos en Entra, reglas de bandeja de entrada

La campaña deja rastros en Microsoft Entra ID, la gestión de usuarios detrás de Microsoft 365, que pueden comprobarse sin herramientas especiales. La tabla siguiente resume los más importantes. Los patrones de nombres proceden del informe de Huntress y pueden cambiar.

El código de error 53003 merece atención. Un bloqueo por acceso condicional suele considerarse un éxito de la política. Pero también muestra que alguien ajeno a la empresa posee credenciales o un token válidos. Una entrada así es motivo para revisar la cuenta. Las reglas de bandeja de entrada creadas mediante una API no siempre aparecen en la interfaz. Se hacen visibles a través del centro de administración de Exchange o de PowerShell.

Las pequeñas empresas sin supervisión de registros suelen verlo todo solo a posteriori. El tiempo que se conservan los registros de inicio de sesión depende de la licencia y debería aclararse de antemano, porque sin registros el alcance de un incidente queda sin determinar.

Acceso condicional: bloquear el flujo de código de dispositivo y exigir MFA para todos los tipos de cliente

El flujo de código de dispositivo es un método de inicio de sesión para dispositivos sin teclado ni navegador. Los atacantes lo explotan en el device code phishing haciendo que los usuarios introduzcan un código en otro dispositivo. En su documentación sobre el bloqueo de flujos de autenticación, Microsoft recomienda acercarse lo máximo posible a un bloqueo completo y permitir el flujo solo en excepciones bien documentadas, como herramientas heredadas que no pueden actualizarse.

La política se crea en el centro de administración de Entra, en Entra ID, Acceso condicional, Directivas. La condición es «Flujos de autenticación» con la selección «Flujo de código de dispositivo», y el control de acceso es «Bloquear acceso». Microsoft recomienda ejecutar primero la política en modo «Solo informe» y activarla después. Se excluyen dos cuentas de acceso de emergencia, cuya lista debe revisarse con regularidad.

Licencia: acceso condicional o Security Defaults

Según Microsoft Learn, el acceso condicional requiere como mínimo Microsoft Entra ID P1 (requisito según la documentación sobre niveles de autenticación). Las empresas sin esta licencia disponen de los Security Defaults, que según Microsoft no requieren licencia. Entre las medidas de protección que se enumeran allí figuran el registro de MFA para todos los usuarios, el bloqueo de protocolos heredados y el bloqueo del flujo de código de dispositivo. Microsoft indica además que, desde el 01/07/2026, todos los inquilinos nuevos de Entra bloquean el flujo de código de dispositivo como parte de los Security Defaults. Según Microsoft, los Security Defaults no se pueden personalizar, solo activar o desactivar. Quien necesite excepciones o reglas más finas necesita acceso condicional.

MFA para todos, sin excepciones para aplicaciones o clientes

Una política base debería exigir MFA para todos los usuarios, todos los recursos y todos los tipos de cliente, o bloquear el acceso. Esta es exactamente la exigencia del informe de Huntress, y las brechas suelen surgir de excepciones bienintencionadas como «solo portales de administración» o «solo en el navegador». Los protocolos heredados como IMAP, POP3 y la autenticación SMTP no admiten MFA y deberían bloquearse.

Los métodos resistentes al phishing, como las llaves de seguridad FIDO2 o Windows Hello para empresas, protegen mucho mejor contra la interceptación AiTM que los códigos, los SMS o las aprobaciones push. Microsoft cita como característica del nivel «MFA resistente al phishing» una interacción entre el método de autenticación y la superficie de inicio de sesión (niveles de autenticación). Esta página no contiene una afirmación explícita sobre AiTM, así que esta valoración es una conclusión del autor. Cómo crear una política base con nivel de autenticación se describe en la página MFA para todos los usuarios. Tiene sentido empezar por los administradores.

Token Protection y sus límites

Token Protection es un control de sesión en el acceso condicional. Solo acepta tokens de inicio de sesión vinculados criptográficamente a un dispositivo registrado. Un token robado no funciona entonces en otro dispositivo. Según Microsoft Learn (página a fecha de agosto de 2026), la función está disponible con carácter general para aplicaciones nativas en Windows, iOS, iPadOS y macOS y se aplica a Exchange Online, SharePoint Online y Teams. En Windows se suman Windows 365 y Azure Virtual Desktop. La página no contiene datos de licencia propios, por lo que el requisito de licencia debe aclararse por separado. Como función del acceso condicional, Token Protection requiere como mínimo Entra ID P1, según deducción propia del autor. No es una cita de Microsoft.

Los límites están claramente indicados. Las aplicaciones basadas en navegador solo se admiten en versión preliminar y solo para aplicaciones web seleccionadas que usan Azure Resource Manager. Outlook en la web, por tanto, no queda cubierto. Además, los dispositivos deben estar registrados, unidos o unidos en modo híbrido a Entra. Los dispositivos Apple necesitan ser dispositivos administrados con la extensión de inicio de sesión único. Para empresas con dispositivos personales, es un obstáculo real.

Token Protection reduce el token replay, pero no elimina el riesgo. Microsoft recomienda un grupo piloto, el modo «Solo informe» y la evaluación de los registros de inicio de sesión antes de un despliegue amplio. También ayudan un dispositivo compatible como condición de acceso, la restricción del consentimiento a aplicaciones nuevas y la revisión periódica de las nuevas aplicaciones empresariales. La MFA resistente al phishing y el acceso basado en dispositivos reducen el riesgo; la supervisión detecta lo que aun así se cuela.

Procedimiento de emergencia: revocar sesiones, limpiar dispositivos y métodos de MFA

La secuencia siguiente es una recomendación del autor, derivada de la documentación de Microsoft sobre la revocación de accesos y del informe de Huntress. No es un requisito oficial. El procedimiento general tras un ataque exitoso se describe en el artículo Ransomware: plan de actuación para los primeros 60 minutos, y parte de él es aplicable aquí.

1. Bloquear la cuenta y revocar sesiones: En el centro de administración de Entra, en Usuarios, se desmarca «Cuenta habilitada» y se elige «Revocar sesiones», o bien mediante PowerShell con Revoke-MgUserSignInSession. Así se impiden nuevos tokens.
2. Restablecer la contraseña: En entornos híbridos, Microsoft recomienda restablecer la contraseña dos veces en el Active Directory local. Después se revocan de nuevo las sesiones.
3. Revisar los métodos de MFA: Los métodos desconocidos, en especial una nueva aplicación de autenticación, se eliminan. El usuario real configura sus métodos solo después, a ser posible con una confirmación por llamada telefónica.
4. Revisar los dispositivos: Los dispositivos registrados desconocidos se desactivan y se eliminan. Son señal de persistencia.
5. Limpiar el buzón: Se revisan y eliminan reglas, reenvíos, delegaciones y reglas de transporte. Se examinan los elementos enviados y eliminados en busca de anomalías.
6. Revisar las aplicaciones: Se eliminan las aplicaciones empresariales y los consentimientos de aplicación desconocidos.
7. Determinar el alcance: Se evalúan los registros de inicio de sesión desde el primer momento sospechoso. También deben considerarse otras cuentas del mismo departamento, ya que la campaña afectó a menudo a varias cuentas por organización.
8. Evaluar las consecuencias para el negocio: ¿Se han modificado datos bancarios, datos salariales o facturas? Se informa al banco, al asesor fiscal y a la gestoría de nóminas, se detienen los pagos y las solicitudes de cambio se confirman por teléfono. Esto lo decide la dirección.
9. Evaluar la obligación de notificación: La necesidad de notificar a la autoridad de control depende del riesgo. El plazo es de 72 horas desde que se tiene conocimiento (artículo 33 del RGPD). Esto no es asesoramiento jurídico.

Por qué la revocación no surte efecto de inmediato

Según Microsoft, los tokens de acceso son válidos por defecto durante una hora. La revocación bloquea nuevos tokens e invalida los tokens de actualización, pero los tokens de acceso ya emitidos siguen siendo válidos hasta que caducan. En aplicaciones con cookies de sesión propias, la propia aplicación debe finalizar el acceso. La evaluación continua de acceso (Continuous Access Evaluation, CAE) acorta este tiempo a unos minutos en Exchange Online, SharePoint Online y Teams, según Microsoft con un retraso de hasta 15 minutos. Huntress indica que los tokens de acceso siguieron siendo válidos hasta unos 90 minutos y que un restablecimiento de contraseña por sí solo no elimina ni los dispositivos falsos ni los métodos de MFA. Ambas cosas van juntas: hacer clic en «Revocar sesiones» es un comienzo, no el final.

Qué pueden comprobar esta semana administradores y gerentes

• ¿Está bloqueado el flujo de código de dispositivo o están activados los Security Defaults?
• ¿Exige una política MFA para todos los usuarios, recursos y tipos de cliente sin excepciones de aplicaciones?
• ¿Están bloqueados los protocolos heredados como IMAP, POP3 y la autenticación SMTP?
• ¿Existen dos cuentas de acceso de emergencia excluidas de las políticas y protegidas por separado?
• ¿Se han revisado los métodos de autenticación, los dispositivos y las reglas de bandeja de entrada en contabilidad y recursos humanos?
• ¿Está claro quién decide en caso de sospecha y qué proveedor de servicios está localizable también fuera del horario laboral?

En el proveedor de servicios informáticos cuentan el tiempo de respuesta, el acceso a los registros, el conocimiento de las políticas y una documentación escrita de las excepciones. Una revisión externa de la configuración puede ser útil, por ejemplo mediante los security checks. El propio sitio web y el dominio de correo también forman parte de la superficie de ataque. La comprobación del sitio web examina el sitio desde fuera, pero no revisa los ajustes de Entra.

La amplia implantación convierte a Microsoft 365 en el objetivo por defecto. Quien endurece los ajustes predeterminados, vigila dispositivos y métodos y conversa de antemano sobre la emergencia quita a la automatización su base. Visto con sobriedad, es menos una cuestión de pánico que de configuración y rutina.