Tokens robados abren 497 sesiones de Microsoft 365 en 79 entidades

Entre el 14 de julio y el 22 de septiembre de 2026, un mismo operador inició sesión 497 veces en cuentas de Microsoft 365 de 79 organizaciones sin teclear una sola contraseña. Huntress, que publicó el análisis el 22 de octubre, cuenta más de 200.000 intentos fallidos desde el rango 193.26.115.0/24 del proveedor alemán 1337 Services GmbH y bautiza la técnica como token spraying, el mismo patrón que el password spraying pero con tokens de sesión robados en lugar de contraseñas adivinadas.

• Hecho: Huntress detectó 497 inicios de sesión con tokens robados en 79 organizaciones entre el 14 de julio y el 22 de septiembre de 2026, con más de 200.000 intentos fallidos desde 193.26.115.0/24.
• Afectados: tenants de Microsoft 365 de clientes de Huntress, sin desglose por país, con 97 cuentas comprometidas y 48 dispositivos falsos registrados en Entra ID.
• Estado: el informe con IoC y guía de mitigación se publicó el 22 de octubre, Microsoft marcó cuatro de las direcciones como IP de actor de amenaza verificado y no hay atribución a ningún grupo.
• Acción urgente: revocar sesiones antes de cambiar la contraseña, borrar dispositivos y métodos MFA ajenos, revisar las reglas de buzón y exigir MFA o bloqueo incondicional en el acceso condicional.

El resumen gráfico de Huntress añade un dato que el texto del informe no desglosa con tanta claridad: 97 cuentas comprometidas y 48 dispositivos falsos registrados en los directorios de Entra ID de las víctimas. Los autores del informe son Andrea Hatcher, Susannah Matt, Matt Poto y Andrew Schwartz, con la colaboración de Anton Ovrutsky. Ninguna de las 79 organizaciones aparece con nombre y Huntress no atribuye la campaña a ningún grupo conocido.

Un relay AiTM captura la sesión y 1337 Services la reproduce en minutos

El informe de Huntress lo resume en una frase: «The Microsoft accounts were compromised without the attacker ever needing a password» (las cuentas de Microsoft se comprometieron sin que el atacante necesitara nunca una contraseña). La víctima recibe un enlace de phishing, llega a una página falsa que actúa como relay adversary-in-the-middle (AiTM), ve la pantalla de inicio de sesión real de Microsoft y aprueba su MFA con normalidad. El relay deja pasar todo eso y se queda con el token que Microsoft emite al terminar. Como ese token se acuña después del segundo factor, quien lo tenga entra sin volver a pasar por la MFA.

Los tokens llegaron por tres caminos según Huntress: relays AiTM detrás de páginas de inicio de sesión falsas, phishing de código de dispositivo (device code) y ingeniería social durante un inicio de sesión legítimo. Son los mismos vectores que ya vimos en los kits de phishing que Microsoft desmanteló en octubre, con la diferencia de que aquí el robo y la reproducción del token corren en infraestructuras separadas.

Una detección del 21 de julio muestra la velocidad del circuito. A las 17:18:20 UTC un relay en 185.238.2[.]195 capturó a la víctima en la pantalla de MFA. A las 17:30:21 la sesión ya estaba secuestrada desde 193.26.115[.]199. A las 17:43:15 la misma sesión se usaba desde una segunda dirección de 1337 Services, 124.198.132[.]33, y a las 18:08:50 el atacante activó una app de autenticación nueva etiquetada como iPhone 13 en la cuenta. Entre la pantalla de MFA y la sesión secuestrada pasaron 12 minutos aquel día. El 22 de septiembre, en la última toma de control registrada, fueron cuatro.

Los servidores de reproducción corrían dos conjuntos de herramientas distintos, que Huntress llama Build A y Build B. El primero es un script que reproduce tokens con el user-agent node y los identificadores de cliente de Microsoft Office y Microsoft Authentication Broker. El segundo reproduce sesiones de navegador completas con un Chrome o Edge actual sobre Windows.

Microsoft vio la misma infraestructura por su cuenta. Entra ID Protection marcó las direcciones 193.26.115[.]221, [.]72, [.]16 y [.]21 con la detección de IP de actor de amenaza verificado en varios tenants. La documentación de Microsoft describe esa detección como actividad coherente con direcciones IP asociadas a actores estatales o a grupos de cibercrimen, calculada en tiempo real y disponible solo con licencia Entra ID P2.

Cuatro fases, seis direcciones IP y un pico de 303 sesiones en septiembre

El operador usó seis direcciones del bloque 193.26.115.0/24 una detrás de otra, con pausas de una o dos semanas entre algunas de ellas. Huntress no sabe por qué rotaba, pero sí mide el efecto: «Blocking any single address would have stopped one phase at most» (bloquear una sola dirección habría frenado una fase como mucho). Microsoft también las marcó una a una, no como rango.

