Volver a la sala de prensa
Amenazas

Campaña de token replay en Microsoft 365 compromete 97 cuentas en 79 organizaciones

Los atacantes desviaron a las víctimas hacia páginas falsas de acceso de Microsoft, se quedaron con los tokens de sesión y los reutilizaron desde sus propios servidores. La campaña eludió el MFA, registró 48 dispositivos falsos y ocultó reglas de correo para fraudes de nómina. Qué ocurrió y cómo reforzar tu inquilino.

Campaña de token replay en Microsoft 365 compromete 97 cuentas en 79 organizaciones

Campaña de token replay en Microsoft 365 compromete 97 cuentas en 79 organizaciones

Una campaña de varios meses contra inquilinos de Microsoft 365 recuerda que la contraseña, e incluso el código MFA de un solo uso, dejan de importar en cuanto el atacante posee un token de inicio de sesión válido. Entre el 14 de julio y el 22 de septiembre de 2026, los atacantes desviaron a las víctimas hacia páginas de acceso que imitaban a Microsoft, capturaron los tokens emitidos tras cada inicio de sesión exitoso y los reutilizaron desde sus propias máquinas. El balance: 97 cuentas comprometidas en 79 organizaciones, 48 dispositivos falsos registrados en los directorios de las víctimas y reglas de bandeja de entrada diseñadas para ocultar fraudes de nómina.

Cómo funciona el ataque

El punto de entrada es una página de inicio de sesión de tipo adversary-in-the-middle (AitM). La víctima llega a una página idéntica al formulario de acceso de Microsoft, pero que en realidad se interpone entre ella y el servicio real. Todo lo que escribe, incluidos el usuario, la contraseña y el código MFA, se reenvía a Microsoft en tiempo real, de modo que el inicio de sesión funciona y nada parece fuera de lugar.

A los atacantes no les interesa la contraseña. Quieren el token de acceso que Microsoft emite una vez completados el inicio de sesión y la verificación MFA. Esa "prueba de inicio de sesión" se reutiliza en cuestión de minutos desde dispositivos controlados por los atacantes para lanzar intentos automatizados de acceso a los servicios de Microsoft 365, sin volver a pasar nunca por el MFA.

Como la misma técnica se aplicó a muchos tokens robados en muchas organizaciones a la vez, el patrón se ha bautizado como token spraying, el primo basado en tokens del password spraying.

Escala e infraestructura

Durante la ventana de la campaña, más de 200.000 intentos de inicio de sesión se rastrearon hasta un único rango de red, 193.26.115[.]0/24. De ellos, 497 tuvieron éxito. La primera actividad provino de una dirección geolocalizada en Rumanía dentro de ese bloque, asociada también con tráfico del troyano de acceso remoto AsyncRAT.

El rango pertenece a un proveedor de hosting alemán que alquila servidores virtuales, y varias direcciones del mismo bloque ya tienen reputación maliciosa o sospechosa. Marcas vinculadas a ese proveedor se vieron afectadas por una operación policial internacional en enero de 2025 y desde entonces han reaparecido con nuevos nombres. El operador ha negado públicamente cualquier implicación en actividades delictivas, así que conviene tratar el vínculo con la infraestructura como contexto y no como atribución.

Los tokens robados tampoco procedían de un único lugar. La campaña se apoyó en relés AitM detrás de páginas de acceso falsas, en phishing mediante device code y en ingeniería social aplicada mientras la víctima realizaba un inicio de sesión legítimo.

Persistencia: nuevos métodos MFA y dispositivos falsos

Una vez dentro, los atacantes actuaron rápido para que una sesión revocada no volviera a dejarlos fuera.

  • Su propia aplicación de autenticación. Registraron un nuevo método MFA para poder resolver ellos mismos los desafíos futuros. En al menos 19 organizaciones, los métodos MFA existentes de la víctima fueron eliminados y sustituidos en menos de tres horas desde el primer inicio de sesión malicioso. En un caso del 21 de julio de 2026, una aplicación de autenticación llamada "iPhone 13" estaba activa menos de 51 minutos después del secuestro de la sesión.
  • Dispositivos falsos. Al menos 48 equipos ficticios fueron registrados en los directorios de Entra ID de las organizaciones afectadas. Un dispositivo registrado ofrece una vía mucho más duradera para solicitar tokens nuevos que una sesión robada, y permanece en el directorio hasta que un administrador lo detecta y lo elimina.

Reglas de bandeja de entrada pensadas para el fraude de nómina

La actividad en los buzones apunta directamente al business email compromise. Se crearon reglas ocultas con nombres de relleno como ".", "s", "d", "iT", "sss" o una cadena de puntos para borrar los mensajes entrantes que mencionaban nómina, depósito o bonificación, o para moverlos a carpetas que rara vez se abren, como Fuentes RSS o Historial de conversaciones. Es la preparación clásica para desviar pagos de salarios o apoderarse de una conversación sobre una factura.

En un buzón comprometido, una regla marcaba como leído y eliminaba cada mensaje entrante. La cuenta se utilizó después para enviar spam a cientos de destinatarios externos antes de que Entra ID Protection la clasificara como de alto riesgo.

Por qué importa

El MFA estaba activo en estas organizaciones, y fue superado. El ataque transcurre por completo después de la autenticación, así que las señales que necesitas son distintas de las que vigilan la mayoría de los equipos:

  • un inicio de sesión exitoso desde una IP o un dispositivo nuevos, segundos o minutos después de uno legítimo;
  • un nuevo método MFA o una nueva aplicación de autenticación en una cuenta;
  • registros de dispositivos inesperados en Entra ID;
  • reglas de bandeja de entrada con nombres sin sentido, o reglas que borran o mueven correo;
  • nuevos consentimientos de aplicaciones empresariales.

Bloquear rangos de IP sirve durante un día. Los servidores virtuales alquilados son baratos y los operadores los rotan.

Qué hacer

Si sospechas de un compromiso por token replay en tu inquilino:

  1. Revoca todas las sesiones activas de la cuenta y después restablece la contraseña.
  2. Audita los dispositivos registrados en Entra ID y elimina todo lo que no puedas justificar.
  3. Revisa los métodos MFA de la cuenta y borra los que el usuario no haya añadido.
  4. Comprueba las reglas de bandeja de entrada, los reenvíos y las aplicaciones empresariales autorizadas recientemente.
  5. Restringe o bloquea el flujo de autenticación por device code mediante Conditional Access.

Para un refuerzo a largo plazo, las políticas de Conditional Access deberían exigir MFA, o bloquear el acceso directamente, para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicación cliente, sin excepciones por comodidad. Complétalo con autenticación resistente al phishing, como passkeys o llaves FIDO2, siempre que sea posible, configura alertas para los cambios de métodos MFA y los nuevos registros de dispositivos, y añade 193.26.115[.]0/24 a tus listas de vigilancia.

La configuración de identidad es una de las áreas que nuestros servicios de penetration testing examinan con más detalle en entornos Microsoft 365. Comprobamos si las políticas de Conditional Access, las restricciones de device code y las reglas de registro MFA detienen realmente un token reutilizado, para que encuentres la brecha antes que un atacante.

COMPARTIR