El password spraying se disparó 155 veces — porque la MFA nunca se activó

En la primera mitad de 2026, Huntress registró un aumento de 155 veces en ataques de password spraying entre sus clientes. No fue un regreso a la fuerza bruta ruidosa. Fue la reutilización silenciosa de contraseñas antiguas contra un inicio de sesión que nunca pedía un segundo factor.

Gran parte de ese tráfico apuntó a Azure CLI de Microsoft. En dos semanas a mediados de junio, Huntress contó más de 81 millones de intentos y 78 cuentas comprometidas en 64 organizaciones. Muchas creían que la MFA ya estaba activa. Para el método que usó el atacante, nunca se disparó.

Este artículo explica qué es el spraying, cómo la campaña LSHIY abusó de un grant OAuth obsoleto, por qué el acceso condicional parecía completo y seguía incompleto, y qué cambiar para que una contraseña sola no abra la puerta.

El spraying no es fuerza bruta

Un ataque de fuerza bruta golpea una sola cuenta con muchas contraseñas. Ese patrón dispara bloqueos, límites de ritmo y alertas de desplazamiento imposible. El password spraying invierte el orden: el atacante elige una contraseña probable, la prueba contra una lista larga de usuarios, espera y pasa a la siguiente.

• Fuerza bruta: muchos intentos contra una cuenta. Rápido, ruidoso, fácil de bloquear.
• Password spraying: un intento contra muchas cuentas. Lo bastante lento para quedar bajo los umbrales de bloqueo.
• Credential stuffing: pares de correo y contraseña ya filtrados, reutilizados en otros sitios.

Esta campaña mezcló escala de spray con pares robados

La campaña LSHIY se situó entre esas dos últimas categorías. Huntress indicó que el objetivo seguía la prevalencia de contraseñas en listas combo comprometidas, no el sector ni el tamaño de la empresa. Los atacantes reutilizaron pares usuario/contraseña que ya se habían filtrado y nunca se habían rotado. Por eso la unicidad sigue importando aunque la MFA exista sobre el papel: una contraseña reutilizada que aún funciona es una sesión a la espera.

Un spray típico sigue empezando por el reconocimiento — usuarios válidos vía LinkedIn, webs de empresa, filtraciones o phishing — y una lista corta de contraseñas comunes o de temporada. Este operador no necesitaba conjeturas ingeniosas. Las contraseñas ya se conocían. La ventaja era el volumen, una infraestructura difícil de bloquear y un flujo que saltaba la página de MFA.

El flujo de autenticación que el tiempo olvidó

Azure CLI, la herramienta de línea de comandos para Azure y Microsoft Entra, aún acepta un grant OAuth heredado llamado Resource Owner Password Credentials (ROPC). La documentación de Microsoft advierte que ROPC es incompatible con la autenticación multifactor. OAuth 2.1 lo deprecó por completo.

En un inicio de sesión normal del navegador, el usuario llega a una página de autorización. Ahí el acceso condicional puede exigir MFA, comprobar el dispositivo o rechazar una ubicación de riesgo. ROPC nunca visita esa página. El cliente envía usuario y contraseña directo al endpoint /token del inquilino. Si la contraseña sigue siendo válida, puede emitirse un token delegado sin aviso interactivo.

Andrew «Spike» Brandt, de Huntress, lo dijo claro: aunque lo llamemos método de autorización, «técnicamente es un método de suplantación». Para un atacante con una contraseña reutilizada, ese es todo el premio: una sesión, no un intento.

La MFA estaba configurada. La política no.

Esto debería inquietar a quien trata una casilla de MFA como la meta. En el pico del 22 de junio, Huntress analizó 23 empresas afectadas. Ocho no tenían ninguna política MFA. Las otras 15 tenían MFA impuesta por acceso condicional — y aun así perdieron cuentas — porque la política no cubría la ruta del atacante.

• La MFA solo cubría aplicaciones concretas, como portales de administración de Microsoft, así que Azure CLI quedaba fuera.
• La MFA solo cubría ciertos grupos, a menudo «solo admins», y las cuentas comprometidas no estaban en ese alcance.
• La MFA solo se exigía desde ubicaciones no confiables. Una geolocalización IPv6 inconsistente hizo que direcciones del atacante parecieran de confianza.
• La MFA quedó en modo solo informe: configurada, observada, nunca aplicada.

