Investigadores advirtieron sobre un masivo ataque de password spray contra Azure CLI que comprometió 78 cuentas en 64 organizaciones. Los atacantes utilizaron el flujo obsoleto ROPC para evadir las políticas de acceso condicional y la autenticación de doble factor (MFA). Se recomienda a las empresas configurar correctamente sus políticas de MFA para todas las aplicaciones y usuarios para cerrar estas vulnerabilidades.

Investigadores de ciberseguridad han advertido sobre un "ataque masivo, continuo y automatizado de password spray" dirigido a la interfaz de línea de comandos (CLI) de Microsoft Azure, comprometiendo decenas de cuentas en el proceso.

La actividad, según Huntress, se origina desde 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", afirmó la empresa en un comunicado. "El objetivo de estos ataques parece basarse enteramente en la prevalencia de contraseñas en listas de combinaciones comprometidas, y no es específico de un tipo de negocio o industria".

Lo que hace que este ataque de password spray sea notable 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 ha descubierto que la campaña aprovecha un flujo de OAuth obsoleto llamado Resource Owner Password Credentials (ROPC) para evadir las protecciones de la Política de Acceso Condicional (CAP).

ROPC es un tipo de concesión de OAuth 2.0 heredado donde 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 canjearlas por un token de acceso. Fue descontinuado en OAuth 2.1. En su documentación, Microsoft recomienda a los clientes no utilizar el ROPC, argumentando que es incompatible con la autenticación de múltiples factores (MFA).

"En la mayoría de los escenarios, existen alternativas más seguras y recomendadas", afirma el gigante tecnológico (enlace). "Este flujo requiere un grado muy alto de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Solo debes usar este flujo cuando los flujos más seguros no sean viables".

Se afirma que los ataques de spray de credenciales y tokens resultaron en 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 se comprometieron 12 cuentas de usuario (identidades). La cadencia constante cambió el 22 de junio, con 30 identidades afectadas en 23 empresas.

En total, 78 cuentas de usuario fueron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de la actividad de password spraying emanó de LSHIY LLC. Algunas de las direcciones IP se resuelven en EE. UU., mientras que otras pocas se resuelven en China.

"Estos ataques son parte de una gran ola de ataques de spray de credenciales a través de varios ASN diferentes", dijo Huntress, añadiendo que ha sido testigo de que el volumen de estos ataques aumentara más de 155 veces en su base de clientes. "Los ataques aumentaron particularmente desde finales de mayo hasta principios de junio, con un valor medio actual de unos 1.964 ataques fallidos por mes por cada inquilino protegido por Huntress".

La actividad parece convertir específicamente en armas antiguas combinaciones de usuario/contraseña que habían sido filtradas previamente pero que nunca habían sido rotadas. El uso del vector ROPC significó que los atacantes pudieron dirigirse a empresas que habían implementado MFA, pero que este no estaba impuesto o configurado para tener en cuenta los inicios de sesión ROPC de Azure CLI.

Esto incluyó escenarios donde el MFA no se activó:
* Imponer MFA solo para aplicaciones específicas, en lugar de "Todas las aplicaciones en la nube", fallando así en cubrir los inicios de sesión de Azure CLI utilizados por los actores de amenazas.
* Imponer MFA solo para grupos de usuarios específicos, como los administradores.
* Imponer MFA solo cuando las solicitudes se originan desde ubicaciones no confiables.

"Cabe 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 entrar a pesar de tener configurado el MFA, la conclusión no debe ser que el MFA no funciona en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas correctamente para abordar el flujo de autorización utilizado en estos incidentes".

Para contrarrestar esta línea de ataque, se aconseja 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 Azure CLI 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 han sido configurados adecuadamente", concluyeron los investigadores de Huntress. "Todavía existen debilidades potenciales en cómo se despliegan los CAP que pueden permitir que los actores de amenazas se filtren. Un error garrafal aquí es que los protocolos heredados como ROPC pueden evadir completamente algunos CAP mal configurados ya que no pasan por el endpoint de autorización donde se aplican las políticas".

Fuente:
THN