La misma IP entró en 29 empresas y rebotó en cuatro

Una dirección IP, 193.26.115.72, pasó por decenas de tenants de Microsoft 365 en cuatro días de septiembre. En cuatro organizaciones se quedó fuera 1.052 veces. En otras veintinueve entró, y el informe que lo cuenta lo resume así: «nada se interpuso». El atacante era el mismo, los tokens robados eran los mismos y el calendario también. Lo único distinto era la configuración que cada empresa tenía puesta antes de que nada de esto empezara.

Los dos grupos del mismo ataque

Los números salen del informe que Huntress publicó el 22 de octubre de 2026 sobre una campaña de token spray and replay contra Microsoft 365. La ventana es del 14 de julio al 22 de septiembre: diez semanas, 497 inicios de sesión válidos en 79 organizaciones y más de 200.000 intentos fallidos. Toda la actividad se concentró en el rango 193.26.115.0/24 de un proveedor de alojamiento alemán (1337 Services GmbH, AS210558, Hamburgo), con seis direcciones que el atacante fue rotando por fases.

El párrafo del informe sobre esa dirección dice, entero: «En cuatro días, la dirección completó 303 inicios de sesión con éxito en 29 organizaciones. El acceso condicional hizo trabajo de verdad aquí. La misma dirección registró 1.052 inicios de sesión bloqueados mientras los intentos continuaban, pero todos esos bloqueos vinieron de solo cuatro organizaciones. En las 29 organizaciones donde entró, nada se interpuso».

Hay que decir también que el informe no se cuadra consigo mismo, y como el título de este post depende de ello, lo ponemos encima de la mesa. En su sección de mitigación, el mismo documento da otra cuenta para la misma dirección: los mismos 1.052 bloqueos de cuatro organizaciones, pero 232 inicios con éxito en 28 organizaciones distintas, y precisa que no hay solape entre los dos grupos. 303 en 29 frente a 232 en 28. Usamos las del relato de la fase porque es donde aparecen junto a los 1.052 bloqueos, que es la comparación que nos interesa; las dos cuentas probablemente miden recortes distintos del mismo periodo. La diferencia es de una organización y no mueve nada de lo que viene después, pero quien vaya a la fuente se encontrará las dos cifras.

Un segundo matiz, porque es el tipo de cosa que se pierde al citar de oído: el informe no publica la configuración de acceso condicional de cada víctima, así que nadie de fuera puede decir «la política X paró el ataque en la empresa Y». Lo que sí está escrito, con número y atribución, es que la mitad defendida del reparto cabe en cuatro empresas y que lo que hizo el trabajo fue acceso condicional. Esa asimetría es el dato. Contra este ataque sí se puede hacer algo, y lo que separa a los dos grupos es si alguien se sentó a escribir una política.

El token se emite después del MFA

Aquí no hubo contraseñas adivinadas. La frase que resume la campaña es que «las cuentas de Microsoft fueron comprometidas sin que el atacante necesitara nunca una contraseña». Las tres vías de obtención que describe el informe son retransmisores adversary-in-the-middle que capturan la sesión ya posterior al MFA, phishing de código de dispositivo e ingeniería social durante un inicio de sesión legítimo.

La mecánica del primero es la que más cuesta explicar en una reunión. La víctima no ve una página falsa mal hecha: ve la página real de Microsoft, porque el retransmisor se la sirve tal cual. Mete su contraseña de verdad, le llega el aviso de MFA de verdad, lo aprueba, y entra. Todo funcionó. Lo que pasa es que la cookie de sesión que Microsoft emite al final de ese proceso se la queda el intermediario. Y esa cookie ya es, por definición, una sesión con el MFA cumplido: nadie se lo va a volver a pedir. Pedir un segundo factor más fuerte en esa pantalla no cambia nada, porque el robo ocurre un paso después de la pantalla.

