Entre el 14 de julio y el 22 de septiembre de 2026, unos atacantes iniciaron sesión en cuentas de Microsoft 365 de 79 organizaciones sin necesitar nunca una contraseña, según una investigación de Huntress publicada por Help Net Security (en inglés). Reutilizaron tokens de sesión robados, registraron sus propios dispositivos, reemplazaron los métodos de MFA y ocultaron su rastro con reglas de bandeja de entrada. Cuando eso pasa, cambiar la contraseña del usuario no termina el ataque: la sesión, el dispositivo y el autenticador del atacante pueden seguir ahí.
Este artículo explica cómo funcionó la campaña, por qué cambiar la contraseña no expulsa al atacante y la lista de siete pasos que usan nuestros expertos para sacarlo de forma definitiva y evitar que vuelva.
Qué encontró Huntress
Los atacantes no adivinaron contraseñas. Usaron relés de tipo adversario en el medio, phishing de código de dispositivo e ingeniería social para capturar tokens de sesión, la prueba de que un usuario ya inició sesión y superó el MFA. Después reutilizaron esos tokens de forma masiva. Help Net Security lo resume así: las cuentas de Microsoft se comprometieron sin que el atacante necesitara nunca una contraseña.
| Fecha | Qué pasó |
|---|---|
| 14 de julio de 2026 | Primera actividad de la campaña |
| 21 de julio | Aparece una sesión robada 12 minutos después de que la víctima llegó al aviso de MFA; menos de una hora después se activa un autenticador llamado «iPhone 13» |
| 11 de septiembre | El atacante cambia de dirección y automatiza la reutilización de tokens: cientos de inicios de sesión exitosos en casi 30 organizaciones en cuatro días |
| 22 de septiembre | Última actividad observada; entre el aviso de MFA y la sesión secuestrada pasan solo cuatro minutos |
En toda la campaña, Huntress contó 497 inicios de sesión exitosos y más de 200.000 intentos fallidos. Una vez dentro, el atacante se aseguró de que un cambio de contraseña no lo dejara afuera:
- Dispositivos intrusos. Se registraron al menos 48 equipos en los directorios de Entra de las víctimas, con nombres «DESKTOP-» seguidos de ocho caracteres hexadecimales.
- Métodos de MFA nuevos. En 19 organizaciones se borraron los métodos de MFA existentes y se registró uno nuevo menos de tres horas después del primer inicio de sesión.
- Reglas de bandeja de entrada. Reglas llamadas «.», «sss» e «iT» borraban el correo entrante o lo marcaban como leído y lo movían a carpetas como Fuentes RSS.
- Fraude de nómina. Desde un buzón comprometido, el atacante escribió a un contador externo sobre la nómina y luego creó reglas para ocultar cualquier respuesta sobre nómina, depósito directo, banco o bonificación.
Hay un detalle que importa más que el resto: la misma dirección del atacante fue bloqueada 1.052 veces, siempre por cuatro organizaciones cuyas directivas de acceso condicional rechazaron los inicios de sesión. Los controles funcionaron donde estaban activos.
Por qué cambiar la contraseña no expulsa al atacante
Un token robado se salta la contraseña y el MFA, porque aparenta demostrar que ambos ya se cumplieron. Y nada de lo que el atacante agregó después de entrar depende de la contraseña. Por eso el playbook de robo de tokens de Microsoft trata «revocar los tokens actuales», «restablecer las contraseñas» y «deshabilitar las credenciales o dispositivos agregados» como pasos separados.
| Lo que deja el atacante | Por qué cambiar la contraseña no lo quita | Qué lo elimina |
|---|---|---|
| Sesiones y tokens activos | Los tokens emitidos antes del cambio pueden seguir funcionando hasta que se revocan o vencen | Revocar las sesiones del usuario y marcar la cuenta como comprometida |
| Un dispositivo registrado en Entra ID | El dispositivo es un objeto propio en su directorio y puede obtener sus propios tokens | Eliminar todos los dispositivos que registró la cuenta y que usted no reconoce |
| Un método de MFA nuevo | El autenticador del atacante sigue registrado en la cuenta | Eliminar los métodos desconocidos antes de volver a habilitar al usuario |
| Reglas de bandeja y reenvíos | Las reglas siguen funcionando en el buzón | Eliminar las reglas agregadas o modificadas y revisar los elementos enviados |
| Consentimientos de aplicaciones | Un permiso OAuth no depende de la contraseña | Revisar y revocar los consentimientos que el usuario no quiso dar |
En nuestra experiencia, el dispositivo y el autenticador son lo que más se pasa por alto, y justo eso permite que un atacante vuelva al día siguiente.
La lista de 7 pasos para expulsar al atacante
Siga estos pasos, en orden, para cada cuenta afectada. Los pasos 1 a 6 sacan al atacante; el paso 7 evita que vuelva.
| Paso | Qué hacer | Listo cuando |
|---|---|---|
| 1. Contener | Bloquear el inicio de sesión de la cuenta, revocar sus sesiones y marcarla como comprometida en Microsoft Entra ID Protection | Ningún inicio de sesión nuevo funciona en la cuenta |
| 2. Restablecer | Restablecer la contraseña (en cuentas híbridas, Microsoft recomienda hacerlo dos veces) | La contraseña y los tokens anteriores ya no sirven |
| 3. Dispositivos | Eliminar los dispositivos que registró la cuenta y que usted no reconoce. En esta campaña, los administradores buscaron «DESKTOP-» seguido de ocho caracteres hexadecimales | Solo quedan dispositivos conocidos |
| 4. Métodos | Eliminar los métodos de MFA desconocidos antes de volver a habilitar la cuenta y luego registrar de nuevo al usuario con un pase de acceso temporal y una passkey | Todos los métodos de la cuenta son del usuario |
| 5. Buzón | Eliminar las reglas de bandeja y los reenvíos agregados o modificados, y revisar los enviados en busca de fraude, como correos de nómina o de cambio de cuenta bancaria | Sin reglas ocultas; contactos afectados avisados |
| 6. Aplicaciones | Revisar los consentimientos de aplicaciones del usuario y las credenciales de aplicaciones agregadas durante el incidente | Sin consentimientos ni credenciales inesperados |
| 7. Cerrar la puerta | Aplicar los controles de la sección siguiente y conservar los registros de inicio de sesión y de auditoría al menos 90 días | Un token reutilizado desde otro dispositivo falla |
Conservar los registros no es un detalle. En los hallazgos de respuesta a incidentes del tercer trimestre de Cisco Talos (en inglés), el registro insuficiente fue la principal debilidad, presente en más del 40 % de los casos. Sin registros, no se puede saber a qué cuentas hay que expulsar al atacante.
Cerrar la puerta: los controles que frenan la reutilización de tokens
- Acceso condicional con un dispositivo conforme o conocido. Las cuatro organizaciones que bloquearon 1.052 intentos muestran el efecto. Un token reutilizado desde el equipo de un atacante no pasa la comprobación del dispositivo.
- Protección de tokens. Este control de acceso condicional hace que Entra ID acepte solo tokens vinculados al dispositivo para el que se emitieron. Según Microsoft Learn, está disponible de forma general para aplicaciones nativas en Windows, macOS e iOS/iPadOS, y cubre Exchange Online, SharePoint Online y Microsoft Teams. En el navegador sigue en versión preliminar y con alcance limitado. Microsoft recomienda empezar en modo de solo informe con un grupo piloto.
- MFA resistente al phishing. Las passkeys están vinculadas a la página de inicio de sesión real, así que un relé de adversario en el medio no puede completarlas. Nuestro plan de 90 días para desplegar passkeys muestra cómo llegar.
- Bloquear los flujos que no usa. Si sus usuarios nunca inician sesión con códigos de dispositivo, bloquee el flujo de código de dispositivo con una directiva de acceso condicional de flujos de autenticación.
- Controlar el registro de dispositivos. Exija MFA para registrar o unir dispositivos y genere alertas ante registros nuevos en cuentas privilegiadas y de alto valor.
Las mismas debilidades aparecieron en la campaña de Storm-0940: los atacantes ya operan a velocidad de máquina, y los minutos entre una sesión robada y un autenticador nuevo son el margen que usted tiene para evitar un ataque.
Cómo ayudan nuestros expertos
- Secure Access E-ntelligence muestra, con evidencia de su tenant, qué usuarios todavía dependen de métodos que se pueden retransmitir o robar con phishing, para que sepa dónde es más probable el robo de tokens.
- E-Visor reúne en un solo panel las señales de identidad, dispositivos, aplicaciones y nube, con señales de riesgo como un inicio de sesión desde un país nuevo y almacenamiento de registros a largo plazo para las investigaciones.
- E-Visor Teams App muestra a cada empleado su propia identidad, sus dispositivos y sus alertas de seguridad en Microsoft Teams, para que pueda detectar un «iPhone 13» que nunca agregó.
- El Micro-Vigilant SecOps Agent muestra a los responsables del SOC qué incidentes de Microsoft Defender XDR se están quedando atrás y quién está sobrecargado, para que un incidente de identidad no espere en la cola.
Preguntas frecuentes
¿El MFA detiene el robo de tokens?
No por sí solo. En un ataque de adversario en el medio, el usuario completa el MFA y el atacante roba la sesión resultante. Los métodos resistentes al phishing, como las passkeys, frenan el relé, y la protección de tokens hace que un token robado no sirva en otro dispositivo.
¿Qué es la reutilización de tokens?
Usar un token de sesión robado para entrar a una cuenta como si fuera el usuario, sin la contraseña ni el MFA. Huntress la observó a gran escala, con herramientas automáticas que reutilizaban tokens capturados en decenas de organizaciones.
¿Cómo sé si un atacante registró un dispositivo?
Revise los dispositivos registrados por el usuario en Microsoft Entra ID y las entradas del registro de auditoría sobre registro de dispositivos. En esta campaña, los dispositivos se llamaban «DESKTOP-» seguido de ocho caracteres hexadecimales.
¿Basta con cambiar la contraseña?
No. También debe revocar las sesiones, eliminar los dispositivos y métodos de MFA desconocidos, quitar las reglas de bandeja de entrada y revisar los consentimientos de aplicaciones. Si no, el atacante puede mantener o recuperar el acceso.
Siguiente paso
Los expertos en identidad de Synergy Advisors pueden revisar su tenant en busca de las brechas que aprovechó esta campaña: métodos débiles, registro de dispositivos abierto y falta de protección de tokens. Hable con nuestros expertos o vea la grabación del webinar Identity Protection Accelerator.
Fuentes
- Microsoft 365 accounts compromised with stolen sessions (23 oct 2026) Help Net Security, investigación de Huntress (en inglés)
- Playbook de robo de tokens Microsoft Learn
- Protección de tokens en el acceso condicional Microsoft Learn
- Cisco Talos: vishing de mesa de ayuda y tendencias de respuesta a incidentes del T3 (30 oct 2026) Help Net Security (en inglés)