La figura anterior, tomada del informe, sitúa cada dirección en el calendario. En la primera fase, del 14 de julio al 3 de agosto, 193.26.115[.]221 reprodujo tokens con Build A y 193.26.115[.]199 reprodujo sesiones de navegador con Build B. En 13 de los 14 incidentes atendidos el primer día, el atacante había registrado ya un equipo Windows falso en el directorio de la víctima. Cuando se apagó el 3 de agosto, la primera dirección había entrado en 37 organizaciones y registrado 37 dispositivos.

La segunda fase arrancó, según el texto del informe, el 17 de agosto (la cronología gráfica de Huntress marca el 19) con 193.26.115[.]16 y 193.26.115[.]21. Aquí aparecen el phishing de código de dispositivo a través del flujo de Microsoft Office, los inicios de sesión contra el servicio de registro de dispositivos y las reproducciones contra SharePoint Online con un user-agent Mozilla/5.0 desnudo. También empieza el borrado de métodos MFA de las víctimas para registrar después un autenticador propio.

El gráfico diario de inicios de sesión logrados, con datos de la telemetría de Huntress a 16 de octubre, deja clara la tercera fase. La tarde del 11 de septiembre 193.26.115[.]72 lanzó un programa automático que reutilizaba tokens robados y en dos horas Huntress envió informes de incidente a 22 clientes. En cuatro días esa dirección completó 303 inicios de sesión en 29 organizaciones. La misma dirección acumuló 1.052 bloqueos, todos procedentes de cuatro organizaciones cuyas políticas de acceso condicional rechazaron los intentos. «Conditional Access did real work here» (el acceso condicional hizo un trabajo real aquí), escriben los autores. En las 29 organizaciones donde entró no había nada que se lo impidiera.

La cuarta fase combinó un relay AiTM alojado en otro proveedor, Evoxt Sdn. Bhd., con reproducción desde 193.26.115[.]210. El 3 de septiembre el atacante intentó reproducir una sesión robada el día anterior y Microsoft la rechazó con el error AADSTS50133 (SsoArtifactRevoked), el que devuelve cuando una sesión ha dejado de ser válida tras un cambio de contraseña. El 22 de septiembre la víctima llegó a la pantalla de MFA a través del relay a las 20:46 UTC desde un navegador en macOS, la completó un minuto después y a las 20:50 el atacante ya leía su correo desde 193.26.115[.]210, con el sistema operativo de la sesión cambiado a Windows por el túnel de escritorio remoto que usaba.

Dispositivos DESKTOP-, MFA borrado y reglas de buzón de una letra

Un token robado caduca o se revoca. Un dispositivo registrado o un método MFA añadido se quedan en la cuenta hasta que alguien los borra, y eso es lo que el operador buscaba. Huntress contó 48 equipos falsos unidos a Entra ID con el nombre DESKTOP- seguido de exactamente ocho caracteres hexadecimales en mayúscula, por ejemplo DESKTOP-54521F46. El patrón no coincide con el nombre que Windows asigna por defecto, que lleva siete caracteres alfanuméricos tras el guion. Tras registrar el dispositivo desde la dirección de 1337 Services, el atacante solía saltar a una dirección de ExpressVPN o de CrownCloud para seguir trabajando.

La cronología gráfica del informe resume lo que cambió en cada fase: reproducción en masa y registro de dispositivos falsos en julio, relays y códigos de dispositivo en agosto, la ráfaga automatizada de septiembre y una única toma de sesión tardía al final. En 19 organizaciones, los métodos MFA de la víctima se borraron y se sustituyeron por uno nuevo en menos de tres horas desde el primer inicio de sesión de la campaña. El borrado se hacía a través del servicio de registro de información de seguridad de Microsoft y el autenticador nuevo aparecía minutos después. Con él, el atacante supera la MFA cuando quiere y sobrevive a un cambio de contraseña.

Las reglas de buzón son la parte más reconocible del BEC. Ninguna se creó desde la red de 1337 Services. Todas salieron de VPN comerciales o de hosting alquilado, entre ellos ExpressVPN, NordVPN, CrownCloud, DataWagon, GLOBALTELEHOST, LeaseWeb, Dynu e Interserver. Los nombres eran un punto, sss, ss, iT, una coma seguida de un punto, ocho puntos, s y d. Las acciones se repiten: marcar como leído y borrar, o mover a carpetas que nadie mira como RSS Feeds, RSS Subscriptions o Conversation History. En cuatro buzones las reglas se crearon por la API REST de Outlook y no desde el cliente, dos de ellas minutos después del primer inicio de sesión de la campaña.

