Ataques de rociado de contraseñas aumentan 155 veces al explotar las brechas en la MFA
Huntress ha detectado un incremento de 155 veces en los ataques de rociado de contraseñas en la primera mitad de 2026. La fuerza bruta tradicional es conocida, pero la técnica que impulsa este aumento es novedosa: una campaña dirigida contra la CLI de Azure de Microsoft, la herramienta de línea de comandos que los administradores usan para gestionar recursos de Azure y Entra. El tráfico se originó desde un rango IPv6 controlado por el proveedor de alojamiento de internet LSHIY LLC. La campaña comenzó meses antes, pero solo en junio se observaron más de 81 millones de intentos de inicio de sesión y 78 compromisos de cuentas en un periodo de dos semanas.
El flujo de autenticación olvidado
Un ataque típico de rociado de contraseñas sigue un patrón habitual: reconocimiento para recopilar nombres de usuario válidos, construcción de una lista de contraseñas comunes o filtradas, rociado de una contraseña contra todas las cuentas de la lista y espera para evitar bloqueos, y la obtención de acceso para moverse lateralmente, realizar compromiso de correo electrónico empresarial (BEC), exfiltrar datos o robar credenciales adicionales. La campaña contra LSHIY combinó el rociado a gran escala con la reutilización de nombres de usuario y contraseñas válidos provenientes de filtraciones anteriores que nunca se rotaron. Además, el atacante abusó de ROPC (Resource Owner Password Credentials), un flujo OAuth heredado y obsoleto en OAuth 2.1, que envía las credenciales directamente al punto de envío /token sin solicitar MFA ni SSO. Esto permitió que una contraseña reutilizada activa se convirtiera en una sesión activa. El problema se agravó porque muchas de las empresas comprometidas tenían implementada la MFA mediante una política de acceso condicional, pero no cubría este flujo específico. Andrew "Spike" Brandt, comandante principal de inteligencia de amenazas en Huntress, señaló: "Aunque lo llamamos un método de autorización, técnicamente es un método de suplantación de identidad".
"Aunque lo llamamos un método de autorización, técnicamente es un método de suplantación de identidad".
Huntress no observó actividad posterior al compromiso en los inicios de sesión exitosos de la campaña. Rich Mozeleski, gerente de producto en Huntress, sospecha que el atacante validaba credenciales para revenderlas en la dark web. LSHIY terminó los ataques desde el rango original y confirmó que el atacante usaba su oferta BYOIP (bring-your-own-IP).
Es una fiesta BYOIP de IPv6
BYOIP es un servicio legítimo que permite a los clientes de un ISP enrutar tráfico a través del proveedor usando rangos de IP propios. Esta flexibilidad permite a los atacantes cambiar de rangos y proveedores, complicando el bloqueo y la detección. Los ataques de LSHIY se originaron desde el rango IPv6 2a0a:d683::/32, que ofrece una enorme cantidad de direcciones, dificultando el bloqueo por IP. Tras el cierre por parte de LSHIY, los intentos se trasladaron a rangos IPv6 de FranTech y, posteriormente, a IPv4 de 3xK Tech. Esta facilidad para cambiar de proveedor convierte el bloqueo de infraestructura en un juego del gato y el ratón para los defensores.
El alcance es el punto débil
La campaña no se dirige a una industria específica, sino que aprovecha organizaciones con controles de contraseña o políticas de MFA deficientes. Huntress analizó 23 empresas afectadas: ocho no tenían MFA; en las otras 15, la MFA no se aplicaba a los intentos del atacante porque las políticas se limitaban a ciertas aplicaciones o grupos de usuarios, dependían de ubicaciones de confianza o estaban en modo solo informe. Esto demuestra que incluso con MFA, es crucial revisar el alcance y la aplicación de las políticas de acceso condicional.
Cerrar el grifo
Las estrategias de mitigación para cerrar las brechas explotadas por estos ataques incluyen: reforzar la higiene de contraseñas y considerar opciones sin contraseña, deshabilitar ROPC y las aplicaciones que lo usan, restringir la CLI de Azure a administradores, priorizar la respuesta basada en la validez de las credenciales y no en el volumen de rociado, requerir MFA para todos los usuarios, aplicaciones y tipos de cliente sin excepciones, y usar configuraciones fuertes de acceso condicional como userStrongAuthClientAuthNRequired para bloquear ROPC.
"Un acceso condicional configurado y gestionado adecuadamente es un superpoder" — Rich Mozeleski, Huntress.
Los atacantes pueden cambiar de proveedor y de rangos de IP más rápido de lo que los defensores pueden bloquearlos. La solución es asegurarse de que una contraseña por sí sola no abra la puerta: mantener contraseñas sólidas, limitar el acceso a la CLI de Azure y aplicar el acceso condicional a todos los usuarios, aplicaciones y tipos de cliente.
Deja una respuesta