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.
Según 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.
«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).
«En la mayoría de los casos, existen alternativas más seguras que se
recomiendan. Este flujo requiere un alto grado de confianza en la aplicación
y conlleva riesgos que no están presentes en otros flujos. Solo debe usarse
cuando no sea viable usar flujos más seguros», afirma el gigante tecnológico.
Se dice que 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 de 2026, 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 (también conocidas como identidades). 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.
«Estos ataques forman parte de una oleada generalizada de ataques de fuerza
bruta contra credenciales en varios sistemas autónomos (ASN)», declaró Huntress, añadiendo que 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.
«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, como vimos en esta campaña, ROPC envía la
contraseña directamente al punto final /token sin solicitar la autenticación
multifactor de forma interactiva», explica Huntress.
Esto incluía escenarios en los que no se activaba la autenticación multifactor
(MFA):
-
Aplicar la MFA solo para aplicaciones específicas, en lugar de para «Todas
las aplicaciones en la nube», lo que impedía cubrir los inicios de sesión de
la CLI de Azure utilizados por los ciberdelincuentes. -
Aplicar la MFA solo para grupos de usuarios específicos, como los
administradores. -
Aplicar la MFA solo cuando las solicitudes se originaban en ubicaciones no
confiables.
«Cabe destacar que ocho empresas afectadas por la campaña no contaban con
ninguna política de autenticación multifactor (MFA): Si bien los
ciberdelincuentes lograron acceder a pesar de tener MFA configurada, la
conclusión no debe ser que MFA no funcione 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 este tipo de 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, 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 (ASN)
operados por la empresa, se originan en China.
Fuente:
THN