El caso más elaborado ocurrió en la tercera fase. El atacante usó un buzón comprometido para enviar un correo sobre nóminas al contable externo de la empresa. Antes había modificado una regla llamada s para capturar cualquier mensaje que mencionara payroll, direct deposit, bank o bonus. Cinco minutos después, desde la dirección 167.148.41[.]96 de Interserver, creó una segunda regla llamada d que marcaba como leído todo el correo del contable y lo movía a Conversation History. Huntress no indica que llegara a producirse ningún pago. En otro buzón de la primera fase, una regla llamada sss marcaba como leído y borraba todo el correo entrante mientras la cuenta enviaba spam a cientos de destinatarios externos, hasta que Entra ID Protection la calificó de alto riesgo.

Direcciones IP, relays y client IDs que publica Huntress

El informe agrupa los indicadores por papel y los publica con la notación defang original, que reproducimos tal cual. Los tres identificadores de aplicación que aparecen en los inicios de sesión son los de productos legítimos de Microsoft, así que sirven para filtrar junto con el user-agent y el origen, nunca como indicador por sí solos.

Los identificadores de cliente son d3590ed6-52b3-4102-aeff-aad2292ab01c (Microsoft Office, Build A), 29d9ed98-a469-4536-ade2-f981bc1d605e (Microsoft Authentication Broker, Build A) y 4765445b-32c6-49b0-83e6-1d93765276ca (OfficeHome, Build B). Huntress mapea la campaña en MITRE ATT&CK con las técnicas T1557 (adversary-in-the-middle), T1566.002 (enlace de spearphishing), T1550.001 (token de acceso de aplicación), T1098.005 (registro de dispositivos), T1556.006 (modificación de MFA), T1564.008 (reglas de ocultación de correo) y T1090.003 (proxy multisalto).

Revocar sesiones, borrar dispositivos y auditar MFA en Entra ID

Huntress insiste en que un cambio de contraseña no cierra este tipo de intrusión. Las sesiones hay que revocarlas de forma explícita, porque el token de acceso sigue siendo válido hasta que caduca. El informe habla de unos 90 minutos de vida y la documentación de Microsoft sobre revocación de acceso fija el valor por defecto en una hora. Esa misma guía recoge los comandos de Microsoft Graph PowerShell para desactivar la cuenta, revocar los tokens de actualización y deshabilitar los dispositivos registrados del usuario.

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'usuario@empresa.es' -ConsistencyLevel eventual
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
    Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

Con la cuenta contenida, este es el orden de trabajo que proponemos a partir de las recomendaciones del informe.

1. Revoca las sesiones y restablece la contraseña de cada usuario con inicios de sesión desde 193.26.115.0/24 o desde las direcciones de la tabla anterior. Hazlo en ese orden y no te quedes solo con el cambio de contraseña.
2. Audita los dispositivos de Entra ID. Busca nombres DESKTOP-, Device- o Work Pc seguidos de ocho caracteres hexadecimales, sobre todo si se registraron desde direcciones de hosting. El patrón es raro pero no exclusivo de esta campaña, así que confirma antes de borrar.
3. Audita los métodos MFA. Busca métodos eliminados y vueltos a registrar en cuestión de minutos y elimina cualquier autenticador que el usuario no reconozca.
4. Revisa las reglas de bandeja de entrada. Interesan las de uno a tres caracteres o solo signos de puntuación, las que mueven correo a RSS Feeds, RSS Subscriptions o Conversation History y las que filtran por términos de nóminas o bancarios.
5. Trata un bloqueo de acceso condicional (AADSTS53003) como la prueba de que el atacante tiene una credencial válida, porque el bloqueo ocurre después de que la autenticación haya tenido éxito.
6. Exige MFA o bloquea, de forma incondicional, para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de cliente en las políticas de acceso condicional. Las cuatro organizaciones que frenaron la tercera fase lo tenían así.
7. Restringe el flujo de código de dispositivo con la condición de flujos de autenticación del acceso condicional. La guía de Microsoft es directa: «Microsoft recommends blocking device code flow wherever possible» (Microsoft recomienda bloquear el flujo de código de dispositivo siempre que sea posible).
8. Desactiva el consentimiento de usuarios estándar a aplicaciones nuevas y revisa las aplicaciones empresariales añadidas desde julio.
9. Si confirmas acceso a buzones con datos personales, prepara la notificación a la AEPD dentro de las 72 horas que fija el RGPD. Las empresas pueden notificar el incidente a INCIBE-CERT y las administraciones públicas, al CCN-CERT.

Para los pasos dos y cuatro, estas dos consultas listan los dispositivos con el patrón de nombre y las reglas de cada buzón, la primera con Microsoft Graph PowerShell y la segunda con Exchange Online PowerShell.

