Agradecimientos: Un agradecimiento especial a Dave Kleinatland, Matt Kiely, Jamin Becker, Bryan Masters, Justin Allen, Arnelle French y Ben Nahorney por sus contribuciones a esta investigación y a este informe.
ACTUALIZACIÓN @ 15/07 a las 11 a. m. hora del Este
Sin dejarse desanimar después de ser expulsados de LSHIY LLC, los usuarios maliciosos de BYOIP simplemente trasladaron sus ataques de pulverización de contraseñas a otro lugar.
Poco después de nuestra última actualización, descubrimos que la actividad de pulverización se había trasladado a FranTech (AS53667) usando los rangos IPv6 2605:6400::/32 y 2605:6404::/32. Los objetivos siguieron siendo en gran parte los mismos, ya que el 87% de las cuentas atacadas desde FranTech ya habían sido atacadas previamente desde LSHIY. No es la primera vez que este ASN se ve involucrado en intentos de ataque de pulverización de contraseñas u otras actividades maliciosas.
Luego, comenzando hace aproximadamente una semana, apareció una nueva ronda de actividad proveniente de otro proveedor: 3xK Tech GmbH (AS200373). El nombre puede sonar familiar si consideramos que Cloudflare lo identificó como la mayor fuente de ataques DDoS por ASN el verano pasado, y GreyNoise lo señaló como responsable del 62% de la actividad de escaneo para una vulnerabilidad crítica descubierta hacia fines del año pasado.
Después de recibir un aviso de un asistente a nuestro episodio de Tradecraft Tuesday de julio, investigamos esta última ola de ataques. Con el traslado a 3xK Tech, descubrimos que los atacantes lograron elevar el volumen de ataques de pulverización de contraseñas de nuevo al nivel de intentos visto durante la campaña de LSHIY, con alrededor de 1,5 millones de intentos de inicio de sesión por día durante varios días.
Figura 1a: Intentos fallidos de inicio de sesión entre el 1 de julio de 2026 y el 15 de julio de 2026
Si bien hay algunas similitudes entre esta nueva actividad y la campaña inicial de ataque de pulverización de contraseñas (los atacantes siguen intentando inicios de sesión Azure CLI ROPC, por ejemplo), también identificamos algunas diferencias notables. En primer lugar, al momento de escribir esto, los ataques de pulverización usan IPv4, aunque esperamos que esto pueda cambiar. Los atacantes parecen estar realizando un intento de pulverización lento y gradual, rotando entre aproximadamente 12.800 IP mientras limitan el número total de intentos por IP a ~900. Dado el rango de direcciones más pequeño bajo IPv4, esto mantiene bajo el volumen por IP, en lo que probablemente fue un intento de evadir la detección.
La facilidad con la que estos atacantes logran mover su actividad entre ASN añade una complicación para los defensores que combaten sus esfuerzos maliciosos. Trasladarse a un nuevo ASN requiere poco o ningún esfuerzo por parte del atacante, y los servicios de alojamiento resistente a la interrupción que toleran este tipo de abuso son comunes. Por eso nuestras recomendaciones anteriores son tan importantes: es fundamental exigir MFA para todos los usuarios y restringir el acceso a Azure CLI para usuarios que no son administradores, porque de lo contrario, combatir el abuso de ASN de frente no es mejor que un juego del gato y el ratón.
---------------
ACTUALIZACIÓN @ 02/07 a las 2:30 p. m. hora del Este
Después de que Huntress se puso en contacto con LSHIY y reportó el comportamiento malicioso, un representante de la empresa nos dijo: "este usuario ha violado seriamente nuestros Términos de Servicio y hemos suspendido su servicio. Este usuario es un usuario de BYOIP". BYOIP es un servicio que permite al propietario asignado de un rango de direcciones IP obtener servicios de interconexión de un ISP. Una de las ofertas de LSHIY es este servicio BYOIP.
Huntress confirmó que los ataques desde este rango de IP habían terminado.
---------------
PUBLICACIÓN ORIGINAL
Resumen: Huntress está observando un ataque masivo, continuo y automatizado de pulverización de contraseñas contra la interfaz de línea de comandos (CLI) de Azure de Microsoft, originado desde un rango de direcciones IPv6 controlado por el proveedor de infraestructura de internet LSHIY LLC, AS32167. Entre el 12 y el 26 de junio, el actor de amenazas realizó más de 81 millones de intentos de inicio de sesión contra cuentas de clientes de Huntress y logró comprometer al menos 78 cuentas de Microsoft. La semana pasada, el número y la eficacia de los compromisos aumentaron drásticamente, lo que continúa una tendencia preocupante en la rápida expansión de este tipo de ataques. Cabe destacar que muchas de estas organizaciones tenían políticas de acceso condicional, pero la forma en que estaban configuradas no cubría las técnicas usadas por los actores de amenazas en esta campaña. Como se señaló en la actualización del 2 de julio mencionada arriba, los ataques cesaron después de que LSHIY terminara el servicio de los usuarios responsables del rango de direcciones IP.
Contexto
Durante las últimas semanas, hemos estado rastreando una ola de ataques de pulverización de credenciales y tokens contra entornos de Microsoft 365. Esta actividad también fue reportada por la comunidad en general, como se ve en varios hilos de Reddit.
A pesar de los millones de intentos de inicio de sesión fallidos, los compromisos confirmados de esta ola se han mantenido bajos, con un promedio de unos pocos por día. La Figura 1 a continuación muestra una captura de pantalla de un periodo específico de los compromisos vinculados a esta campaña (cabe destacar que la campaña comenzó antes de esta captura). Entre el 12 y el 21 de junio, vimos un goteo constante de compromisos, generalmente entre dos y cuatro cuentas comprometidas diariamente (con la excepción de 12 cuentas de usuario el 19 de junio).
Luego, el 22 de junio, vimos un aumento significativo en los ataques, con 30 cuentas de usuario (a las que llamamos "identidades") afectadas en 23 empresas.
En total, entre el 12 y el 26 de junio, vimos 78 cuentas de usuario comprometidas en 64 organizaciones. En esta ventana de 14 días, hemos visto más de 81 millones de intentos de inicio de sesión. La mayoría de esta actividad rastreada se originó desde AS32167, un sistema autónomo vinculado al proveedor de infraestructura/alojamiento de internet LSHIY LLC.
Figura 1: Cronología de los compromisos vinculados al ataque de pulverización de contraseñas durante las últimas dos semanas
Estos ataques forman parte de una gran ola de ataques de pulverización de credenciales en varios ASN diferentes. En los últimos seis meses, Huntress ha observado que el volumen de ataques de pulverización de credenciales aumentó más de 155 veces en toda nuestra base de clientes. Los ataques aumentaron particularmente desde fines de mayo hasta principios de junio, con un valor medio actual de aproximadamente 1.964 intentos fallidos por mes por cada inquilino protegido por Huntress. Estas cifras se inclinan fuertemente hacia ciertas empresas específicamente atacadas. La mediana actual se sitúa en 804 por mes. La focalización de estos ataques parece basarse completamente en la prevalencia de contraseñas en listas combinadas de contraseñas comprometidas, y no es específica de ningún tipo de negocio o industria.
Táctica del atacante
El actor de amenazas parecía estar usando combinaciones antiguas de usuario/contraseña, cuyas credenciales ya habían sido filtradas, pero nunca se habían rotado.
Aunque algunas de las IP en esta ola de ataques se resolvieron hacia EE. UU., otras se resolvieron hacia China. Esto se debe a inconsistencias en la telemetría de geolocalización de terceros; mientras una herramienta de terceros geolocalizó la mayoría de las IP en China, otra geolocalizó otras IP en Nebraska.
Por eso, algunos de los incidentes se detectaron porque los inicios de sesión provenían de IP anómalas. Como muestra la Figura 2, en una organización afectada el 25 de junio, el SOC vio varios eventos vinculados a esta campaña que se originaron en China.
Figura 2: Inicios de sesión sospechosos provenientes de China en una organización del sector educativo afectada por esta campaña
Atacantes validando credenciales mediante el flujo ROPC
En la campaña, los actores de amenazas reutilizaron credenciales validadas mediante el flujo OAuth ROPC (Resource Owner Password Credentials). ROPC es un tipo de concesión de OAuth 2.0 que ha quedado obsoleto en OAuth 2.1. Este flujo de autenticación toma un usuario/contraseña en el endpoint /token de un inquilino y genera un nuevo token delegado de usuario una vez que se proporcionan las credenciales correctas.
Esto importa porque muchas de las empresas comprometidas habían implementado la autenticación multifactor (MFA) mediante una Política de acceso condicional (CAP), pero la MFA no estaba configurada para cubrir este flujo específico que usaron los atacantes.
Se considera que ROPC es problemático por varias razones, pero una de ellas es que no ofrece compatibilidad con flujos de autenticación modernos como MFA o SSO. Esto significa que, como vimos en esta campaña, ROPC envía la contraseña directamente al endpoint /token sin ninguna solicitud interactiva de MFA.
Brechas en la configuración de MFA
Como los actores de amenazas estaban usando este vector de ataque, pudieron afectar a empresas que habían implementado MFA, pero que no la configuraron correctamente para cubrir los inicios de sesión de Azure CLI mediante ROPC.
Al analizar el pico de ataques del 22 de junio que afectó a 23 empresas, descubrimos que 15 de esas compañías tenían MFA implementada y aplicada mediante CAP. Sin embargo, aunque estas organizaciones pensaban que estaban protegidas por MFA, la MFA no se activó por varias razones durante esta campaña (como se ve en la Figura 3):
En algunos casos, la MFA se aplicaba para aplicaciones específicas en lugar de "Todas las aplicaciones en la nube". Por ejemplo, algunas organizaciones aplicaron MFA para los portales de administración de Microsoft, lo que no cubría los inicios de sesión de Azure CLI usados por el actor de amenazas.
Otras organizaciones habilitaron la MFA solo para grupos de usuarios específicos (como Solo administradores). Los usuarios comprometidos no estaban dentro del alcance de esos grupos de usuarios específicos.
Varias empresas tenían la MFA configurada para que solo se exigiera desde ubicaciones no confiables, algo que el atacante pudo evadir gracias a que su dirección IP estaba mal etiquetada como de EE. UU.
En dos casos, la MFA se dejó solo en modo de informe, es decir, estaba implementada pero nunca se aplicaba.
Figura 3: Un desglose de las brechas de configuración de MFA en esta campaña
Vale la pena notar que ocho empresas afectadas por la campaña no tenían ninguna política de MFA. Si bien los actores de amenazas en esta campaña lograron entrar a pesar de tener MFA configurada, la conclusión no debería ser que la MFA no funciona en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén correctamente configuradas para abordar el flujo de autorización usado en estos incidentes.
LSHIY: el rango IPv6 del ataque
Los ataques provinieron del rango de direcciones IPv6 2a0a:d683::/32, que no tiene un valor correspondiente en el sistema de direccionamiento IPv4. El rango pertenece a LSHIY LLC, un proveedor de infraestructura de internet que tiene direcciones comerciales registradas en dos edificios de fábricas diferentes en Hong Kong y Wuhan, China, y una en las TKO Suites, en 42 Broadway, piso 12, Nueva York, NY 10004. TKO Suites es un espacio de oficinas compartido para alquiler sin un negocio particular, así que quien esté en esa oficina mantiene en privado la verdadera titularidad de esa empresa.
LSHIY opera dos ASN distintos: además de AS32167 (registrado el 14 de junio de 2021), también opera AS955 (registrado el 22 de junio de 2022). Terceros informan que los rangos de IPv6 asociados con ambos sistemas autónomos se originan en China. Tras investigar más a fondo este rango de IPv6 de interés, Huntress encontró direcciones IPv6 específicas dentro de ese rango que eran recientes, incluida una de un administrador creado el 11 de junio de 2026.
Huntress ha reportado la actividad a la empresa a través de su mecanismo de reporte de abuso, pero no hemos recibido respuesta al momento de publicar esta entrada. Actualizaremos la publicación cuando recibamos una respuesta de un representante de la empresa.
Guía de mitigación
Este ataque revela fallas en las CAP que no se han configurado adecuadamente. Las CAP evalúan señales de inicio de sesión como usuario, ubicación, dispositivos y tipo de aplicación, para decidir si se requiere MFA antes de emitir un token. Sin embargo, como podemos ver en esta campaña, todavía existen posibles debilidades en la forma en que se implementan las CAP que pueden permitir que los actores de amenazas se cuelen. Un error evidente aquí es que los protocolos heredados como ROPC pueden eludir por completo algunas CAP mal configuradas, ya que no pasan por el endpoint de autorización donde se aplican las políticas. Sin embargo, algunos de los otros problemas descritos anteriormente, como ubicaciones confiables o grupos de usuarios mal configurados, también pueden generar brechas.
Aquí hay otras recomendaciones que pueden ayudar a proteger contra este tipo de ataque:
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, de forma incondicional. Una configuración de Acceso condicional fuerte (
userStrongAuthClientAuthNRequired) aplica autenticación fuerte a nivel de autenticación de cliente y bloquea los flujos ROPC, lo que hace fallar este tipo de ataqueRestringir la aplicación de Azure CLI para usuarios que no son administradores
No activar una respuesta basada en el volumen de ataques de rociado, ya que esto apunta a los inquilinos más rociados, pero menos comprometidos; en su lugar, priorizar según la validez de las credenciales
