Datadog Security Research ha detectado una campaña de password-spraying dirigida a las cuentas root de AWS en más de 150 organizaciones entre julio y agosto de 2026. Los atacantes realizaron múltiples intentos fallidos de inicio de sesión contra identidades con privilegios elevados, centrándose en el usuario root, el cual posee acceso irrestricto a todos los recursos de la nube.

Datadog Security Research observó una campaña de password-spraying dirigida a cuentas root de AWS en más de 150 organizaciones entre el 24 de julio y el 23 de agosto de 2026, con repetidos intentos fallidos de inicio de sesión en la consola contra identidades con altos privilegios.

El usuario root de AWS es la identidad original creada cuando se registra una cuenta de AWS. Tiene acceso sin restricciones a los recursos en la nube, la configuración de la cuenta, la información de facturación y funciones administrativas sensibles. Una cuenta root comprometida podría darle a un atacante un control amplio sobre el entorno de AWS de tu organización.

Datadog descubrió que la mayoría de las organizaciones recibieron solo un pequeño número de intentos de inicio de sesión. La mediana de intentos fallidos por organización fue de dos. Al mismo tiempo, algunas víctimas vieron hasta ocho durante la campaña de un mes.

Los investigadores no identificaron ninguna autenticación exitosa, lo que indica que no hay evidencia de que la campaña resultara en compromisos confirmados de cuentas de AWS.

Los atacantes utilizaron el password spraying, un método de ataque en el cual los actores de amenazas prueban un conjunto limitado de contraseñas comúnmente utilizadas o previamente expuestas contra muchas cuentas.

Atacan las cuentas root de AWS

Este enfoque está diseñado para evitar activar los bloqueos de cuenta que pueden ocurrir durante los ataques tradicionales de fuerza bruta centrados en una sola cuenta.

Dos cadenas de user-agent de navegador estuvieron repetidamente asociadas con la actividad. Una suplantaba un navegador Microsoft Edge antiguo basado en la versión 85 de Chrome, mientras que la otra suplantaba Firefox versión 120.

El uso de estos identificadores puede ayudarte a buscar en los registros intentos de autenticación relacionados. Sin embargo, los valores de user-agent pueden ser fácilmente falsificados por los atacantes.

La campaña también se apoyó en una infraestructura de proxies. Las direcciones IP de origen estaban distribuidas en muchos países y sistemas autónomos, lo que hace que el bloqueo geográfico sea menos efectivo.

Los servicios de inteligencia de amenazas identificaron la infraestructura como servicios de alojamiento, proxies residenciales o sistemas similares comúnmente utilizados para ocultar el origen del tráfico malicioso.

Los investigadores de Datadog dijeron que las organizaciones víctimas no mostraron un patrón claro. Los objetivos abarcaron múltiples industrias y países, lo que sugiere que los atacantes pueden haber utilizado una lista amplia de correos electrónicos potenciales de cuentas de AWS en lugar de centrarse en un sector específico.

La operación es notable porque los intentos de inicio de sesión en la consola raíz de AWS requieren la dirección de correo electrónico de la cuenta, lo que sugiere que los atacantes pueden haber obtenido los correos de las cuentas root a través de filtraciones de datos, registros públicos, phishing u otro reconocimiento.

Otra posibilidad es que el atacante probara una gran cantidad de direcciones de correo electrónico corporativas hasta identificar identidades raíz de AWS válidas.

Las cuentas root de AWS son objetivos particularmente sensibles porque pueden realizar acciones no disponibles para los usuarios IAM ordinarios. Sin embargo, AWS ha introducido protecciones más fuertes para la cuenta root.

Desde junio de 2025, AWS IAM ha impuesto la autenticación multifactor (MFA) para los usuarios root en todos los tipos de cuenta, con un periodo de gracia de 35 días después del primer intento de inicio de sesión en la consola.

El MFA puede evitar la toma de control de la cuenta incluso si un atacante tiene la contraseña correcta. Sin embargo, no debes tratar el MFA como el único control.

Tus equipos de seguridad deben revisar los registros de AWS CloudTrail en busca de eventos de ConsoleLogin a nivel de raíz, especialmente los intentos fallidos que utilicen los user-agents de Chrome/Edge y Firefox identificados. También deberían crear alertas sobre inicios de sesión directos de root, actividad de API de root, cambios en las credenciales de root y sesiones privilegiadas inusuales.

Deberías minimizar el uso rutinario de credenciales root, habilitar el acceso root centralizado donde sea posible, aplicar políticas de control de servicios que restrinjan la actividad directa de la root en las cuentas miembro y proteger las credenciales root de la cuenta de gestión con un MFA de hardware fuerte y resistente al phishing.