Huntress registra 497 inicios de sesión en una campaña de replay de tokens M365

Huntress publicó el 23 de octubre una investigación sobre una campaña que reutilizó sesiones de Microsoft 365 en 79 organizaciones entre el 14 de julio y el 22 de septiembre de 2026. La empresa contó 497 inicios de sesión exitosos y más de 200.000 intentos fallidos en la telemetría de sus clientes. Son observaciones de Huntress durante su respuesta a incidentes, no una estimación del total de víctimas ni de toda la actividad contra Microsoft 365.

La sesión robada evita repetir el inicio de sesión

La campaña no fue simplemente una lluvia de contraseñas. Los atacantes capturaban tokens de sesión mediante relés adversary-in-the-middle (AiTM), phishing de código de dispositivo y otras formas de ingeniería social; luego los reproducían para entrar a servicios de Microsoft 365. En un AiTM, la víctima interactúa con un inicio de sesión real a través de un intermediario controlado por el atacante. Cuando termina el desafío multifactor, el token resultante puede quedar en manos del intermediario y usarse desde otra máquina.

Huntress observó que algunos accesos registrados desde una infraestructura de alojamiento aparecían pocos minutos después de la interacción de la víctima con el relé. El token representa una sesión ya autenticada, así que pedir MFA en el inicio original no invalida por sí mismo un token que fue robado después. Esto no significa que MFA sea inútil: describe por qué los métodos que resisten phishing y los controles vinculados al dispositivo tienen un papel distinto a un segundo factor susceptible de ser retransmitido.

-SecureCrew dice: Después del MFA, la sesión sigue siendo una credencial; que la roben no convierte al segundo factor en inútil, pero sí cambia qué debe protegerse.-

Persistencia detrás del primer acceso

En los entornos investigados, Huntress encontró al menos 48 dispositivos Entra registrados por el atacante. En 19 organizaciones, los investigadores vieron que se borraban los métodos MFA existentes y se añadía otro en pocas horas. También observaron reglas de bandeja de entrada para ocultar mensajes y un correo relacionado con nóminas enviado desde una cuenta comprometida. Son hallazgos concretos de esos entornos, no prueba de que todas las organizaciones sufran el mismo recorrido.

La diferencia entre sesión y persistencia importa para la respuesta. Huntress recomienda revocar las sesiones, restablecer la contraseña y retirar los dispositivos y métodos MFA que la investigación identifique como ajenos. Cambiar la contraseña sin revisar los métodos de autenticación no elimina necesariamente una vía de acceso que el atacante haya registrado, y una regla de buzón puede mantener oculta actividad incluso después de recuperar la cuenta.

-SecureCrew dice: Borrar el dispositivo recién registrado y dejar intacto el método MFA añadido en el mismo incidente es cerrar una puerta y conservar la llave.-

Qué puede aportar Token Protection

Microsoft documenta Token Protection como un control de Acceso Condicional que intenta reducir el replay al aceptar tokens de sesión vinculados criptográficamente al dispositivo en aplicaciones compatibles. No está disponible de forma universal para cualquier navegador y aplicación: el soporte varía por plataforma y por tipo de cliente; para algunas aplicaciones web sigue limitado a una vista previa. Microsoft recomienda comenzar con un grupo piloto, probar la política en modo de solo informe y revisar registros de inicio interactivos y no interactivos antes de exigirla.

En una investigación activa, los equipos deberían correlacionar inicios de sesión, registros de registro de dispositivos, cambios en métodos MFA y reglas de correo, y conservar los tiempos para reconstruir qué ocurrió primero. Los bloqueos de direcciones observadas pueden ayudar, pero Huntress vio cambios entre direcciones durante la campaña. Una lista estática de IP no sustituye controles de sesión ni revisión de identidad; tampoco debe asumirse que una alerta por sí sola detecta todas las variantes del replay.

La cifra principal sirve para entender la escala observada por el proveedor y la mecánica del acceso. No demuestra cuántas empresas fueron atacadas fuera de su base de clientes, ni identifica por sí misma quién operó la campaña. El aprendizaje defensivo sí es claro: recuperar una cuenta exige revisar lo que quedó autorizado dentro del tenant, no limitarse a cambiar la contraseña.

Diccionario de la Crew

Token de sesión — Credencial temporal que permite a una aplicación reconocer una sesión ya autenticada.
AiTM — Ataque adversary-in-the-middle que retransmite el inicio de sesión real y captura la sesión resultante.
Entra ID — Servicio de identidad de Microsoft utilizado para registrar usuarios y dispositivos.
Acceso Condicional — Políticas de Microsoft Entra que evalúan señales del usuario, dispositivo y sesión antes de conceder acceso.
Replay — Reutilización de una credencial o token legítimo capturado previamente.