Luego viene la parte industrial, que es de donde sale el nombre: los tokens se reproducen en bloque. Más de 200.000 intentos para 497 aciertos deja una tasa de acierto que no llega al 0,25%, y esa proporción cuenta la verdad del método. Aquí entramos en lectura nuestra, que el informe no desglosa a qué corresponden esos fallos: lo más probable es que la mayor parte de la bolsa sean tokens ya caducados o revocados, aunque también habrá bloqueos de acceso condicional y cuentas que ya no existen. El atacante no necesita distinguirlos; los prueba todos y se queda con los que aún respiran. Es fuerza bruta, pero contra sesiones en lugar de contra contraseñas, y el ruido forma parte del método.

Lo caro empezó después de entrar

Un inicio de sesión no vale dinero. Lo que vale dinero es quedarse. Y en eso la campaña fue cualquier cosa menos ruidosa:

• Dispositivos suyos dentro de tu directorio. El informe observa, en el conjunto de la campaña y acotado a una de las agrupaciones de cliente que llama Build A, «48 dispositivos distintos unidos a Entra, llamados DESKTOP- más exactamente ocho caracteres hexadecimales en mayúsculas». No son 48 en tu casa: son 48 repartidos entre las víctimas. Un equipo registrado es una forma de volver a entrar que ya no depende del token robado.
• El MFA del usuario, borrado y sustituido. «En 19 organizaciones, los métodos de MFA existentes de la víctima fueron eliminados y se registró un método nuevo en menos de tres horas desde el primer inicio de sesión de una dirección de la campaña.» Tres horas marca el reloj al que hay que responder.
• Reglas de bandeja con nombres que nadie lee. Los nombres documentados son ., sss, ss, iT, ,., ........, s y d. Marcaban como leído, borraban o movían correo a carpetas como Fuentes RSS, Suscripciones RSS o Historial de conversaciones. Nadie mira ahí. Esa es la idea: que el titular de la cuenta no vea una parte de su propio correo.

El orden importa: primero una llave que no caduca, luego el control del segundo factor, luego el silencio. De los tres pasos, el único que tu usuario podría llegar a notar es el tercero, que es justo el que está diseñado para que no lo note.

El control que ataca esto existe, y no cubre el navegador

Microsoft tiene un control pensado literalmente contra esto. Se llama protección de tokens y es un control de sesión de acceso condicional que, en palabras de su propia documentación, «intenta reducir los ataques de reproducción de token asegurando que Microsoft Entra ID solo acepte tokens de sesión de inicio ligados al dispositivo, como los Primary Refresh Tokens». La idea es la correcta: el token se ata criptográficamente al equipo, «de modo que aunque un actor malicioso robe el token, no pueda usarlo desde otro dispositivo». Exactamente el ataque del informe.

Ahora la letra pequeña, que está publicada y es la parte que casi nunca se cuenta. La tabla de disponibilidad por plataforma de esa misma página (revisión del 14 de agosto de 2026) dice: aplicaciones nativas en Windows, iOS/iPadOS y macOS, disponible con carácter general; aplicaciones basadas en navegador, vista previa en Windows y macOS y no soportado en iOS/iPadOS. Y el alcance de esa vista previa es más estrecho de lo que suena: «el soporte de aplicaciones basadas en navegador está limitado actualmente a aplicaciones web, navegadores y configuraciones de dispositivo seleccionadas que acceden a Azure Resource Manager». Los recursos donde sí se aplica para aplicaciones nativas son Exchange Online, SharePoint Online y Microsoft Teams, más Azure Virtual Desktop y Windows 365 en Windows.

Junta las dos cosas y sale la frase incómoda del día: para la vía de robo de esta campaña, el control que la ataca todavía no está disponible con carácter general. Un retransmisor adversary-in-the-middle roba una sesión de navegador, y ahí la protección de tokens va por vista previa y acotada a Azure Resource Manager. Conviene no convertir eso en una ley general: los tokens también se roban en el lado nativo, por ejemplo con un infostealer en el equipo, y para ese caso el control sí está maduro. Tampoco es una pega que haya que esconder: es comportamiento documentado, y la misma página pide desplegarlo en modo solo informe antes de forzarlo. Lo que sí cambia es lo que puedes prometer en una reunión. Si alguien te dice «lo tenemos cubierto, hemos activado protección de tokens», la pregunta siguiente es: ¿en nativo o en navegador, y para qué recursos?

