Investigadores de ciberseguridad de Huntress han alertado sobre un ataque masivo, continuo y automatizado de fuerza bruta contra contraseñas dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, que ha comprometido decenas de cuentas.
De acuerdo con Huntress, la 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, el atacante realizó más de 81 millones de intentos de inicio de sesión y logró comprometer al menos 78 cuentas de Microsoft en 64 organizaciones. Según Huntress, la estrategia de estos ataques parece basarse exclusivamente en la frecuencia de las contraseñas en las listas de combinaciones de contraseñas comprometidas, sin estar específica para ningún tipo de empresa o sector.
Lo que hace que este ataque de fuerza bruta sea relevante no es solo su magnitud, sino también el hecho de que muchas de las organizaciones afectadas tenían habilitadas las políticas de acceso condicional. En concreto, se ha descubierto que la campaña aprovecha un flujo de OAuth obsoleto llamado Credenciales de Contraseña del Propietario del Recurso (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. Se dejó de usar en OAuth 2.1.
En su documentación, Microsoft recomienda a los clientes no usar el flujo ROPC, argumentando que es incompatible con la autenticación multifactor (MFA). El gigante tecnológico afirma que en la mayoría de los casos existen alternativas más seguras que se recomiendan y que este flujo requiere un alto grado de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos.
Los ataques de fuerza bruta contra 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, con un promedio de dos a cuatro cuentas comprometidas diariamente, con la excepción del 19 de junio, cuando se vieron comprometidas 12 cuentas de usuario. El ritmo constante cambió el 22 de junio, cuando 30 identidades de 23 empresas se vieron afectadas.
En total, 78 cuentas de usuario se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de los ataques de fuerza bruta contra contraseñas provino de LSHIY LLC. Algunas de las direcciones IP corresponden a Estados Unidos, mientras que otras corresponden a China.
Huntress declaró que estos ataques forman parte de una oleada generalizada de ataques de fuerza bruta contra credenciales en varios sistemas autónomos (ASN) y ha observado un aumento de más de 155 veces en el volumen de ataques de este tipo entre sus clientes. Los ataques surgieron especialmente entre finales de mayo y principios de junio, con un promedio actual de aproximadamente 1964 ataques fallidos al mes por cada cliente protegido por Huntress.
La actividad parece centrarse específicamente en el uso de combinaciones antiguas de nombre de usuario y contraseña que ya habían sido vulneradas, pero que nunca se habían actualizado. El uso del vector ROPC permitió a los atacantes dirigirse a empresas que habían implementado la autenticación multifactor (MFA), pero que no la tenían configurada para gestionar los inicios de sesión ROPC de la CLI de Azure.
Huntress explica que ROPC se considera 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 ROPC envía la contraseña directamente al punto final /token sin solicitar la autenticación multifactor de forma interactiva.
Entre los escenarios en los que no se activaba la autenticación multifactor se encuentran: aplicar la MFA solo para aplicaciones específicas en lugar de para todas las aplicaciones en la nube; aplicar la MFA solo para grupos de usuarios específicos, como los administradores; y aplicar la MFA solo cuando las solicitudes se originaban en ubicaciones no confiables.
Huntress señala que ocho empresas afectadas por la campaña no contaban con ninguna política de autenticación multifactor (MFA). Aunque los ciberdelincuentes lograron acceder a pesar de tener MFA configurada, la conclusión no debe ser que MFA no funcione; 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.
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, que restrinjan el acceso a la aplicación Azure CLI para usuarios que no sean administradores y que prioricen la respuesta según la validez de las credenciales.
Este ataque revela vulnerabilidades en los CAP que no se han configurado adecuadamente. Todavía existen posibles debilidades en la implementación de los CAP que pueden permitir que los ciberdelincuentes se filtren. Un error evidente 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.
El rango de direcciones IPv6 desde el que se originaron los ataques pertenece a LSHIY, un proveedor de infraestructura de internet registrado en Hong Kong, Wuhan (China) y Nueva York. También existen otros informes que indican que los rangos de IPv6 asociados con AS32167 y AS955, dos sistemas autónomos operados por la empresa, se originan en China.
Con Información de blog.segu-info.com.ar
