Campaña de distribución y repetición de tokens de Microsoft 365 compromete cuentas de correo empresarial

Agradecimientos: Un agradecimiento especial a Anton Ovrutsky por sus contribuciones a esta investigación y redacción.

Contexto

Entre el 14 de julio de 2026 y el 22 de septiembre de 2026, Huntress detectó 497 eventos de inicio de sesión de Microsoft 365 en 79 organizaciones víctimas relacionados con una campaña de repetición de tokens que usaba un bloque de direcciones IP del proveedor de hosting alemán 1337 Services GmbH. En lugar de adivinar contraseñas, el atacante reutilizó tokens de inicio de sesión robados a las víctimas, y hemos rastreado más de 200.000 intentos de inicio de sesión fallidos de la ventana de la campaña hasta el rango de direcciones IP 193.26.115[.]0/24.

Figura 1: Estadísticas generales de la actividad que observó Huntress

Figura 2: Eventos de inicio de sesión exitosos mediante repetición de tokens a lo largo de la campaña

También conocida como AS210558, 1337 Services GmbH está constituida en Hamburgo, Alemania. Si bien 1337 Services GmbH ofrece un servicio legítimo de hosting de IP, los atacantes usan este tipo de proveedores de ISP para alojar tráfico malicioso, una táctica conocida como "trae tu propia IP" (BYOIP). Un artículo de Krebs on Security de febrero de 2025 sugiere que el fundador de 1337 Services GmbH podría haber operado el foro de cibercrimen Cracked.

Las cuentas de Microsoft se vieron comprometidas sin que el atacante necesitara nunca una contraseña. En un ataque de adversario en el medio (AiTM), la víctima inicia sesión a través de un relay que se ubica entre ella y Microsoft. El relay deja pasar la página de inicio de sesión real y la solicitud de MFA hacia la víctima, y luego conserva el token de "prueba de inicio de sesión" que Microsoft emite una vez que la víctima termina de iniciar sesión. Como ese token se genera después del MFA, quien lo tenga no necesita volver a pasar el MFA. El actor de amenazas luego reutilizó los tokens robados desde sus propias máquinas en intentos automatizados de inicio de sesión contra los servicios de Microsoft 365. Dado que el atacante reutilizó muchos tokens robados en volumen en muchas organizaciones, nos referimos a esto como "pulverización de tokens": el mismo patrón que el ataque de pulverización de contraseñas, pero con tokens robados en lugar de contraseñas adivinadas.

En esta campaña, los tokens provinieron de múltiples fuentes: relays de AiTM detrás de páginas de inicio de sesión falsas, phishing de código de dispositivo e ingeniería social durante un proceso de inicio de sesión legítimo.

Huntress detectó esta actividad por primera vez el 14 de julio de 2026, cuando un inicio de sesión desde 193.26.115[.]221 provino de un dispositivo unido a Entra llamado DESKTOP- seguido de ocho caracteres hexadecimales. Microsoft marcó de forma independiente la misma infraestructura: Microsoft Entra ID Protection generó detecciones verificadas de direcciones IP de actores de amenazas contra 193.26.115[.]221, 193.26.115[.]72, 193.26.115[.]16 y 193.26.115[.]21 en múltiples inquilinos de clientes. Microsoft describe esta detección como "actividad de inicio de sesión que es consistente con direcciones IP conocidas asociadas a actores estatales o grupos de cibercrimen, según Microsoft Security Intelligence (MSTIC)".

Una detección del 21 de julio desde 193.26.115[.]199 nos dio una vista de cómo el atacante pudo robar y reutilizar un token en menos de una hora:

Registrar su propia app autenticadora es un método de persistencia. Un token de sesión robado eventualmente caduca o se revoca, pero un método de MFA permanece en la cuenta. Con su propio autenticador registrado, el atacante puede completar el MFA para nuevos inicios de sesión cuando quiera, y ese acceso sobrevive a un restablecimiento de contraseña a menos que alguien audite los métodos de MFA de la cuenta y elimine el fraudulento. En 19 organizaciones, los métodos de MFA existentes de la víctima se eliminaron y se registró un nuevo método dentro de las tres horas posteriores al primer inicio de sesión desde una dirección de la campaña.

Los dispositivos fraudulentos cumplieron el mismo propósito. En los compromisos que investigamos, el actor de amenazas registró al menos 48 computadoras falsas en los directorios de Microsoft de las organizaciones víctimas. Un dispositivo registrado puede darle al atacante una forma más duradera de solicitar tokens que la sola sesión robada, y permanece en el directorio hasta que alguien lo elimina.

