Una campaña de reutilización de tokens secuestra cuentas de Microsoft 365 en 79 organizaciones
Entre mediados de julio y finales de septiembre de 2026, una campaña coordinada tomó el control de cuentas de Microsoft 365 en 79 organizaciones sin descifrar una sola contraseña. Los atacantes robaron tokens de sesión ya autenticados, los reutilizaron desde su propia infraestructura y aprovecharon ese acceso para dejar a las víctimas fuera de su propia autenticación multifactor (MFA).
Qué ocurrió
La operación duró unas diez semanas, del 14 de julio al 22 de septiembre de 2026. En los entornos donde se observó, generó más de 200.000 intentos fallidos de inicio de sesión, 497 inicios de sesión exitosos y 97 cuentas comprometidas. Los atacantes registraron al menos 48 dispositivos no autorizados en Microsoft Entra ID para conservar el acceso tras la intrusión inicial.
Tres técnicas de entrada alimentaron la campaña:
- Phishing adversary-in-the-middle (AiTM). Una página de inicio de sesión clonada se situaba entre la víctima y Microsoft, reenviando en tiempo real el usuario, la contraseña y el desafío MFA, y capturando la sesión autenticada que volvía.
- Phishing por código de dispositivo. En la oleada de agosto, se convenció a las víctimas de aprobar un código de dispositivo generado por el atacante en la página legítima de Microsoft, entregando una sesión sin necesidad de ninguna página falsa.
- Ingeniería social para que los objetivos interactuaran con cualquiera de los dos señuelos.
Una vez capturado el token, se reutilizaba desde servidores alquilados en Alemania. Dos conjuntos de herramientas distintos gestionaban la reutilización: uno realizaba intercambios de tokens automatizados a través de las aplicaciones cliente Microsoft Office y Authentication Broker para llegar a Microsoft Graph, Exchange Online y SharePoint; el otro reproducía sesiones completas de navegador mediante el cliente OfficeHome. Los relés de phishing y los hosts de reutilización estaban en infraestructuras separadas, por lo que bloquear uno no detenía al otro.
La velocidad fue un rasgo definitorio. En un incidente de julio pasaron doce minutos entre el inicio de sesión de la víctima y la toma de control. En la última toma de septiembre, solo cuatro.
Cómo se afianzaron los atacantes
En 19 de las organizaciones afectadas, los intrusos eliminaron los métodos MFA existentes de la víctima y registraron sustitutos en menos de tres horas desde su primer inicio de sesión, con frecuencia etiquetados como un autenticador de iPhone. Dispositivos Windows no autorizados, nombrados con el prefijo DESKTOP- seguido de ocho caracteres hexadecimales, les dieron una segunda vía de persistencia.
Después vino el abuso de los buzones. Reglas de bandeja de entrada con nombres desechables, como un solo punto o una sola letra, movían en silencio el correo entrante a carpetas como RSS Feeds, RSS Subscriptions y Conversation History. Una cuenta secuestrada envió un mensaje relacionado con nóminas a un contador externo mientras las reglas ocultaban las respuestas bancarias. Otras cuentas se usaron para enviar spam a cientos de destinatarios.
La actividad no se ha vinculado a una familia de malware conocida ni a un kit de phishing concreto, y no se ha atribuido a ningún grupo en particular.
Por qué importa
El robo de tokens de sesión convierte la MFA en un obstáculo de un solo uso en lugar de un control permanente. Cuando el atacante posee la prueba de que el desafío ya se completó, Microsoft ve una sesión legítima. Los pasos de persistencia, nuevos métodos MFA, dispositivos inscritos y reglas de bandeja, están diseñados para sobrevivir a un simple restablecimiento de contraseña, y por eso tantas víctimas siguen comprometidas tras la solución "evidente".
La nota positiva: las políticas de Conditional Access bloquearon 1.052 intentos de reutilización en cuatro organizaciones durante una sola oleada. Fue la aplicación de políticas, no la MFA por sí sola, lo que dejó los tokens sin valor.
Qué hacer
- Busque los artefactos. Revise los registros de inicio de sesión de Entra en busca de conexiones desde rangos de hosting desconocidos, incluido el bloque
193.26.115[.]0/24, agentes de usuarionodeoMozilla/5.0a secas, y los códigos de error53003(bloqueado por Conditional Access) y50133(artefacto SSO revocado). - Audite la persistencia. Liste los métodos MFA y los dispositivos registrados en los últimos noventa días y elimine los que el usuario no pueda confirmar, sobre todo los que sigan el patrón
DESKTOP-más ocho caracteres hexadecimales. - Revise las reglas de bandeja de entrada de todo el tenant en busca de reglas con nombres sin sentido o que muevan el correo a las carpetas RSS o Conversation History.
- Remedie correctamente. Revoque todas las sesiones y tokens de actualización, restablezca la contraseña, elimine dispositivos y métodos MFA no autorizados, borre las reglas maliciosas y vuelva a inscribir la MFA desde un dispositivo de confianza.
- Endurezca el tenant. Desactive o restrinja al máximo el flujo de código de dispositivo, exija dispositivos conformes o hybrid-joined para las aplicaciones sensibles, active la protección de tokens donde esté disponible y revise las aplicaciones con consentimiento reciente.
- Forme contra el señuelo. Los usuarios deben saber que una página legítima de Microsoft que les pide aprobar un código que no solicitaron es, en sí misma, el ataque.
La reutilización de tokens solo funciona donde la política lo permite. Nuestro equipo de penetration testing evalúa los tenants de Microsoft 365 frente a este escenario exacto, comprobando si Conditional Access, la configuración del código de dispositivo y los controles de registro MFA detendrían una sesión reutilizada antes de que se convierta en una toma de control.