Los investigadores de ciberseguridad han advertido sobre un «ataque de pulverización de contraseñas automatizado, continuo y a gran escala» dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, con docenas de cuentas comprometidas en el proceso.
Según Huntress, esta actividad 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, los atacantes detrás del ataque realizaron más de 81 millones de intentos de inicio de sesión y comprometieron con éxito al menos 78 cuentas de Microsoft en 64 organizaciones», dijo la compañía en un comunicado. «Los objetivos de estos ataques parecen basarse completamente en la prevalencia de contraseñas de listas combinadas de contraseñas comprometidas y no son una industria o una industria específica».
Los ataques de pulverización de contraseñas se destacan no solo por su escala, sino también por el hecho de que muchas de las organizaciones comprometidas tenían habilitadas políticas de acceso condicional. Específicamente, se descubrió que esta campaña aprovechaba un flujo de 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 tradicional de OAuth 2.0 en el que un usuario proporciona un nombre de usuario y una contraseña directamente a una aplicación cliente, y la aplicación cliente envía estas credenciales a un servidor de autorización a cambio de un token de acceso. Esto está obsoleto en OAuth 2.1.
En su documentación, Microsoft aconseja a los clientes que no utilicen ROPC, diciendo que no es compatible con la autenticación multifactor (MFA).
«En la mayoría de los escenarios, hay alternativas más seguras disponibles y recomendadas», dijo el gigante tecnológico. «Este flujo requiere un grado muy alto de confianza en su aplicación y conlleva riesgos que otros flujos no tienen. Este flujo sólo debe usarse cuando no se puede realizar un flujo más seguro».
El ataque de pulverización de credenciales y tokens supuestamente comprometió un promedio de dos a cuatro cuentas cada día del 12 al 21 de junio de 2026, con la excepción del 19 de junio, cuando 12 cuentas de usuario (también conocidas como identidades) se vieron comprometidas con varios inicios de sesión exitosos por día. Esta tendencia constante cambió el 22 de junio, cuando 30 identidades en 23 empresas se vieron afectadas.
Un total de 78 cuentas de usuario en 64 organizaciones se vieron comprometidas como parte de esta campaña. La mayor parte de la actividad de pulverización de contraseñas se originó en LSHIY LLC. Algunas de las direcciones IP se resuelven en Estados Unidos, mientras que otras se resuelven en China.
«Estos ataques son parte de una ola más grande de ataques de pulverización de credenciales en varios ASN diferentes», dijo Huntress, y agregó que la compañía ha visto el volumen de ataques de pulverización de credenciales aumentar más de 155 veces en su base de clientes. «Los picos de ataques se produjeron especialmente a finales de mayo y principios de junio, siendo el promedio actual de aproximadamente 1.964 ataques fallidos por mes por inquilino protegido por Huntress».
Esta actividad específicamente parece estar utilizando como arma antiguas combinaciones de nombres de usuario y contraseñas que previamente estaban comprometidas pero no rotadas. El uso de vectores ROPC significa que los atacantes pueden apuntar a empresas que han implementado MFA, pero no se aplicaron ni configuraron teniendo en mente el inicio de sesión ROPC de la CLI de Azure.
Esto también incluye escenarios en los que no se activó la AMF.
Debido a que aplica MFA solo para aplicaciones específicas, no para «todas las aplicaciones en la nube», no puede cubrir los inicios de sesión de la CLI de Azure utilizados por los actores de amenazas. Aplique MFA solo para grupos de usuarios específicos, como administradores. Aplique MFA solo cuando las solicitudes provengan de ubicaciones que no sean de confianza.
«Es notable que las ocho empresas afectadas por la campaña no tenían ninguna política de AMF», dijo Huntress. «Si bien los atacantes en esta campaña pudieron ingresar a pesar de que MFA estaba implementado, el punto no es que MFA no funcione en absoluto, sino que las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas adecuadamente para abordar los flujos de autorización utilizados en estos incidentes».
Para combatir este ataque, se recomienda a las organizaciones que exijan MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, restrinjan las aplicaciones de la CLI de Azure a usuarios que no sean administradores y prioricen las respuestas según la validez de las credenciales.
«Este ataque expuso grietas en un CAP mal configurado», concluyeron los investigadores de Huntress. «Todavía existen debilidades potenciales en la forma en que se implementan los CAP que permiten que los actores de amenazas se escapen. Un error flagrante aquí es que los protocolos heredados como ROPC no pasan por los puntos finales de autorización donde se aplican las políticas, por lo que pueden eludir por completo algunos CAP configurados incorrectamente».
Source link
