Los investigadores de ciberseguridad han advertido sobre un “ataque masivo, continuo y automatizado de pulverización de contraseñas” dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, comprometiendo docenas de cuentas en el proceso.
La actividad, según Huntress, se origina en un rango de direcciones IPv6 (2a0a:d683::/32) controlado por el proveedor de infraestructura de Internet LSHIY LLC (AS32167).
“Entre el 12 y el 26 de junio, el actor de amenazas detrás de esto realizó más de 81 millones de intentos de inicio de sesión y comprometió con éxito al menos 78 cuentas de Microsoft en 64 organizaciones”, dijo la compañía en un comunicado. “El objetivo de estos ataques parece basarse enteramente en la prevalencia de contraseñas en listas combinadas de contraseñas comprometidas, y no es específico del tipo de negocio o industria”.
Lo que hace que el ataque de pulverización de contraseñas sea digno de mención no es solo la escala, sino también el hecho de que muchas de las organizaciones comprometidas tenían habilitadas políticas de acceso condicional. Específicamente, se descubrió que la campaña aprovecha un flujo OAuth obsoleto llamado Credenciales de contraseña del propietario de recursos (ROPC) para eludir las protecciones de la Política de acceso condicional (CAP).
ROPC es un tipo de concesión de OAuth 2.0 heredado en el que un usuario proporciona directamente su nombre de usuario y contraseña a una aplicación cliente, que luego envía estas credenciales a un servidor de autorización para intercambiarlas por un token de acceso. Quedó obsoleto en OAuth 2.1.
En su documentación, Microsoft recomienda a los clientes que no utilicen ROPC, argumentando que es incompatible con la autenticación multifactor (MFA).
“En la mayoría de los escenarios, hay alternativas más seguras disponibles y recomendadas”, afirma el gigante tecnológico. “Este flujo requiere un grado muy alto de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Sólo debe utilizar este flujo cuando no sean viables flujos más seguros”.
Se dice que los ataques de pulverización de credenciales y tokens dieron como resultado un puñado de inicios de sesión exitosos por día entre el 12 y el 21 de junio de 2026, con un promedio de dos a cuatro cuentas comprometidas diariamente, con la excepción del 19 de junio, cuando 12 cuentas de usuario (también conocidas como identidades) fueron comprometidas. La cadencia constante cambió el 22 de junio, con 30 identidades en 23 empresas afectadas.
En total, 78 cuentas de usuarios se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de la actividad de pulverización de contraseñas provino de LSHIY LLC. Algunas de las direcciones IP se resuelven en EE. UU., mientras que otras se resuelven en China.
“Estos ataques son parte de una gran ola de ataques de pulverización de credenciales en algunos ASN diferentes”, dijo Huntress, y agregó que ha sido testigo de un aumento de más de 155 veces en el volumen de ataques de pulverización de credenciales en toda su base de clientes. “Los ataques aumentaron en particular desde finales de mayo hasta principios de junio, con un valor medio actual de alrededor de 1.964 ataques fallidos por mes por inquilino protegido por Huntress”.
La actividad parece utilizar específicamente como arma antiguas combinaciones de nombre de usuario y contraseña que fueron violadas previamente pero que nunca se rotaron. El uso del vector ROPC significó que los atacantes pudieron apuntar a empresas que habían implementado MFA, pero no se aplicó ni se configuró para tener en cuenta los inicios de sesión ROPC de la CLI de Azure.
Esto incluyó escenarios en los que no se activó MFA:
- Aplicar MFA solo para aplicaciones específicas, a diferencia de “Todas las aplicaciones en la nube”, por lo que no se cubren los inicios de sesión de la CLI de Azure utilizados por los actores de amenazas.
- Aplicar MFA solo para grupos de usuarios específicos, como administradores
- Aplicar MFA solo cuando las solicitudes se originan en ubicaciones que no son de confianza
“Vale la pena señalar que ocho empresas afectadas por la campaña no tenían ninguna política de MFA”, dijo Huntress. “Si bien los actores de amenazas en esta campaña pudieron ingresar a pesar de que se configuró MFA, la conclusión no debería ser que MFA no funcione en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas adecuadamente para abordar el flujo de autorización utilizado en estos incidentes”.
Para contrarrestar esta línea de ataque, se recomienda a las organizaciones exigir MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, restringir la aplicación CLI de Azure para usuarios que no sean administradores y priorizar la respuesta según la validez de las credenciales.
“Este ataque revela grietas en los CAP que no se han configurado adecuadamente”, concluyeron los investigadores de Huntress. “Todavía existen debilidades potenciales en la forma en que se implementan los CAP que pueden permitir que los actores de amenazas se escapen. Un error flagrante aquí es que los protocolos heredados como ROPC pueden eludir por completo algunos CAP mal configurados, ya que no pasan por el punto final de autorización donde se aplican las políticas”.