Ilustración de la reutilización de tokens que describe el artículo: un inicio de sesión aprobado con MFA, el token de sesión que se emite después y ese token reutilizado por un atacante durante unas 10 semanas, según informó Huntress. Es conceptual, no un registro ni una captura de pantalla reales.
Los atacantes robaron sesiones que ya habían superado la MFA, las reutilizaron desde servidores alquilados y después cambiaron los métodos de MFA de las víctimas. Así funciona y esto es lo que debes revisar.
Una sesión que ya superó la MFA no vuelve a necesitarla
Si un atacante roba la sesión que la autenticación multifactor (MFA) acaba de aprobar, a la MFA ya no le queda nada que comprobar.
Es lo que describió la empresa de seguridad Huntress en un informe sobre una campaña contra cuentas de Microsoft 365. Entre el 14 de julio y el 22 de septiembre de 2026 detectó más de 200 000 intentos fallidos de inicio de sesión y al menos 497 exitosos en los entornos de sus clientes. La actividad afectó a 79 organizaciones.
Este artículo es para quienes administran Microsoft 365 o le dan soporte: administradores, personal de seguridad y responsables de TI. Explica qué es un token, cómo lo obtuvieron los atacantes, qué hicieron después y qué controles de Microsoft ayudan. También indica dónde se detienen esos controles, porque esa parte es fácil de pasar por alto.
Qué es un token y qué significa reutilizarlo
Cuando inicias sesión en Microsoft 365, demuestras quién eres con una contraseña y un segundo factor. Después, Microsoft entrega a tu dispositivo un token, un pequeño pase digital que dice «este usuario ya fue verificado». Tus aplicaciones presentan ese pase a Exchange, SharePoint y Teams para que no tengas que iniciar sesión en cada clic.
La reutilización de tokens (token replay) consiste en usar el pase de otra persona. Si un atacante copia un token válido y lo presenta desde otra máquina, el servicio ve un pase que parece auténtico. La contraseña y el segundo factor ya se comprobaron antes, así que no se vuelven a pedir.
Por eso el ataque es difícil de ver. En los inicios de sesión exitosos no se adivinó nada y nada falló. Simplemente, el pase lo usó la persona equivocada.
Qué observó Huntress
Según Huntress, la campaña duró unas diez semanas. Además de las cifras anteriores, encontró 48 dispositivos falsos registrados en los directorios de Entra de las víctimas. En al menos 19 organizaciones, los métodos de MFA existentes de las víctimas se eliminaron y se añadieron otros nuevos en las tres horas siguientes al primer inicio de sesión.
Los atacantes trabajaban en dos niveles. Un conjunto de servidores capturaba las sesiones de las víctimas. Otro conjunto distinto de servidores alquilados, en el rango de direcciones de un proveedor de alojamiento alemán, reutilizaba esas sesiones. Huntress llama a este paso de reutilización token spraying, por analogía con el password spraying.
Como los dos niveles están separados, bloquear uno no detiene el otro.
La velocidad importaba. Huntress midió 12 minutos entre una solicitud de MFA y una sesión secuestrada el 21 de julio, y cuatro minutos el 22 de septiembre. The Hacker News, que publicó los hallazgos el 26 de octubre, no atribuye la campaña a ningún actor de amenazas, y Huntress tampoco. Considera no confirmada cualquier atribución que veas en otros sitios.
Una nota sobre las cifras: proceden únicamente de los entornos de clientes de Huntress. La escala real es al menos así de grande, y probablemente mayor. Además, la página de Huntress da dos cifras distintas para un mismo pico de actividad de septiembre, así que no citamos ninguna de las dos.
Cómo obtuvieron los atacantes los tokens
Huntress y The Hacker News describen tres vías.
La primera es el phishing de adversario en el medio (adversary-in-the-middle), abreviado AiTM. La víctima llega a una página de inicio de sesión falsa que se sitúa entre ella y la página real de Microsoft. Esa página transmite a Microsoft su contraseña y su código de MFA, y se queda con el token que devuelve el servicio.
La víctima ve un inicio de sesión normal. El atacante tiene una sesión que funciona.
La segunda es el phishing con código de dispositivo. Algunos dispositivos, como un televisor o una herramienta de línea de comandos, no pueden mostrar una página de inicio de sesión completa, así que Microsoft les permite iniciar sesión mostrando un código corto que el usuario introduce en otro dispositivo. Un atacante puede iniciar ese proceso, enviar el código a la víctima con una historia creíble y recibir el token cuando la víctima lo aprueba.
La tercera es simple ingeniería social durante un inicio de sesión legítimo. Los informes dan pocos detalles sobre esta vía, así que no sabemos cómo funcionó en la práctica.
Qué hicieron los atacantes una vez dentro
Huntress encontró un patrón constante después de la primera reutilización. Los atacantes añadían su propia aplicación de autenticación, o borraban los métodos de MFA de la víctima y registraban uno nuevo. En un caso del 21 de julio, un método añadido por el atacante llamado «iPhone 13» estaba activo unos 50 minutos después de que el relé capturara la sesión.
También registraron dispositivos falsos en Entra, que permanecen en el directorio hasta que alguien los elimina. Y crearon reglas de bandeja de entrada ocultas, con nombres como un solo punto o «sss», que movían o eliminaban correos sobre nóminas, depósitos y bonificaciones. En un incidente, el atacante escribió a un contador externo sobre las nóminas y ocultó las respuestas, un patrón típico de business email compromise (fraude por vulneración del correo empresarial). En otro, se usó un buzón para enviar spam a cientos de destinatarios externos hasta que Entra ID Protection marcó la cuenta como de alto riesgo.
Cada paso hace que el intruso sea más difícil de expulsar. Un nuevo método de MFA significa que el atacante puede volver a iniciar sesión más adelante. Un dispositivo falso consigue lo mismo. Una regla oculta impide que la víctima vea las respuestas.
Por qué la MFA por sí sola no bastó
La MFA protege el momento del inicio de sesión. En un ataque AiTM, es la víctima quien hace esa parte por el atacante. El código real llega al servicio real de Microsoft a través del relé del atacante, y el atacante se queda con el resultado.
Algunos métodos de MFA resisten mejor que otros. La documentación de Microsoft sobre los niveles de autenticación (authentication strengths) sitúa Windows Hello for Business, las llaves de seguridad FIDO2 y la autenticación basada en certificados en un grupo «resistente al phishing». Los define como métodos que requieren una interacción entre el método y la superficie de inicio de sesión. El inicio de sesión telefónico de Microsoft Authenticator es un método sin contraseña, pero no forma parte de ese grupo, y los códigos y las aprobaciones push no están en ninguno de los dos.
Nuestra lectura de esa definición es que a una página de relé, que no es la superficie de inicio de sesión real, le resulta mucho más difícil completar estos métodos. Es una inferencia nuestra y no una declaración de Microsoft sobre AiTM, porque la página de Microsoft no menciona AiTM en absoluto. Tampoco sabemos qué métodos de MFA usaban las víctimas de Huntress, así que no podemos decir si los métodos resistentes al phishing habrían detenido esta campaña.
Qué cubren los controles de Microsoft y dónde se detienen
Varios controles ayudan contra el robo de tokens. Ninguno es, por sí solo, una respuesta completa. La tabla recoge lo que hace cada uno según la documentación actual de Microsoft, y el límite que importa.
| Control | Qué hace | Límite que debes conocer |
|---|---|---|
| Niveles de autenticación resistentes al phishing | Exige llaves FIDO2, Windows Hello for Business o autenticación basada en certificados para los inicios de sesión que elijas. | Conditional Access se evalúa después del primer paso de autenticación, así que un usuario todavía puede escribir una contraseña antes de que se aplique el requisito. |
| Protección de tokens (token protection) | Vincula los tokens de sesión de inicio de sesión al dispositivo, de modo que un token robado no debería funcionar desde otro dispositivo. Microsoft dice que «intenta reducir» la reutilización. | Cubre determinadas aplicaciones nativas, como Exchange Online, SharePoint Online y Teams, en plataformas compatibles. La compatibilidad con navegadores está en versión preliminar y se limita a determinadas aplicaciones web que acceden a Azure Resource Manager. Consulta la página para conocer el estado actual de cada plataforma. |
| Evaluación continua de acceso (continuous access evaluation) | Permite a Exchange, SharePoint y Teams rechazar un token antes de que caduque tras eventos como un restablecimiento de contraseña, una cuenta deshabilitada, una sesión revocada o un riesgo de usuario alto. | Solo funciona con aplicaciones compatibles. Las comprobaciones de ubicación solo cubren ubicaciones con nombre basadas en IP. Microsoft advierte de que pueden producirse retrasos en los eventos de hasta 15 minutos. |
| Bloquear el flujo de código de dispositivo | Una directiva de Conditional Access que bloquea la vía de inicio de sesión con código de dispositivo para los usuarios que no la necesitan. | Microsoft recomienda auditar primero el uso existente, y las cuentas que excluyas eluden la directiva. Las entidades de servicio (service principals) no están cubiertas por las directivas de usuario. |
Según la página de Microsoft, las sesiones de navegador en Outlook en la web o SharePoint no figuran en la lista de la protección de tokens. Nuestra inferencia es que se trata de un hueco frente a los ataques AiTM, que suelen capturar sesiones de navegador. La página de Microsoft no lo dice, así que tómalo como algo que debes probar en tu propio tenant y no como un hecho.
Huntress también recomienda directivas de Conditional Access que exijan MFA o bloqueen el acceso para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente, sin condiciones. Es el consejo del proveedor, y tiene sentido como base. No sustituye a los controles anteriores.
Qué hacer si sospechas que te han robado una sesión
Huntress es clara en un punto. Restablecer la contraseña no basta por sí solo. Los métodos de MFA y los dispositivos falsos del atacante siguen ahí, y un token de acceso puede seguir funcionando hasta que caduque, lo que Huntress sitúa en unos 90 minutos (el valor predeterminado de Microsoft es de 60 a 90 minutos). Sigue estos pasos en orden.
- Revoca las sesiones del usuario y después restablece la contraseña. En la campaña, los intentos posteriores del atacante de reutilizar sesiones que ya no eran válidas, por ejemplo tras un cambio de contraseña, fallaron con el error «SsoArtifactRevoked» de Microsoft (AADSTS50133).
- Revisa los métodos de MFA del usuario. Busca métodos añadidos o borrados poco después de un inicio de sesión, sobre todo en las horas siguientes.
- Audita los dispositivos registrados en Entra. Confirma que un dispositivo no es legítimo antes de eliminarlo. Huntress observó que los falsos usaban nombres que empezaban por «DESKTOP-» seguido de ocho caracteres hexadecimales, lo que difiere del valor predeterminado de Windows, y también menciona los prefijos «Device-» y «Work Pc» seguidos de ocho caracteres hexadecimales.
- Revisa las reglas de bandeja de entrada y las nuevas aplicaciones empresariales. Los nombres cortos o formados solo por signos de puntuación, y las reglas que afectan a mensajes de nóminas o bancarios, merecen un examen detenido.
- Busca impacto externo. Comprueba si se enviaron correos a terceros y si se aprobaron o cambiaron datos de pago.
Para la búsqueda de amenazas (threat hunting), Huntress enumera los patrones exactos de inicio de sesión, los ID de cliente y las direcciones que observó. Usa su informe para esos datos, porque cambian rápido y son más útiles para los equipos de búsqueda de amenazas que para el lector general.
Qué sabemos y qué no
| Etiqueta | Afirmación |
|---|---|
| Hecho | Huntress informa de actividad entre el 14 de julio y el 22 de septiembre de 2026, con al menos 497 inicios de sesión exitosos y 48 dispositivos falsos en Entra entre sus clientes. |
| Informe de los investigadores | Los atacantes usaron relés AiTM, phishing con código de dispositivo e ingeniería social para obtener tokens, y después los reutilizaron desde servidores alquilados. |
| Informe de los investigadores | En al menos 19 organizaciones, los métodos de MFA se sustituyeron en las tres horas siguientes al primer inicio de sesión. |
| Inferencia nuestra | Los métodos resistentes al phishing y los tokens vinculados al dispositivo encarecen este ataque. Las sesiones de navegador pueden seguir expuestas a AiTM incluso donde la protección de tokens está activada. |
| Desconocido | Quién llevó a cabo la campaña. Si alguna víctima usaba MFA resistente al phishing. Cuántas organizaciones fuera del alcance de Huntress se vieron afectadas. La evaluación de la propia Microsoft sobre la campaña. |
¿Con qué profundidad deberías aprender esto?
Conocer: Todo usuario y responsable de Microsoft 365 debería entender una idea. La MFA protege el inicio de sesión, no la sesión que viene después. Si un mensaje te pide introducir un código en una página que no abriste tú mismo, detente y notifícalo.
Usar: Los administradores y el personal del servicio de asistencia deberían saber revocar sesiones, revisar los métodos de MFA y los dispositivos registrados, encontrar reglas de bandeja de entrada ocultas y leer una directiva de Conditional Access. Deberías saber por qué restablecer la contraseña no es, por sí solo, una respuesta completa.
Dominar: Los arquitectos de seguridad y los responsables de identidad deberían diseñar pensando en el robo de tokens. Eso significa elegir los niveles de autenticación, desplegar la protección de tokens probándola primero en modo de solo informe, decidir quién necesita de verdad el flujo de código de dispositivo y reenviar los registros de inicio de sesión a un lugar que un intruso no pueda modificar.
Lo que puedes ignorar por ahora
No necesitas memorizar las direcciones IP, los user agents ni los ID de cliente del informe de Huntress. Son indicadores para quienes buscan amenazas y quedarán obsoletos. Lo que perdura es el patrón: un inicio de sesión normal, un cambio de MFA poco después, un dispositivo nuevo y una regla de correo oculta.
Un siguiente paso práctico
Abre tus registros de inicio de sesión y busca cualquier cuenta que haya registrado un nuevo método de MFA en las horas siguientes a un inicio de sesión desde un lugar desconocido. Después comprueba si tu tenant permite el flujo de código de dispositivo (device code flow). Si nunca lo has necesitado, crea primero la directiva de bloqueo en modo de solo informe y lee los resultados antes de activarla.
Para profundizar
Informes y cobertura
- Token spray and replay in Microsoft 365, Huntress, Andrea Hatcher, Susannah Matt, Matt Poto y Andrew Schwartz, 22 de octubre de 2026, la cronología completa, las herramientas y los indicadores.
- The Hacker News sobre los hallazgos de Huntress, The Hacker News, Ravie Lakshmanan, 26 de octubre de 2026, un resumen más breve.
Documentación de Microsoft
- Token protection in Conditional Access, Microsoft Learn, plataformas compatibles y pasos de despliegue.
- Continuous access evaluation, Microsoft Learn, eventos, duraciones y límites.
- Block device code flow, Microsoft Learn, los pasos de la directiva.
- Authentication strengths, Microsoft Learn, el grupo resistente al phishing.
Los datos de este artículo se comprobaron el 26 de octubre de 2026. Las funciones de Microsoft y el informe de Huntress pueden cambiar, así que verifícalos con las fuentes anteriores antes de actuar.
Este artículo separa lo que afirman Huntress y Microsoft de nuestra inferencia.
Lecturas relacionadas en TechiesJournal
- Ataques de phishing (en inglés), TechiesJournal, los fundamentos.
- Cuando una aplicación en la nube de confianza se convierte en una vía de ataque (en inglés), TechiesJournal, otro riesgo de identidad en Microsoft 365.