81 millones de intentos de password spray en Azure CLI. Los atacantes no intentaban romper la MFA. La estaban eludiendo.
Ochenta y un millones de intentos de password spray. Setenta y ocho cuentas comprometidas. Treinta y nueve organizaciones afectadas. Esas son las cifras que Huntress publicó el 1 de julio de 2026, tras una campaña activa dirigida a entornos de Microsoft Azure – y el número más importante no es ninguno de esos. El número clave es cero, que es la cantidad de veces que los atacantes activaron un reto de MFA.
Esta campaña no se centró en vulnerar el MFA. Se diseñó para evitarlo por completo. La técnica no es nueva – investigadores de seguridad ya han documentado ataques de autenticación basados en ROPC – pero la magnitud de esta campaña y la especificidad del objetivo Azure CLI la convierten en el ejemplo más claro y reciente de lo que ocurre cuando los flujos de autenticación heredados conviven con controles de identidad modernos en el mismo entorno empresarial.
La investigación de Huntress documenta cómo los atacantes usaron el flujo OAuth 2.0 Resource Owner Password Credentials para autenticarse directamente en Azure AD sin activar políticas de acceso condicional ni requisitos de MFA. Entender por qué esto funciona requiere comprender qué es ROPC, en qué se diferencia de los flujos de autenticación modernos y por qué sigue estando accesible en la mayoría de los tenants de Azure a pesar de que Microsoft ha declarado obsoleto el protocolo.
Puntos Clave
1. Huntress documentó 81 millones de intentos de password spray usando Azure CLI, comprometiendo 78 cuentas en 39 organizaciones.
La campaña se dirigió a un flujo heredado de OAuth 2.0 llamado Resource Owner Password Credentials (ROPC), que transmite credenciales directamente a Azure AD y evita por completo la aplicación de MFA y las políticas de acceso condicional modernas.
2. Microsoft ha declarado obsoleto ROPC, pero sigue funcionando ampliamente.
El flujo OAuth 2.0 ROPC fue diseñado para sistemas heredados que no pueden redirigir a los usuarios a un navegador para autenticación. Microsoft lo declaró obsoleto en favor de flujos modernos, pero como sigue operativo técnicamente en la mayoría de los tenants de Azure, los atacantes pueden usarlo para autenticarse sin activar controles de MFA ni de políticas de acceso condicional.
3. La mala configuración de las políticas de acceso condicional es el principal facilitador.
Incluso organizaciones que han implementado políticas de acceso condicional suelen tener brechas de cobertura – aplicaciones específicas, grupos de usuarios o condiciones basadas en ubicación que dejan el tráfico ROPC sin protección. Azure CLI suele ser una excepción común, lo que significa que las credenciales de desarrollador autenticadas vía ROPC pueden acceder a recursos de producción.
4. El patrón de ataque explota la brecha entre la intención de la política y la aplicación técnica.
Las organizaciones creen que el MFA protege su entorno Azure porque protege la autenticación basada en navegador. La autenticación ROPC no pasa por ese mismo flujo. Esto no es una vulnerabilidad del MFA en sí, sino una mala configuración que deja abierto un camino de autenticación heredado junto al moderno.
5. La solución requiere más que buenas prácticas de contraseñas.
Bloquear el camino de ataque ROPC exige una combinación de: bloquear protocolos de autenticación heredados a nivel de tenant, auditar la cobertura de las políticas de acceso condicional para detectar brechas, rotar credenciales en cuentas con acceso a Azure CLI e implementar controles de Gestión de Identidades y Accesos que marquen los eventos de autenticación ROPC como anómalos.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
Qué es ROPC y por qué sigue existiendo
El marco OAuth 2.0 ofrece varios flujos de autenticación diseñados para diferentes casos de uso. El estándar moderno para autenticación interactiva de usuarios es el flujo Authorization Code con PKCE – redirige a los usuarios a un proveedor de identidad, recoge credenciales allí y devuelve un código de autorización a la aplicación. Este flujo es compatible con MFA y políticas de acceso condicional porque la autenticación ocurre en el proveedor de identidad, donde residen esos controles.
ROPC se diseñó como alternativa para aplicaciones heredadas que no pueden realizar redirecciones basadas en navegador. En vez de enviar a los usuarios a una página de inicio de sesión, ROPC acepta credenciales directamente desde la aplicación y las pasa al proveedor de identidad como una solicitud POST. La propia aplicación gestiona el intercambio de credenciales.
Microsoft declaró obsoleto ROPC porque es arquitectónicamente incompatible con los controles de seguridad modernos. Las credenciales pasan por la aplicación en vez de la interfaz de autenticación del proveedor de identidad, lo que significa que no se pueden insertar retos de MFA en el flujo. Las políticas de acceso condicional que se activan en eventos de inicio de sesión no se disparan. La emisión de tokens ocurre sin que se complete la evaluación de acceso condicional del proveedor de identidad.
El problema es que obsoleto no significa deshabilitado. ROPC sigue funcionando en la mayoría de los tenants de Azure. Microsoft ha ido migrando a los clientes hacia flujos de autenticación modernos, pero ROPC sigue operativo por compatibilidad con sistemas heredados. En la campaña documentada por Huntress, los atacantes usaron ROPC para autenticarse contra Azure CLI – una herramienta común de desarrollo con acceso a recursos de Azure – porque Azure CLI soporta autenticación ROPC y la mayoría de las organizaciones no la han bloqueado explícitamente. Un análisis formal de riesgos sobre la cobertura de protocolos de autenticación — mapeando específicamente qué flujos heredados siguen habilitados y en qué ámbitos de aplicación — es el punto de partida para cerrar este tipo de brechas antes de que se conviertan en incidentes.
Cómo funciona el ataque en la práctica
La campaña documentada por Huntress sigue un patrón reconocible: enumerar nombres de usuario válidos, ejecutar credential stuffing o password spray contra endpoints accesibles vía ROPC, recolectar tokens de autenticaciones exitosas y usar esos tokens para acceder a recursos de Azure.
La pieza de Azure CLI es relevante por el alcance que suele tener el acceso CLI. Las cuentas de desarrollador con acceso a Azure CLI suelen tener permisos sobre entornos de producción, grupos de recursos, cuentas de almacenamiento y recursos de cómputo. El CLI es una herramienta de gestión – se espera que tenga acceso amplio. Cuando los atacantes comprometen una credencial CLI vía ROPC, no solo obtienen acceso al correo. Potencialmente acceden a la infraestructura.
Los ataques de fuerza bruta contra endpoints de autenticación tradicionales son ruidosos. Generan eventos de inicio de sesión fallidos que las plataformas SIEM y los sistemas de protección de identidad detectan y alertan. Los password sprays basados en ROPC pueden ser más silenciosos: no generan los mismos eventos de autenticación de sesión de navegador y muchas configuraciones de registro no capturan la emisión de tokens ROPC con la misma precisión que los eventos de inicio de sesión interactivos.
La cifra de 81 millones de intentos refleja el coste computacional de hacer password spraying a gran escala – es un número grande, pero los 78 compromisos exitosos (0,000096% de éxito) también muestran cómo las credenciales se distribuyen entre muchos intentos hasta encontrar una coincidencia. El verdadero riesgo no es la cantidad de intentos, sino que cada autenticación ROPC exitosa devuelve un token bearer que da acceso a todo lo que la cuenta comprometida puede alcanzar. Una sola cuenta de desarrollador comprometida con acceso a cuentas de almacenamiento de producción, recursos de cómputo y pipelines CI/CD es una brecha de datos y un incidente a nivel de infraestructura al mismo tiempo — la combinación de propiedad intelectual en repositorios de código y datos regulados en almacenamiento en la nube implica obligaciones de notificación y remediación significativas.
Phishing y el reuso de contraseñas son las fuentes más comunes de las credenciales usadas en campañas de password spray. Una vez que las credenciales aparecen en bases de datos de brechas – y la mayoría lo hace, tarde o temprano – se convierten en insumos para herramientas automatizadas de spray. La autenticación ROPC a escala depende principalmente de: (a) cuántas credenciales válidas han obtenido los atacantes de brechas previas y (b) cuántos endpoints de tenant son accesibles vía ROPC sin aplicación de CAP.
El problema de cobertura de las políticas de acceso condicional
Las políticas de acceso condicional son el principal control de defensa en profundidad para entornos Azure AD. Permiten definir condiciones bajo las cuales la autenticación es exitosa – exigir MFA, bloquear ubicaciones de inicio de sesión riesgosas, restringir acceso a dispositivos en cumplimiento. Cuando están bien configuradas, las CAP hacen que los password sprays sean en gran parte ineficaces porque incluso una credencial válida no autenticará si no cumple las condiciones de la política.
El problema de cobertura en los ataques ROPC no es que las CAP no funcionen. Es que la cobertura rara vez es completa. Las organizaciones implementan CAP de forma incremental, empezando por aplicaciones y grupos prioritarios, y acumulando excepciones con el tiempo. Azure CLI suele ser una excepción común: los desarrolladores necesitan acceso CLI, las herramientas CLI en pipelines automatizados no pueden manejar interrupciones de MFA y el resultado es una excepción CAP que convierte la autenticación CLI en un objetivo fácil.
La configuración de seguridad incorrecta en la capa de identidad sigue siendo uno de los vectores de ataque de mayor impacto. Una sola excepción de política mal configurada puede exponer credenciales a caminos de autenticación heredados que eluden un MFA robusto. La campaña de Huntress es consecuencia directa de esa dinámica: 78 cuentas comprometidas no porque el MFA sea débil, sino porque esas cuentas tenían una excepción CAP o estaban en un ámbito de aplicación que permitía autenticación ROPC.
La pregunta de auditoría que las organizaciones deben hacerse no es «¿tenemos políticas de acceso condicional?» sino «¿nuestras políticas de acceso condicional cubren todos los caminos de autenticación, incluidos los endpoints de protocolos heredados, para todas las cuentas de usuario?» La mayoría no ha auditado esto a nivel de protocolo. Extender las prácticas de administración de riesgos de la cadena de suministro a esta cuestión es especialmente relevante para organizaciones que han dado acceso Azure CLI a desarrolladores externos, contratistas o proveedores de servicios gestionados — cada credencial externa con acceso CLI es un punto de exposición ROPC que la auditoría CAP de la organización principal puede no controlar directamente.
Gobernanza de identidad más allá del MFA
El patrón de ataque ROPC plantea un argumento estructural sobre la seguridad de identidad que el MFA por sí solo no resuelve. El MFA es un control que opera sobre flujos de autenticación interactivos. Los protocolos de autenticación heredados se diseñaron para operar fuera de esos flujos. Por diseño, son incompatibles con MFA.
La respuesta arquitectónica requiere actuar a nivel de protocolo, no solo a nivel de credenciales. Bloquear la autenticación heredada implica configurar Azure AD para rechazar solicitudes de token ROPC por completo – se puede crear una CAP que bloquee la autenticación heredada para todos los usuarios o grupos específicos. Esta es la mitigación principal recomendada tanto por Microsoft como por la investigación de Huntress.
Los marcos de control de acceso basado en roles y control de acceso basado en atributos que limitan las credenciales de desarrollador al mínimo privilegio reducen el alcance de un compromiso ROPC. Una cuenta de desarrollador que solo puede leer ciertos contenedores de almacenamiento y desplegar en grupos de recursos específicos es menos catastrófica de comprometer que una con acceso de colaborador a toda una suscripción. La minimización de datos aplicada al alcance de las credenciales — aprovisionar cuentas de desarrollador solo con los permisos mínimos de Azure necesarios para su tarea actual, revisados periódicamente en vez de acumularse durante años de cambios de rol — es la práctica operativa que convierte el mínimo privilegio en una realidad en tiempo de ejecución y no solo en la intención al aprovisionar.
Los programas de Gestión de Identidades y Accesos que tratan las credenciales de desarrollador como una categoría de riesgo distinta – con rotación programada, revisiones de alcance y detección de anomalías en la emisión de tokens ROPC – son la respuesta empresarial a este patrón de ataque. La mayoría de los programas IAM se crearon para gestionar credenciales humanas en flujos basados en navegador. Las credenciales de desarrollador usadas en herramientas CLI y pipelines de automatización suelen quedar fuera de esos flujos.
La arquitectura de confianza cero aplicada a la identidad en la nube exige verificación continua a nivel de evento de autenticación, no solo a nivel de acceso a la aplicación. Cuando se emite un token vía ROPC, los principios de confianza cero indican que ese token debe evaluarse en busca de señales de riesgo – geografía de origen inusual, patrones de reuso de credenciales, velocidad de acceso – antes de que se sirvan los recursos. Esa evaluación continua es lo que ofrecen los controles basados en CAP, y por eso la evasión de CAP por ROPC es tan relevante.
El Informe anual de previsiones de riesgos de seguridad y cumplimiento de datos 2026 de Kiteworks concluyó que las brechas en la gestión de identidades y accesos siguen siendo una de las causas raíz más comunes en brechas de datos empresariales. La campaña ROPC documentada por Huntress es un ejemplo preciso de ese hallazgo: no es un sofisticado zero-day, sino una brecha de protocolo heredado que la mayoría de las organizaciones no ha abordado específicamente en sus programas de gobernanza de identidad. Las organizaciones que canalizan contenido sensible a través de una Red de Contenido Privado con controles de acceso por políticas y registro de auditoría inmutable en la capa de contenido cuentan con una barrera adicional: incluso una credencial de Azure comprometida con acceso a producción no puede llegar a contenido que las políticas ABAC de Kiteworks restringen a identidades autorizadas específicas.
Pasos inmediatos de remediación
La investigación de Huntress ofrece recomendaciones concretas que las organizaciones pueden aplicar de inmediato. Las medidas principales son:
Bloquear la autenticación heredada a nivel de tenant. Las políticas de acceso condicional de Azure AD pueden bloquear protocolos de autenticación heredados, incluido ROPC, para todos los usuarios o para grupos y aplicaciones específicos. Microsoft ofrece una plantilla de política para esto. Las organizaciones que han pospuesto este paso por dependencias de aplicaciones heredadas deben auditar esas dependencias y planificar una migración.
Auditar la cobertura de las políticas de acceso condicional. Mapear cada cuenta de usuario y aplicación frente a las políticas CAP que se les aplican. Identificar brechas – aplicaciones sin CAP, cuentas excluidas de MFA, cuentas de servicio con acceso CLI que evitan el acceso condicional. Cada brecha es un posible punto de exposición ROPC.
Rotar credenciales para cuentas con acceso a Azure CLI. En la campaña de Huntress, 78 cuentas se autenticaron exitosamente vía ROPC antes de que se detectara la campaña. Las organizaciones que no puedan descartar exposición deben rotar credenciales de todas las cuentas de desarrollador con acceso CLI o programático a Azure.
Habilitar el registro de inicios de sesión para eventos ROPC. Los registros de inicio de sesión de Azure AD capturan eventos de autenticación, incluida la autenticación heredada. Configurar alertas en SIEM para eventos de autenticación ROPC ofrece una alerta temprana ante futuros intentos de spray – y establece la línea base de registro de auditoría necesaria para la respuesta a incidentes.
Implementar detección de anomalías en la emisión de tokens. Las solicitudes de token ROPC que provienen de rangos de IP, geografías o en horarios inusuales son señales detectables. Las herramientas de protección de identidad que puntúan eventos de riesgo de autenticación pueden marcar intentos de spray ROPC antes de que se multipliquen las autenticaciones exitosas. El panel de CISO ofrece a la dirección de seguridad visibilidad en tiempo real sobre los patrones de acceso a contenido en todos los canales gobernados — de modo que la actividad anómala tras una credencial comprometida se detecte antes de que escale a un incidente reportable.
Para saber más sobre cómo Kiteworks aborda la gobernanza de identidad, los controles de acceso y la configuración incorrecta de seguridad en la nube en entornos regulados, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
El flujo Resource Owner Password Credentials (ROPC) es un mecanismo de autenticación heredado de OAuth 2.0 que pasa las credenciales del usuario directamente desde una aplicación al proveedor de identidad mediante una solicitud POST, evitando la autenticación con redirección basada en navegador utilizada por los flujos modernos. Como las credenciales pasan por la aplicación en vez de la interfaz de autenticación del proveedor de identidad, no se pueden insertar retos de MFA en el flujo y las evaluaciones de inicio de sesión de las políticas de acceso condicional no se activan. Microsoft declaró obsoleto ROPC por estas limitaciones de seguridad, pero el protocolo sigue funcionando en la mayoría de los tenants de Azure por compatibilidad con aplicaciones heredadas. Huntress documentó atacantes usando este flujo para ejecutar 81 millones de intentos de password spray contra endpoints de Azure CLI en 2026, comprometiendo 78 cuentas sin activar ni un solo reto de MFA. La configuración de seguridad incorrecta no está en el MFA en sí, sino en la disponibilidad continua de un camino de autenticación que lo evita. Las organizaciones sujetas a obligaciones de cumplimiento normativo — HIPAA, CMMC, GDPR, FINRA — deben tratar la disponibilidad de ROPC en su tenant de Azure como una brecha de cumplimiento, ya que los caminos de autenticación heredados no monitoreados debilitan la documentación de control de acceso que exigen esos marcos.
Un ataque de password spray a Azure CLI usando ROPC funciona así. Los atacantes obtienen o compilan una lista de credenciales válidas de usuarios de Azure AD – generalmente de bases de datos de brechas previas, campañas de phishing o resultados de credential stuffing. Luego envían esas credenciales al endpoint de token ROPC de Azure AD mediante solicitudes de autenticación de Azure CLI. Cuando las credenciales son válidas y ninguna política de acceso condicional bloquea el flujo ROPC para esa cuenta, Azure AD emite un token de acceso sin activar MFA. El atacante usa ese token para autenticar comandos de Azure CLI contra los recursos de Azure de la víctima. El ataque es detectable mediante monitoreo SIEM de eventos de inicio de sesión heredados en los registros de Azure AD, pero solo si el registro está habilitado y las alertas configuradas. Los principios de arquitectura de confianza cero que exigen verificación continua a nivel de emisión de token – incluida la puntuación de riesgo para solicitudes de autenticación heredada – ofrecen cobertura de detección que el MFA por sí solo no brinda. Un plan de respuesta a incidentes documentado que cubra explícitamente escenarios de compromiso ROPC — incluyendo los pasos de revisión de registros de actividad de Azure y la secuencia de rotación de credenciales — da a los equipos de seguridad una ruta definida desde la detección hasta la contención.
Una política de acceso condicional (CAP) en Azure AD define condiciones bajo las cuales la autenticación es exitosa – exigir MFA desde ubicaciones específicas, bloquear eventos de inicio de sesión riesgosos o restringir acceso a dispositivos en cumplimiento. Cuando están bien configuradas y delimitadas, las CAP hacen que los ataques de password spray sean en gran parte ineficaces porque incluso credenciales válidas no autenticarán si no cumplen las condiciones de la política. El ataque ROPC evita las CAP porque su aplicación se activa en flujos de inicio de sesión interactivos; las solicitudes de token ROPC no disparan ese flujo. Además, muchas organizaciones tienen excepciones CAP para herramientas de desarrollo, pipelines de automatización y aplicaciones heredadas que requieren autenticación compatible con ROPC. Estas excepciones crean las brechas de cobertura que explotó la campaña documentada por Huntress. Las auditorías de Gestión de Identidades y Accesos que mapean específicamente la cobertura de protocolos de autenticación – no solo la de aplicaciones – son necesarias para identificar estas brechas. Aplicar controles de acceso en la capa de contenido — no solo en la capa de identidad — ofrece una segunda barrera de aplicación que sigue siendo efectiva incluso cuando una brecha de autenticación permite la emisión de tokens.
Exigir MFA en Azure AD significa que los flujos de autenticación interactivos activan un reto MFA antes de emitir tokens. Bloquear la autenticación heredada significa que Azure AD rechaza solicitudes de token que usan protocolos de autenticación heredados (incluido ROPC) por completo, sin importar la validez de las credenciales. Son dos controles separados con efectos distintos. El MFA por sí solo no protege contra ataques ROPC porque ROPC evita el flujo de autenticación interactivo donde se activa el MFA. Bloquear la autenticación heredada detiene las solicitudes de token ROPC antes de evaluar las credenciales, previniendo el ataque a nivel de protocolo. Microsoft recomienda bloquear la autenticación heredada como configuración de seguridad base, y Azure AD ofrece una plantilla CAP específica para este fin. Las organizaciones deben implementar ambos controles: exigir MFA para toda autenticación interactiva y bloquear protocolos de autenticación heredados para todas las cuentas y aplicaciones que ya migraron a flujos modernos. El control de acceso basado en roles que limita las credenciales de desarrollador al mínimo privilegio reduce el daño de cualquier brecha de autenticación heredada que persista. Los programas de administración de riesgos de terceros deben verificar que los proveedores de servicios gestionados y contratistas que operan en el entorno Azure hayan confirmado que han bloqueado la autenticación heredada en sus propias herramientas administrativas — una cuenta MSP con credenciales CLI accesibles vía ROPC crea la misma exposición que una cuenta interna de desarrollador.
Las organizaciones que crean haber sido objetivo de un password spray ROPC a Azure CLI deben tomar cinco acciones inmediatas. Primero: extraer los registros de inicio de sesión de Azure AD y filtrar eventos de autenticación heredada de los últimos 90 días – las solicitudes de token ROPC aparecen como eventos de inicio de sesión heredados. Segundo: identificar cuentas que se hayan autenticado exitosamente vía autenticación heredada y revisar sus registros de actividad de Azure en busca de accesos no autorizados. Tercero: rotar credenciales de todas las cuentas con acceso a Azure CLI, aunque no se confirme autenticación ROPC. Cuarto: implementar una política de acceso condicional que bloquee la autenticación heredada para todas las cuentas de usuario, o al menos para todas las cuentas con acceso CLI o API programático a Azure. Quinto: revisar y cerrar todas las excepciones CAP para herramientas de desarrollo y cuentas de servicio de automatización. Después, establecer una línea base completa de registro de auditoría y configurar alertas en SIEM para futuros eventos de autenticación ROPC. El proceso de respuesta a incidentes debe documentar hallazgos para cualquier obligación de notificación de cumplimiento normativo que aplique. Las organizaciones que gestionan datos regulados — PHI, CUI, PII — deben además evaluar si alguna cuenta de almacenamiento o repositorio de datos accesible a las credenciales de Azure comprometidas contiene contenido que requiera notificación de brecha de datos bajo los marcos aplicables.
Recursos adicionales
- Artículo del Blog
Cómo diseñar un flujo de transferencia segura de archivos para proveedores y contratistas externos - Artículo del Blog
La importancia de la administración de riesgos de proveedores para CISOs - Artículo del Blog
Cómo proteger la propiedad intelectual al colaborar con terceros - Artículo del Blog
Combate amenazas con seguridad y administración de riesgos en la cadena de suministro - Artículo del Blog
Brechas de datos de socios: tu seguridad es tan fuerte como tu socio más débil