También observamos que el actor de amenazas configuraba reglas de correo ocultas en las bandejas de entrada de las víctimas que movían discretamente los mensajes de contactos específicos fuera de la vista. En al menos un caso, el actor de amenazas usó la cuenta de correo para enviar un correo relacionado con nómina a un contacto externo. Ninguna de las reglas de correo se creó desde la red de 1337 Services GmbH; cada una provino de una dirección alquilada o VPN diferente.

Detalles técnicos

A lo largo de la campaña de 10 semanas, el actor de amenazas reutilizó sesiones robadas de Microsoft 365 usando hosts alquilados dentro de un bloque de direcciones IP, 193.26.115[.]0/24. Usaron seis direcciones del rango /24, una tras otra:

Figura 3: Direcciones IP usadas a lo largo de la campaña de pulverización de tokens

No podemos afirmar con certeza por qué el operador rotó las direcciones, pero el efecto es claro. Un bloqueo, alerta o regla de acceso condicional escrita para una dirección no hace nada contra la siguiente, y Microsoft marcó las direcciones de forma individual: sus incidentes nombraron a 193.26.115[.]221, 193.26.115[.]72, 193.26.115[.]16 y 193.26.115[.]21, no el rango. Varios cambios siguieron a un período de calma, alrededor de dos semanas entre las Fases 1 y 2 y una semana antes de la toma de control del 22 de septiembre. Bloquear una sola dirección habría detenido como máximo una fase. Bloquear el /24 habría cubierto los seis hosts principales de repetición, aunque el operador también usó algunas otras direcciones de 1337 Services fuera de ese bloque.

Dos niveles: los relays capturan, 1337 repite

El operador dividió el ataque en dos tipos de infraestructura. Primero, la víctima inicia sesión a través de un relé AiTM. El relé transmite la solicitud de MFA de la víctima y conserva la sesión resultante. Luego, en cuestión de minutos, la sesión robada reaparece desde una dirección de 1337 Services. El 21 de julio, el intervalo entre el momento en que la víctima llegó a la solicitud de MFA y la aparición de la sesión secuestrada fue de 12 minutos. El 22 de septiembre, fue de cuatro.

Debido a que las dos mitades están en proveedores distintos, bloquear el rango de 1337 no impide que se capturen las credenciales, y bloquear un relé no impide la repetición de tokens que ya fueron robados.

Dos compilaciones

Los hosts de repetición ejecutaron dos conjuntos de herramientas distintos, que llamamos Build A y Build B:

En los inicios de sesión de Build A, observamos 48 dispositivos distintos unidos a Entra llamados DESKTOP- más exactamente ocho caracteres hexadecimales en mayúsculas (por ejemplo, DESKTOP-54521F46). Eso no coincide con el valor predeterminado de fábrica de Windows, que es DESKTOP- más siete caracteres alfanuméricos.

Con estos cambios en las direcciones IP llegaron variaciones en las tácticas. Rastreamos cuatro fases distintas a lo largo de la campaña. 

Figura 4: Cronología de la campaña de repetición de tokens

Fase 1: La ola de julio (193.26.115[.]221 y 193.26.115[.]199)

Huntress comenzó a observar tokens robados que se usaban para acceder a más de una docena de organizaciones a partir del 14 de julio de 2026. En 13 de los 14 incidentes a los que Huntress respondió ese día, el atacante había registrado un equipo falso con estilo Windows en el directorio de la organización víctima, nombrado DESKTOP- más ocho caracteres hexadecimales. Todos estos inicios de sesión usaron la Compilación A: el user agent node, reproduciendo tokens a través del cliente de Microsoft Office. Después de registrar el dispositivo fraudulento desde la dirección de 1337 Services GmbH, el atacante a menudo cambiaba a una dirección de ExpressVPN o CrownCloud para seguir actuando. Junto a esto, 193.26.115[.]199 ejecutó la Compilación B, reproduciendo sesiones de navegador directamente desde relés AiTM, como en la línea de tiempo del 21 de julio mostrada arriba.

El atacante creó reglas de correo malicioso en varias de las cuentas comprometidas para eliminar o mover mensajes con ciertas palabras clave a una carpeta poco visible, como RSS Feeds. En un buzón comprometido, se creó una regla de correo llamada sss para marcar todo el correo entrante como leído y luego eliminarlo. El atacante luego usó el buzón para enviar spam saliente a cientos de destinatarios externos antes de que Microsoft Entra ID Protection calificara la cuenta como de alto riesgo, y Huntress deshabilitó la regla.

La última vez que detectamos actividad desde la dirección IP 193.26.115[.]221 fue el 3 de agosto. Para entonces, el atacante había iniciado sesión con éxito en 37 organizaciones y había registrado 37 dispositivos fraudulentos en Entra.

