Los investigadores de la compañía Huntress revelaron una campaña a gran escala de compromiso de cuentas de Microsoft 365, en la que los atacantes reproducían tokens de autenticación robados en lugar de probar contraseñas. Según Huntress, del 14 de julio al 22 de septiembre de 2026 se registraron 497 inicios de sesión exitosos en los sistemas de 79 organizaciones frente a más de 200 000 intentos fallidos. Los atacantes también registraron al menos 48 dispositivos falsos en los catálogos de Microsoft Entra ID de las empresas afectadas. La campaña eludía la autenticación multifactor (MFA) y exige que las organizaciones revisen de inmediato los dispositivos registrados, los métodos de MFA y las reglas de procesamiento de correo entrante.
Mecanismo del ataque: de la interceptación a la reproducción
La campaña utilizó la técnica adversary-in-the-middle (AitM): el atacante colocaba una página de inicio de sesión intermedia entre la víctima y la infraestructura legítima de Microsoft. Cuando el usuario completaba la autenticación, incluida la introducción del código MFA, el servidor intermedio interceptaba el token de acceso emitido por Microsoft, es decir, la “prueba de inicio de sesión”. Este token se reproducía después desde la infraestructura de los atacantes durante varios minutos, sin necesidad de volver a pasar por MFA.
Según Huntress, los tokens llegaban desde varias fuentes: retransmisores AitM detrás de páginas de inicio de sesión falsas, phishing a través del mecanismo de códigos de dispositivo (device-code phishing) e ingeniería social durante el proceso de inicio de sesión legítimo. Los investigadores denominaron este enfoque token spraying, por analogía con el password spraying, pero en lugar de contraseñas se reproducen masivamente tokens robados en múltiples organizaciones.
La infraestructura del ataque estaba dividida en dos niveles: retransmisores AitM para interceptar sesiones y hosts separados para la reproducción de tokens. La reproducción se realizaba desde el rango 193.26.115[.]0/24, asociado al proveedor de alojamiento alemán 1337 Services GmbH. Durante 10 semanas los atacantes utilizaron de forma sucesiva seis direcciones IP de este bloque.
Persistencia y postexplotación
Tras obtener acceso, los atacantes se afianzaban de inmediato en los entornos comprometidos. Según Huntress, en 19 organizaciones los métodos existentes de MFA fueron eliminados y sustituidos por otros nuevos en un plazo de tres horas desde el primer inicio de sesión. En un caso registrado el 21 de julio de 2026, una nueva aplicación autenticadora con el nombre “iPhone 13” se activó en menos de 51 minutos después de la toma de control de la sesión.
Paralelamente, los atacantes registraban dispositivos falsos en los catálogos Entra ID de las víctimas. Como señalan los investigadores, un dispositivo registrado proporciona una forma más estable de solicitar tokens que una sesión robada y permanece en el catálogo hasta que se elimina manualmente.
En la fase de postexplotación, los atacantes creaban reglas ocultas de procesamiento de correo entrante con nombres como “.”, “sss”, “s”, “d”, “iT”. Estas reglas eliminaban o movían a carpetas poco visibles (RSS Feeds, Conversation History) los mensajes que contenían palabras clave relacionadas con salarios, bonificaciones y depósitos directos. En uno de los buzones comprometidos, una regla marcaba todos los mensajes entrantes como leídos y los eliminaba; después, el buzón se utilizó para enviar spam a cientos de destinatarios externos.
Eficacia de Conditional Access
Los datos de Huntress sobre la fase de la campaña en septiembre muestran un patrón característico: desde una sola dirección se realizaron 303 inicios de sesión exitosos en 29 organizaciones, mientras que esa misma dirección recibió 1 052 intentos bloqueados; sin embargo, todos los bloqueos correspondían únicamente a cuatro organizaciones que tenían configuradas políticas de acceso condicional (Conditional Access Policies). En las otras 29 organizaciones no había nada que impidiera el inicio de sesión. Esto demuestra que la MFA por sí sola no protege frente a la reproducción de tokens: se necesitan políticas de acceso condicional adicionales.
Vínculos con campañas anteriores
La campaña descrita encaja en una tendencia sostenida de ataques contra los servicios en la nube de Microsoft mediante la interceptación de sesiones. Anteriormente ya escribimos sobre la campaña Payroll Pirates, que utilizaba phishing AitM contra Microsoft 365, así como sobre la plataforma NovaCookies para el robo de sesiones de Microsoft 365. La campaña actual se distingue por el nivel de automatización y la separación de la infraestructura de interceptación y reproducción, lo que complica su detección.
Indicadores de compromiso
Huntress publicó las siguientes direcciones IP relacionadas con la infraestructura de reproducción de tokens:
193.26.115[.]221— host de reproducción y registro de dispositivos (fase 1, julio–agosto)193.26.115[.]199— host de reproducción de sesiones (fase 1)193.26.115[.]16— host de reproducción y device-code phishing (fase 2)193.26.115[.]21,193.26.115[.]72,193.26.115[.]210
Direcciones adicionales relacionadas con la campaña: 124.198.132[.]33, 45.83.31[.]44, 192.159.99[.]172, 185.238.2[.]195, 167.148.41[.]96.
Recomendaciones de respuesta
Huntress subraya que el restablecimiento de la contraseña por sí solo es insuficiente: no elimina los dispositivos y métodos de MFA registrados por el atacante, y el token de acceso sigue siendo válido aproximadamente 90 minutos después del restablecimiento. Acciones recomendadas:
- Revocar todas las sesiones activas y restablecer la contraseña, exactamente en ese orden
- Comprobar los dispositivos de Entra ID y eliminar los registros desconocidos del tipo
DESKTOP-* - Auditar los métodos de MFA y eliminar las aplicaciones autenticadoras desconocidas
- Revisar las reglas de procesamiento de correo, buscando reglas con nombres de una sola letra o con solo un punto
- Comprobar las aplicaciones corporativas registradas para detectar aplicaciones no autorizadas
- Configurar políticas de acceso condicional: exigir MFA (o bloquear) para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente sin excepciones
- Restringir la autenticación mediante device-code a través de Conditional Access
Las organizaciones que utilizan Microsoft 365 deben revisar de inmediato los registros de inicio de sesión en busca de autenticaciones desde el rango 193.26.115[.]0/24, auditar los dispositivos registrados y los métodos de MFA en Entra ID, y asegurarse de que las políticas de acceso condicional cubren todos los tipos de aplicaciones y usuarios sin excepciones. El bloqueo únicamente del rango de IP de reproducción no eliminará la amenaza: la infraestructura de interceptación de tokens se encuentra en direcciones separadas y los atacantes cambian de host con regularidad.