Qué para qué, fase por fase

Cambiar la contraseña no echa a nadie

El informe lo dice en dos frases que deberían estar pegadas en el procedimiento de cualquiera: «un restablecimiento de contraseña por sí solo no elimina los dispositivos ni los métodos de MFA registrados por el atacante» y «además, hay que revocar las sesiones; un restablecimiento de contraseña por sí solo no invalida el token de acceso, lo que significa que el atacante podría mantener el acceso hasta que el token caduque (tiempo de vida de aproximadamente 90 minutos)». Las dos van en la misma dirección: la contraseña no era el camino de entrada, así que cambiarla no cierra el camino de entrada.

Es la misma lección que contábamos al leer el informe de ransomware de este mes y que resumimos entonces en que recuperar rápido no es echar al atacante: volver a tener los servicios en pie y haber expulsado al que entró son dos trabajos distintos, y el primero se mide en horas mientras el segundo se mide en qué has mirado. Aquí lo que hay que mirar está enumerado: dispositivos, métodos, reglas.

Cuándo NO: dos cosas que parecen la respuesta

No cierres esto bloqueando direcciones. Es lo primero que pide todo el mundo cuando ve un rango concreto en un informe, y es tentador porque se hace en diez minutos y queda bien en el acta. Pero el propio informe cuenta seis direcciones del mismo /24 usadas de forma secuencial a lo largo de cuatro fases: el bloqueo que escribes hoy cubre la foto de ayer. Hay un caso en que sí vale la pena, y es distinto: bloquear ahora, con el incidente abierto, para ganar horas mientras ordenas lo demás. Como medida permanente es un indicador de compromiso convertido en política de seguridad, que no es lo mismo.

Y no bajes la vida de las sesiones por reflejo. Acortar la frecuencia de reautenticación suena a solución y tiene una factura que se paga en otro sitio. Un token robado se usa dentro de su ventana, así que pasar de días a horas reduce el margen sin cerrarlo; a cambio, todo el mundo empieza a ver avisos de inicio de sesión varias veces al día. Y un usuario entrenado durante meses a aprobar avisos sin pensar es, exactamente, el usuario que el próximo retransmisor necesita. El ajuste que sí mueve la aguja es el de la primera fila de la tabla: credenciales que un intermediario no puede retransmitir. Con una advertencia que nos toca dar aunque reste: de las tres vías del informe, esa credencial solo cierra la del retransmisor. Contra el phishing de código de dispositivo y contra la ingeniería social durante un inicio legítimo no hace nada, porque ahí el usuario se autentica de verdad en la página de verdad; para ésos toca bloquear el flujo de código de dispositivo si no lo usas y enseñar qué pide y qué no pide el soporte.

La comprobación de esta tarde

Seis pasos. Los cuatro primeros son de mirar y se hacen hoy; los dos últimos son de decidir, y son los que cambian el resultado la próxima vez.