Get-MgDevice -All | Where-Object { $_.DisplayName -match '^(DESKTOP|Device|Work Pc)-[0-9A-F]{8}$' } |
    Select-Object DisplayName, RegistrationDateTime, TrustType, Id
Get-InboxRule -Mailbox usuario@empresa.es |
    Select-Object Name, Enabled, MoveToFolder, DeleteMessage, MarkAsRead, SubjectOrBodyContainsWords

Para el threat hunting en Microsoft Sentinel, esta consulta KQL busca durante los últimos 90 días los intercambios de token desde el rango del informe o con los user-agents de Build A contra los clientes de Office y del Authentication Broker. Espera algo de automatización legítima y céntrate en los resultados que tocan buzones de usuario o el servicio de registro de dispositivos.

SigninLogs
| where TimeGenerated > ago(90d)
| where IPAddress startswith "193.26.115."
    or (UserAgent in ("node", "Mozilla/5.0")
        and AppId in ("d3590ed6-52b3-4102-aeff-aad2292ab01c", "29d9ed98-a469-4536-ade2-f981bc1d605e"))
| project TimeGenerated, UserPrincipalName, IPAddress, UserAgent, AppDisplayName, ResourceDisplayName, ResultType
| order by TimeGenerated desc

Cuando cerramos esta noticia, el 24 de octubre de 2026, INCIBE-CERT y el CCN-CERT no habían publicado ningún aviso propio sobre esta campaña y Huntress no desglosa las víctimas por país. Lo que sí sabemos es que Microsoft 365 es el correo corporativo de buena parte de la pyme española y que la técnica no distingue idiomas.

Lo que el informe deja fuera y el hilo que une Railway, LSHIY y 1337 Services

Las cifras de Huntress son un suelo, no un techo. La empresa vende detección y respuesta gestionada para pymes y proveedores de servicios, de modo que solo ve lo que pasa en los tenants de sus clientes. Las 79 organizaciones y los 497 inicios de sesión son lo que ese parque permitió observar, y el propio gráfico diario avisa de que los recuentos son un mínimo. Tampoco hay desglose por sectores ni por países, y el informe no cuantifica cuánto dinero se intentó desviar con el correo de las nóminas.

Sobre 1337 Services GmbH, Huntress se limita a describirla como un proveedor legítimo de alojamiento de IP, el sistema autónomo AS210558 con sede en Hamburgo, usado por terceros bajo el modelo que el sector llama bring your own IP. El informe remite a la investigación de Brian Krebs del 4 de febrero de 2025, según la cual el fundador de la empresa pudo haber operado el foro de cibercrimen Cracked, incautado en la operación Talent. Es una conexión que Krebs reconstruye a partir de registros mercantiles y perfiles públicos, no una acusación formal.

El patrón de la campaña tampoco es nuevo para Huntress. En marzo de 2026 describió una oleada de phishing de código de dispositivo alojada en la plataforma Railway que llegó a 344 organizaciones entre el 2 y el 19 de marzo, con el device code en el 87,4 % de las sesiones observadas. En junio documentó el password spraying de LSHIY LLC contra la CLI de Azure, con más de 81 millones de intentos entre el 12 y el 26 de junio y al menos 78 cuentas comprometidas, muchas de ellas en organizaciones que tenían acceso condicional pero mal delimitado. Y Microsoft contó el 4 de mayo una campaña AiTM con señuelos de código de conducta que alcanzó a más de 35.000 usuarios de 13.000 organizaciones en 26 países entre el 14 y el 16 de abril.

En el blog, esta es la tercera noticia en diez días sobre accesos a tenants de Microsoft 365 que no necesitan una contraseña. Primero fue la credencial de ConnectWise Cloud Backup que abrió 173 tenants, después la atribución de Microsoft a Storm-0940 de ese mismo ataque. Las tres apuntan a lo que defendíamos en nuestro análisis sobre la gestión de identidad y acceso en la nube: la identidad es el perímetro y el token es la llave. Una MFA por notificación push o por código de seis cifras protege de la contraseña filtrada, pero no de un relay que se queda con la sesión. Lo que sí resiste a ese relay son las credenciales ligadas al origen, como las passkeys FIDO2 que ya explicábamos cuando hablábamos de autenticación sin contraseña, combinadas con políticas que evalúan cada acceso según el modelo Zero Trust.

Queda un consejo operativo que Huntress deja casi al final y que conviene subrayar. Si tu SOC ordena los tenants por volumen de intentos fallidos, estará mirando a los cuatro que ya tenían el acceso condicional bien configurado. Ordena por credenciales válidas y busca los inicios de sesión que sí entraron.