Un recuento posterior dejó la brecha más clara

En un seguimiento, Huntress escribió que 55 de las 78 cuentas comprometidas ya tenían políticas de acceso condicional que exigían MFA. Una organización incluso llamó a una política «Block Azure CLI». No bloqueaba Azure CLI. La MFA no falló como tecnología. Falló como alcance.

Huntress no vio actividad posterior a la compromiso tras los inicios de sesión LSHIY. Rich Mozeleski sospecha que el operador validaba credenciales para revenderlas en lugar de instalarse en los inquilinos. Es un consuelo frío. Una contraseña confirmada que elude la MFA sigue siendo un producto en una lista, y el siguiente comprador puede no detenerse en la validación.

Bloquear IPs se convirtió en un juego del topo

La primera oleada vino del rango IPv6 2a0a:d683::/32, anunciado por LSHIY LLC (AS32167). El atacante usó el servicio bring-your-own-IP (BYOIP) de LSHIY — un peering legítimo que permite enrutar tráfico por rangos que el cliente ya posee. Tras las denuncias, LSHIY suspendió a ese usuario a principios de julio.

El spray no paró. La actividad pasó a rangos IPv6 de FranTech y luego a 3xK Tech en IPv4, rotando miles de direcciones y manteniendo bajo el volumen por IP. Huntress volvió a ver unos 1,5 millones de intentos al día. IPv6 da un enorme pozo de direcciones. Cambiar de proveedor da uno nuevo en cuanto se cierra el anterior.

Quien espera a bloquear el ASN de turno siempre irá un paso atrás. El control duradero es hacer que una contraseña no baste, no mantener una lista negra de la infraestructura de ayer.

Qué deberían cambiar las organizaciones

Afinar el acceso condicional sin bloquear a usuarios reales es difícil. Esa dificultad es parte de por qué esto sigue funcionando. La guía de Huntress sigue siendo el camino más corto:

• Exigir MFA — o bloquear el inicio de sesión — para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de cliente, sin exclusiones silenciosas.
• Usar un ajuste de cliente fuerte como userStrongAuthClientAuthNRequired para que ROPC falle aunque la contraseña sea correcta.
• Desactivar ROPC y otros grants heredados que no pueden satisfacer MFA. Microsoft ya pide a los desarrolladores que migren.
• Restringir Azure CLI a quienes realmente lo necesitan. La mayoría del personal no lo necesita.
• Priorizar la respuesta por validez de credenciales, no por volumen de spray. Los inquilinos más ruidosos suelen ser los menos comprometidos.
• Tratar la higiene de contraseñas como una MFA inacabada: secretos únicos, rotación tras cualquier filtración y passkeys u otras opciones sin contraseña para cuentas de alto valor.
• Escribir las reglas. Nuestra guía de contraseñas seguras de 2026 ayuda a convertir «tenemos MFA» en un estándar aplicable sobre reutilización, rotación y métodos de respaldo.

Qué puede hacer cada persona

No hace falta un inquilino Entra para estar en este radio. Las mismas listas combo que alimentaron los sprays de Azure CLI se prueban a diario contra correo personal, compras y redes sociales. El spraying y el stuffing se alimentan de la reutilización.

• Usa una contraseña única en cada cuenta. Genera una con nuestro generador y guárdala en un gestor.
• Ejecuta un test de filtraciones sobre todo lo que hayas reutilizado. Las contraseñas de LSHIY eran viejas; seguían funcionando porque nadie las había rotado.
• Activa MFA en todas partes y luego prefiere passkeys o una llave de seguridad para el correo, el gestor, la banca y el trabajo. La MFA clásica aún ayuda contra el stuffing, pero como explica nuestro artículo AitM, SMS y TOTP no son el final de la historia.
• Si usas Azure CLI u otro cliente heredado, pregunta a TI si ROPC sigue permitido para tu cuenta. Una contraseña que nunca escribes en el navegador aún puede reutilizarse con una herramienta.