1. Lista los dispositivos de Entra registrados en los últimos noventa días y compáralos con el inventario, no con tu memoria. Busca nombres del tipo DESKTOP- seguidos de ocho caracteres hexadecimales que nadie reconozca. Si tu inventario de equipos vive en una hoja que nadie actualiza, este paso te va a doler y por eso es el primero.
2. Saca del registro de auditoría los cambios en métodos de autenticación de los últimos tres meses. Lo que buscas es un patrón: un borrado y un registro nuevo para el mismo usuario dentro de la misma hora. Cada vez que aparezca, se llama al usuario y se le pregunta. No se asume.
3. Recorre las reglas de bandeja de todos los buzones con Get-InboxRule y quédate con dos cosas: nombres de uno o dos caracteres y destinos del tipo Fuentes RSS, Suscripciones RSS o Historial de conversaciones. Aprovecha para listar reenvíos externos; es el mismo barrido y responde a la otra mitad de la pregunta.
4. Caza en los inicios de sesión lo que recomienda el propio informe: peticiones de tipo OAuth2:Token y Cmsi:Cmsi con agentes de usuario node o un Mozilla/5.0 a secas. Un agente de usuario no prueba nada por sí mismo, pero es un filtro baratísimo para empezar a leer.
5. Lee tus políticas de acceso condicional por sus exclusiones, no por sus nombres. La recomendación del informe es exigir MFA o bloquear «para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicación cliente, sin condiciones». Cuenta cuántas de tus políticas cumplen eso de verdad una vez descuentas las excepciones que alguien metió un martes por una urgencia que ya se resolvió. Y mira también las políticas de acceso condicional que no escribiste: en tu tenant hay políticas que no redactaste tú.
6. Decide a qué veinte personas les pones credencial resistente a phishing este trimestre. No a todo el mundo a la vez, que es como se consigue no empezar nunca: los que firman pagos, los que tienen roles privilegiados y los que hablan con proveedores. Y escribe el procedimiento de expulsión en seis líneas —revocar sesiones, dispositivos, métodos, reglas, reenvíos, aviso al usuario por un canal que no sea su correo—, porque tres horas no dan para improvisarlo.

Dónde encaja esto en lo que hacemos

Nosotros desplegamos y mantenemos tenants de Microsoft 365 de otras empresas, y lo que este informe retrata se arregla configurando, que es un trabajo que alguien tiene que hacer un día cualquiera, cuando no hay incidente. Eso es la parte menos vistosa del puesto de trabajo moderno —inventario de equipos que cuadre, métodos de autenticación revisados, reglas de buzón que nadie puso a escondidas— y es la que decide en qué grupo del reparto de arriba acabas. La capa de Zero Trust es el nombre formal de la idea: que una sesión válida no sea, por sí sola, permiso para todo.

Si quieres que hagamos los cuatro primeros pasos contigo sobre tu tenant —dispositivos, métodos, reglas de bandeja y la caza en los inicios de sesión—, hablamos. Es una tarde. Y si sale limpio, te lo decimos y ya está: también es un resultado útil saber que no te toca.

Fuentes. La campaña, las fechas (14 de julio a 22 de septiembre de 2026), los 497 inicios de sesión válidos en 79 organizaciones, los más de 200.000 intentos fallidos, el rango 193.26.115.0/24 de 1337 Services GmbH (AS210558, Hamburgo) y sus seis direcciones, el reparto de 193.26.115.72 (1.052 bloqueos en cuatro organizaciones; 303 inicios con éxito en 29 organizaciones en el relato de la fase y 232 en 28 sin solape en la sección de mitigación —la discrepancia es del documento, no nuestra, y la señalamos en el cuerpo—), los 48 dispositivos unidos a Entra con nombre DESKTOP- más ocho hexadecimales observados en el conjunto de la campaña y acotados a Build A, las 19 organizaciones con el MFA borrado y re-registrado en menos de tres horas, los nombres de las reglas de bandeja y sus carpetas de destino, la caza por tipo de petición y agente de usuario y las frases sobre el restablecimiento de contraseña y la revocación de sesiones: Huntress, «M365 Token Spray and Replay Campaign Compromises Business Email Accounts» (22 de octubre de 2026). La cobertura con la que llegó el caso: Help Net Security, 23 de octubre de 2026. La definición de la protección de tokens, la tabla de disponibilidad por plataforma (nativo disponible con carácter general; navegador en vista previa en Windows y macOS y no soportado en iOS/iPadOS), el límite de la vista previa a aplicaciones web seleccionadas que acceden a Azure Resource Manager, los recursos soportados y la recomendación de desplegar en modo solo informe: Microsoft Learn, «How Token Protection Enhances Conditional Access Policies» (revisión del 14 de agosto de 2026). Todo verificado el 24 de octubre de 2026. Lo que no está en esas fuentes —qué política concreta tenía cada víctima— no lo afirmamos: no es público.