Fase 2: La ola de agosto-septiembre (193.26.115[.]16 y 193.26.115[.]21)

Después de una pausa de dos semanas, el actor de amenazas regresó usando dos nuevas direcciones IP el 17 de agosto. Esta ráfaga trajo más reglas de ocultamiento de correo, y en un caso el actor de amenazas registró una dirección web que imitaba la de un socio comercial.

Esta ola también sumó phishing por código de dispositivo. Registramos inicios de sesión a través del flujo de código de dispositivo de Microsoft Office desde 193.26.115[.]16, donde se engaña a la víctima para que ingrese un código en la página legítima de inicio de sesión de Microsoft y entregue directamente al atacante un token de actualización y de acceso válido, autorizando sin saberlo la sesión del atacante. La misma dirección también inició sesión en el Device Registration Service, el endpoint usado para unir nuevos dispositivos al inquilino. 193.26.115[.]21 reprodujo tokens contra SharePoint Online con un user agent simple Mozilla/5.0.

En esta segunda ola, comenzamos a observar que el atacante borraba la configuración de MFA de los usuarios comprometidos para permitir el registro de dispositivos por primera vez sin tokens de dispositivo ni contraseñas de un solo uso. El patrón era consistente: los métodos de MFA de la víctima se borraban a través del servicio de registro de información de seguridad de Microsoft, y minutos después se registraba un nuevo autenticador. En un incidente, observamos que el actor de amenazas usaba un método de autenticación sin dispositivo que ya estaba en la cuenta.

Fase 3: La ráfaga del 11 de septiembre (193.26.115[.]72)

En la tarde del 11 de septiembre, el actor de amenazas volvió a cambiar a una nueva dirección, esta vez ejecutando un programa automatizado (user agent node) que reutilizaba credenciales de inicio de sesión robadas. En menos de dos horas, Huntress envió informes de incidentes a 22 clientes. Cada inicio de sesión que registramos desde esta dirección usó el cliente de Microsoft Office o Authentication Broker y solicitudes OAuth2:Token (la acción de intercambiar un token por otro), la mayoría dirigidas a Microsoft Graph. En cuatro días, la dirección completó 303 inicios de sesión exitosos en 29 organizaciones.

El acceso condicional hizo un trabajo real aquí. La misma dirección registró 1.052 inicios de sesión bloqueados mientras los intentos continuaban, pero todos esos bloqueos provinieron de solo cuatro organizaciones. En las 29 organizaciones donde logró entrar, nada se interpuso en su camino.

En un incidente, el actor de amenazas usó el buzón comprometido para enviar un correo relacionado con nómina a la dirección de correo externa de un contador público. El atacante primero modificó una regla de bandeja de entrada llamada s para capturar cualquier mensaje que mencionara nómina, depósito directo, banco o bono. Cinco minutos después, desde la misma dirección de Interserver (167.148.41[.]96), crearon una segunda regla llamada d que marcaba como leído todo correo de la dirección del contador y lo movía a la carpeta Historial de conversaciones, ocultando efectivamente las respuestas de la víctima.

Fase 4: Retransmisión y repetición, del 2 al 22 de septiembre (193.26.115[.]210)

La dirección final combinó un relé AiTM en un proveedor de hosting diferente, Evoxt Sdn. Bhd. (2400:8d60:2::1:841d:5dd), con la repetición desde 193.26.115[.]210. Apareció por primera vez el 2 de septiembre. El 3 de septiembre, el atacante intentó repetir, desde 193.26.115[.]210, la sesión robada el día anterior, pero la sesión ya no era válida y el intento falló con el error SsoArtifactRevoked de Microsoft (AADSTS50133).

Después de una semana completa de calma tras la ráfaga de la fase 3, detectamos una toma final de sesión el 22 de septiembre. La víctima llegó al aviso de MFA a través del relé de Evoxt a las 20:46 UTC y lo completó un minuto después, desde un navegador macOS usando el cliente OfficeHome. A las 20:50, el atacante repitió la sesión desde 193.26.115[.]210. Al enrutarse a través de un operador de túnel VDI con protocolo de escritorio remoto, el sistema operativo de la sesión cambió de macOS a Windows, y el actor de amenazas accedió al correo de la víctima.

Posterior al compromiso: reglas de bandeja de entrada ocultas

Cada regla sospechosa de bandeja de entrada que encontramos en cuentas comprometidas en esta campaña se creó desde una VPN o hosting alquilado, nunca desde 1337 Services: ExpressVPN, NordVPN, CrownCloud, DataWagon, GLOBALTELEHOST, LeaseWeb, Dynu e Interserver. Los nombres de las reglas eran deliberadamente olvidables:

