Ajusta la boquilla: un repaso de Tradecraft Tuesday sobre el ataque de pulverización de contraseñas

Las botellas rociadoras son famosas por lo delicadas que son. ¿Cuántas veces has comprado un producto de limpieza solo para descubrir que, tras unos pocos usos, la boquilla se atasca y queda inutilizable? 

Ante un ataque de pulverización de contraseñas, nuestro trabajo como defensores exige un nivel de precisión similar: bloquear el punto de entrada para que ni una sola gota (es decir, un inicio de sesión malicioso) logre pasar.

Aunque los ataques de fuerza bruta no son nada nuevo, está surgiendo una nueva variante de la pulverización de contraseñas.

Huntress observó un asombroso aumento del 155x en los ataques de pulverización de credenciales durante la primera mitad de 2026.

Gran parte de este aumento se debe a una sola campaña contra el CLI de Azure de Microsoft, originada en un rango de IPv6 controlado por el proveedor de hosting de internet LSHIY LLC. Aunque la campaña comenzó meses antes, a mediados de junio Huntress observó más de 81 millones de intentos de inicio de sesión relacionados y 78 cuentas comprometidas en tan solo un período de dos semanas.

Figura 1: El pico de pulverización de contraseñas del 22 de junio, vinculado a la campaña LSHIY. Huntress generalmente observó más tráfico entre semana. 

Todo esto y más se trató en la transmisión de Tradecraft Tuesday de julio. Los panelistas Andrew "Spike" Brandt (Principal Threat Intelligence Incident Commander), Rich Mozeleski (Staff Product Manager) y Lindsey O'Donnell-Welch (Principal Technical Community Engagement Writer) repasaron su reciente blog en el que analizan la campaña LSIHY (decidimos que rima con "fishy") y ofrecieron medidas de mitigación para la prevención y la remediación. 

Cómo un flujo de OAuth en desuso lleva la pulverización de contraseñas a otro nivel 

Un ataque típico de pulverización de contraseñas consta de los siguientes pasos:

  1. Reconocimiento: El atacante recopila nombres de usuario válidos a través de LinkedIn, sitios web de empresas, filtraciones de datos y phishing para crear una lista de objetivos.

  2. Creación de la lista de contraseñas: El atacante arma una lista corta de contraseñas filtradas, contraseñas comunes como "Password123", variantes del nombre de la empresa o términos de temporada.

  3. Ataque de pulverización de contraseñas contra las cuentas: El atacante prueba una contraseña contra cada cuenta de la lista de objetivos. Respetando los umbrales de bloqueo, el atacante espera antes de pasar a la siguiente contraseña, con un enfoque "lento y constante". 

  4. Obtención de acceso inicial: Si logra acceder, el atacante avanza hacia el movimiento lateral, el Compromiso del correo electrónico empresarial (BEC), la exfiltración de datos o un mayor robo de credenciales, a menudo sin ser detectado durante semanas. 

Los atacantes detrás de la campaña LSHIY llevaron las cosas un paso más allá, gracias a algo llamado Resource Owner Password Credentials (ROPC).

Obsoleto en OAuth 2.1, el permiso ROPC fue diseñado para ayudar a la gente a migrar al uso de OAuth allá por 2012. Si se proporcionan las credenciales correctas en el endpoint /token de un inquilino, este flujo de autenticación genera un nuevo token delegado por el usuario, lo que permite al atacante evadir por completo la autenticación multifactor (MFA) y las políticas de acceso condicional (CAP). 

Como lo expresó Spike: 

"Aunque lo llamamos método de autorización, técnicamente es un método de suplantación". 

Cabe destacar que Huntress no observó ninguna actividad de compromiso tras los inicios de sesión exitosos vinculados a la campaña LSHIY. Rich plantea la hipótesis de que, tras hacerse con una lista de combinaciones de contraseñas, el actor de amenazas detrás de estos intentos podría estar validando credenciales para venderlas en la Dark Web.  

Tras ser contactado por Huntress y otros, LSHIY confirmó a principios de julio que los ataques provenientes de ese rango de IP habían sido detenidos, declarando que el atacante había estado aprovechando su oferta de traer tu propia IP (BYOIP). 

Cuando la fiesta es BYOIP

BYOIP es una oferta legítima que da a los clientes de los ISP servicios de peering para los rangos de direcciones IP que poseen. En lugar de depender de direcciones de AWS/Azure, los actores de amenazas pueden "traer" su propio bloque y rotar a nuevas IP después de cada intento de inicio de sesión para evadir el Smart Lockout de Microsoft u otros métodos de detección. 

Los ataques de la campaña LSHIY se originaron desde el rango IPv6 2a0a:d683::/32. Como señaló Rich, la llegada de IPv6 en 2017 aumentó drásticamente el espacio disponible de direcciones IP, creando una especie de "viejo oeste" de territorio inexplorado donde tanto atacantes como defensores pueden perderse. 

