Campaña de reutilización de tokens de Microsoft 365 afecta a 79 organizaciones mediante relés AitM
Huntress informa sobre una campaña entre julio y septiembre de 2026 que reutilizó tokens robados de Microsoft 365 para comprometer 97 cuentas en 79 organizaciones, registrando dispositivos Entra no autorizados y ocultando reglas de correo electrónico.
Traducido automáticamente del original en inglés.
Entre el 14 de julio y el 22 de septiembre de 2026, los atacantes utilizaron relés adversario-en-el-medio (adversary-in-the-middle) para robar tokens de inicio de sesión de Microsoft 365 y reutilizarlos contra los inquilinos (tenants) de las víctimas. Huntress rastreó esta actividad, que afectó a 79 organizaciones y comprometió 97 cuentas, mientras se registraban decenas de dispositivos Entra no autorizados.
Qué sucedió
Huntress observó más de 200.000 intentos de inicio de sesión vinculados a la campaña, lo que resultó en 497 inicios de sesión exitosos en Microsoft 365. A partir de esas sesiones, los actores de amenazas finalmente tomaron el control de 97 cuentas de usuario y registraron al menos 48 ordenadores falsos en los directorios de Microsoft de las víctimas. Los investigadores atribuyeron la mayoría de los intentos fallidos al rango de IP 193.26.115[.]0/24, con observaciones iniciales que apuntaban a una dirección rumana, 193.26.115[.]221.
Después de obtener acceso, los atacantes añadieron sus propias aplicaciones autenticadoras para mantener la persistencia y eludir futuros desafíos de MFA. En al menos 19 organizaciones, se eliminaron métodos de MFA existentes y se registraron nuevos dentro de las tres horas posteriores al primer inicio de sesión no autorizado. En un caso el 21 de julio de 2026, apareció un autenticador etiquetado como “iPhone 13” menos de 51 minutos después del secuestro de la cuenta.
Los intrusos también crearon reglas ocultas de bandeja de entrada con nombres como “.”, “sss” y “d” para eliminar o redirigir mensajes que contenían palabras clave como nómina, depósito y bonificación. Algunas reglas movían el correo a carpetas poco visibles como Feeds RSS e Historial de conversaciones, y en un buzón todos los mensajes entrantes fueron marcados como leídos y eliminados antes de que la cuenta se utilizara para enviar spam saliente.
Cómo funciona
La técnica principal es un relé adversario-en-el-medio que presenta una página de inicio de sesión falsa de Microsoft a la víctima. Cuando el usuario introduce sus credenciales y completa la autenticación multifactor, el relé reenvía esos datos al servicio real de Microsoft. El objetivo no es quedarse con la contraseña, sino capturar el token de acceso que Microsoft emite tras un inicio de sesión exitoso.
Una vez capturado el token, el atacante lo reutiliza desde su propia infraestructura en cuestión de minutos. Huntress denomina a este patrón “token spraying” porque muchos tokens robados se reutilizan a gran escala en múltiples organizaciones, similar a cómo el password spraying prueba una contraseña contra muchas cuentas. Dado que el token ya demuestra la autenticación, el atacante no necesita resolver el MFA nuevamente durante la sesión reutilizada.
Los tokens provenían de varios vectores, incluidos relés AitM detrás de páginas de inicio de sesión falsas, flujos de phishing por código de dispositivo e ingeniería social durante inicios de sesión legítimos. Los dispositivos no autorizados registrados brindan a los atacantes una ruta duradera para solicitar nuevos tokens incluso si una sesión robada expira o es revocada.
Detalles clave
- Cronología: Del 14 de julio al 22 de septiembre de 2026, según las observaciones de Huntress.
- Alcance: 79 organizaciones afectadas; 97 cuentas comprometidas; 497 inicios de sesión exitosos a partir de más de 200.000 intentos.
- Infraestructura: Intentos fallidos vinculados a 193.26.115[.]0/24; la IP inicial 193.26.115[.]221 está asociada con AsyncRAT y el host alemán 1337 Services GmbH.
- Persistencia: Los atacantes registraron al menos 48 dispositivos Entra no autorizados y añadieron sus propias aplicaciones autenticadoras; en 19 organizaciones, los métodos de MFA fueron reemplazados dentro de las tres horas.
- Evasión: Reglas ocultas de bandeja de entrada con nombres cortos o basados en puntos eliminaban o redirigían correos que hacían referencia a nómina, depósitos y bonificaciones.
- Orientaciones de mitigación: Revocar sesiones, restablecer contraseñas, auditar dispositivos Entra y métodos de MFA, revisar reglas de bandeja de entrada y aplicaciones empresariales, y restringir los flujos de código de dispositivo con Acceso Condicional.
Por qué importa
Para los equipos que gestionan Microsoft 365, esta campaña demuestra que un MFA fuerte por sí solo puede no detener la toma de control de cuentas cuando los tokens son interceptados y reutilizados. El ataque elude el segundo factor habitual reutilizando un token válido de prueba de inicio de sesión, y luego consolida el acceso registrando nuevos dispositivos y autenticadores. Esa combinación dificulta la detección y aumenta la ventana para el robo o abuso de datos.
El impacto operativo es inmediato: los buzones comprometidos pueden ser silenciados con reglas furtivas, las comunicaciones financieras pueden desaparecer y el spam saliente puede dañar la reputación del remitente. Dado que los dispositivos no autorizados persisten en el directorio hasta que se eliminan manualmente, la limpieza requiere una auditoría cuidadosa de los registros de Entra, las inscripciones de MFA y las políticas condicionales, en lugar de simplemente restablecer contraseñas.
Qué puedes hacer
- Revoca las sesiones activas y restablece las contraseñas de cualquier cuenta sospechosa, luego fuerza la reautenticación.
- Audita los registros de dispositivos Entra y elimina las entradas desconocidas o sospechosas, incluidos los ordenadores añadidos recientemente.
- Revisa los métodos de MFA de los usuarios afectados y elimina aplicaciones autenticadoras o números de teléfono no familiares.
- Busca reglas inesperadas de bandeja de entrada con nombres cortos o inusuales y verifica la redirección de correo a carpetas poco visibles.
- Restringe los flujos de autenticación por código de dispositivo utilizando políticas de Acceso Condicional para reducir el riesgo de AitM y phishing.
- Aplica el Acceso Condicional de forma amplia: exige MFA o bloquea el acceso para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente.