En cuatro buzones, las reglas se crearon a través de la API REST de Outlook en lugar de Outlook mismo, dos de ellas a los pocos minutos del primer inicio de sesión desde una dirección de la campaña.

La sesión robada dejó de funcionar

El operador seguía regresando. En una organización, intentaron reutilizar la misma sesión robada tres veces más en agosto: una vez desde 193.26.115[.]199 y dos veces desde otras direcciones de 1337 Services (45.83.31[.]44 y 192.159.99[.]172). Todos los intentos fallaron con el error SsoArtifactRevoked de Microsoft (AADSTS50133), que Microsoft devuelve cuando una sesión ya no es válida después de que una contraseña expira o se cambia. Aunque el token de actualización y la cookie de sesión hayan expirado, el token de acceso seguirá siendo válido a menos que las sesiones de identidad se hayan revocado o deshabilitado.

Guía de mitigación: acceso condicional al rescate

Como vimos en la masiva campaña de rociado de contraseñas de LSHIY que reportamos a principios de este año, las políticas de acceso condicional (CAP) pueden ayudar a cerrar algunas de las brechas de seguridad que la MFA no puede, siempre que se implementen adecuadamente. Las empresas que configuren CAP deben exigir MFA (o bloquear) para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente, sin condiciones.

No actives una respuesta basada en el volumen de intentos, ya que esto apunta a los inquilinos más atacados pero menos comprometidos; en su lugar, prioriza según la validez de las credenciales. La fase 3 muestra por qué: los 1.052 inicios de sesión bloqueados de 193.26.115[.]72 provinieron de cuatro organizaciones, y sus 232 inicios de sesión exitosos se distribuyeron en 28 organizaciones distintas, sin superposición entre ambos grupos. Clasificar a los inquilinos por intentos fallidos habría dirigido a los equipos de respuesta hacia las cuatro organizaciones donde el acceso condicional ya estaba funcionando.

Si sospechas de un compromiso por reutilización de tokens:

• Revoca las sesiones y restablece la contraseña. Restablecer la contraseña por sí solo no elimina los dispositivos ni los métodos de MFA registrados por el atacante. Además, debes revocar las sesiones; un simple restablecimiento de contraseña no invalida el token de acceso, lo que significa que el atacante podría mantener el acceso hasta que el token expire (con un tiempo de vida de aproximadamente 90 minutos)

• Audita los dispositivos de Entra. Investiga los dispositivos llamados DESKTOP-, Device- o Work Pc seguidos de ocho caracteres hexadecimales, especialmente los registrados desde direcciones IP de hosting. El patrón es poco común, pero no exclusivo de esta campaña, así que confirma antes de eliminarlos.

• Audita los métodos de MFA. Busca métodos de MFA que se hayan eliminado y vuelto a registrar en cuestión de minutos, y elimina cualquier autenticador que el usuario no reconozca.

• Revisa las reglas de la bandeja de entrada. Busca reglas con nombres de uno a tres caracteres o solo signos de puntuación, reglas que mueven correos a Fuentes RSS, Suscripciones RSS o Historial de conversación, y reglas basadas en términos de nómina o banca.

• Trata los bloqueos de acceso condicional (AADSTS53003) como una señal de que la credencial es válida, no como una protección garantizada. El bloqueo ocurre después de que la autenticación se realiza con éxito.

• Restringe el flujo de código de dispositivo con políticas de acceso condicional para flujos de autenticación. Si lo necesitas, crea cuentas de servicio con permisos restringidos y exclusiones según sea necesario.

• Busca inicios de sesión de tipo OAuth2:Token y Cmsi:Cmsi provenientes de infraestructura de hosting que usen el cliente de Microsoft Office o Authentication Broker con un agente de usuario node o un simple Mozilla/5.0. Es de esperar cierta automatización legítima; concéntrate en los inicios de sesión que afecten los buzones de los usuarios o el Device Registration Service.

• Busca nuevas aplicaciones empresariales. Los atacantes intentarán mantener la persistencia otorgando a nuevas aplicaciones acceso a un inquilino, con un nivel de acceso que varía según los permisos de la aplicación. Mejor aún, desactiva la posibilidad de que los usuarios estándar autoricen nuevas aplicaciones y, en su lugar, exige que soliciten su aprobación.

Asignación de MITRE ATT&CK

Indicadores de compromiso (IOC)

Los indicadores están agrupados por función. Cada dirección IP enlaza con VirusTotal y Censys.

Hosts de reproducción de tokens (1337 Services GmbH, AS210558)

Repetidores AiTM e infraestructura de acciones en buzones de correo

ID de aplicaciones cliente

Recursos de destino

Agentes de usuario

Tipos de solicitud y códigos de error

Artefactos del sistema y del buzón de correo