Varios asistentes de Tradecraft Tuesday preguntaron sobre la geolocalización de direcciones IP usadas en ataques de pulverización de contraseñas, a lo que Spike respondió con ironía: "La geolocalización en IPv6 es un desastre en este momento".

Desde la eliminación de LSHIY, el actor de amenazas parece haberse mudado a un bloque de IP alojado por el ISP FranTech (AS53667), realizando ataques de pulverización de contraseñas desde dos rangos de IPv6 (2605:6400::/32, 2605:6404::/32), además de rangos de IPv4 a través de nodos de salida de Tor. Cabe destacar que el volumen de intentos ha disminuido significativamente. 

Varios otros miembros de la comunidad de infosec y MSP comentaron durante el evento que habían visto tráfico similar proveniente del ISP alemán 3xK Tech. Estos servicios de peering intercambiables crean un escenario familiar de "golpea al topo" para la caza de amenazas por parte de los defensores. 

Usa MFA, no pulverices contraseñas

La campaña LSHIY no parece estar dirigida a ninguna industria específica, sino que aprovecha de forma oportunista a las organizaciones con malos hábitos de contraseñas o con MFA mal configurado. De 23 empresas afectadas analizadas por Huntress, todas menos ocho tenían MFA implementado. Un tercio de las 15 restantes tenía su MFA delimitado a usuarios específicos, lo que significa que ciertos grupos (como propietarios vinculados a ROPC) quedaban excluidos. 

Figura 2: Desglose de cómo tenían configurado (o no) el MFA las organizaciones afectadas por la campaña LSHIY

Esto no significa que el MFA esté fallando; significa que las políticas de acceso condicional deben delimitarse para aplicarse correctamente. Decenas de comentaristas en el chat de Tradecraft Tuesday se quejaron de lo difícil que es ajustar las políticas de acceso condicional sin bloquear con frecuencia a usuarios legítimos. 

Lindsey lo dejó claro: 

"Las políticas de acceso condicional son confusas. Como pueden ver, incluso tuvimos empresas con MFA configurado, con una política explícita diseñada para bloquear este vector tan específico, que de todos modos fueron afectadas."

Lee nuestro blog reciente sobre otro ataque de OAuth para conocer más variantes de configuraciones incorrectas de CAP. 

No te dejes mojar

No somos los únicos que vemos esto: más de tres cuartas partes de los asistentes a Tradecraft Tuesday encuestados notaron un aumento en los intentos de ataque de pulverización de contraseñas en sus entornos, y varias personas señalaron específicamente a Azure CLI. 

Huntress recomienda las siguientes estrategias de mitigación para proteger a tus usuarios de los ataques de pulverización de contraseñas: 

  • Aplica buenos hábitos de contraseñas y considera opciones sin contraseña. 

  • Deshabilita ROPC (o las aplicaciones que dependen de él) en tu sistema.

  • Restringe la aplicación de Azure CLI para usuarios sin privilegios de administrador.  

  • No actives la respuesta en función del volumen de pulverización (apuntando a los inquilinos más atacados, pero menos comprometidos); da prioridad según la validez de las credenciales.

  • Exige MFA (o bloquea el acceso) para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicación cliente, sin condiciones.

  • Usa una configuración sólida de acceso condicional, como userStrongAuthClientAuthNRequired, para exigir autenticación fuerte en el cliente.

Rick lo expresó muy bien:

"Un acceso condicional bien configurado y administrado es un superpoder." 

¿Te gustó lo que acabas de leer? Únete a nosotros cada mes en Tradecraft Tuesday, nuestro livestream donde exponemos técnicas de hackers y hablamos de temas técnicos con demostraciones en vivo. ¡Asegura tu lugar ahora!

También te podría interesar

Más información sobre Cerrando la brecha: Managed ITDR ahora admite la deshabilitación de identidades para identidades sincronizadas con Active Directory
Cerrando la brecha: Managed ITDR ahora admite la deshabilitación de identidades para identidades sincronizadas con Active Directory
Blog

Una de las funciones más solicitadas de Huntress Managed ITDR ya está disponible: la deshabilitación de identidades para identidades sincronizadas con Active Directory. Esto es lo que significa para tu flujo de contención y respuesta.

Más información sobre CMMC: la oportunidad ($$) y el desafío para los MSP
CMMC: la oportunidad ($$) y el desafío para los MSP
Blog

CMMC no es solo otra casilla de cumplimiento: es un cambio de mercado que dividirá a los MSP entre ganadores y perdedores. Si el mandato de EMR te enseñó algo, es que quienes se mueven primero ganan.

Más información sobre Resiliencia operativa: cómo convertir tu plan de respuesta a incidentes en memoria muscular
Resiliencia operativa: cómo convertir tu plan de respuesta a incidentes en memoria muscular
Blog

Un plan de respuesta a incidentes solo funciona si se pone a prueba. Conoce los 5 pilares de la resiliencia operativa y cómo convertir tu plan en memoria muscular antes de que ocurra un ataque.