Ocho minutos hasta AWS-Admin: Cómo un cubo S3 abierto y una Lambda de administrador bastaron

6 Min. de lectura

El 28 de noviembre de 2025, un atacante tomó el control completo de una cuenta de AWS en ocho minutos. Desde la primera clave de acceso robada hasta los derechos de administrador completos. El equipo de seguridad de Sysdig documentó el caso. Lo explosivo es la velocidad: una IA realizó el reconocimiento y la creación de scripts en tiempo real. La puerta de entrada fue un conocido error de configuración.

Lo más importante en resumen

• Ocho minutos hasta admin: Según Sysdig, un atacante comprometió una cuenta de AWS en menos de diez minutos. Desde claves robadas en un bucket S3 abierto hasta un usuario administrador creado por el propio atacante.
• El error estaba en la configuración: Una función Lambda tenía un rol de ejecución con derechos de administrador. Quien podía modificar la función heredaba esos derechos. No fue necesario un nuevo exploit.
• La IA fue el turbo: Escribió código de ataque y exploró la cuenta en tiempo real. Sin embargo, según Mandiant, la mediana del sector para ataques es de 14 días. El caso de ocho minutos es la excepción, con condiciones especiales.

Relacionado:Cómo una brecha en Argo CD abre todo el clúster  /  AWS y Azure bajo supervisión de la UE

Ocho minutos del bucket S3 a la clave de administrador

El punto de entrada estaba expuesto en la red. En un bucket S3 accesible públicamente había datos de entrenamiento para un sistema de IA, entre ellos claves de acceso válidas de un usuario de IAM. Este usuario tenía pocos permisos, pero uno fue suficiente: podía modificar el código de una determinada función Lambda. La función se llamaba EC2-init y tenía asociado un rol de ejecución con derechos de administrador.

A partir de aquí, todo fue rápido. El atacante modificó la función, la hizo generar nuevas claves de acceso para un usuario administrador llamado *frick* y leyó el resultado directamente de la respuesta de la función. Sin rodeos a través de un servidor externo, sin reverse shell. A continuación, accedió a 19 identidades diferentes de AWS, creó un segundo administrador de puerta trasera y así aseguró el acceso en múltiples ocasiones.

Después, la cosa se puso cara. A través del servicio de IA Amazon Bedrock, el atacante utilizó modelos de lenguaje de terceros a costa de la víctima. Paralelamente, inició una instancia de GPU por unos 30 euros la hora para ejecutar sus propios modelos. AWS detuvo la instancia a los cinco minutos por límites de capacidad. Lo revelador fue el propio código: comentarios en serbio y números de cuenta de AWS inventados delataron que un modelo de lenguaje había participado en su redacción.

No es un zero-day, sino una cadena de errores conocidos

La cifra de ocho minutos parece romper con todo lo que se sabe sobre seguridad en la nube. Sin embargo, al analizar el vector de ataque, se observa lo contrario. No hay ninguna vulnerabilidad desconocida ni un exploit específico de IA. Cada paso aprovechó una mala configuración documentada.

Claves de acceso de larga duración se encontraban en un bucket público. Un rol de ejecución de Lambda tenía permisos de administrador, aunque nunca los hubiera necesitado. Un usuario con permisos insuficientes podía sobrescribir código de funciones ajenas. Estos tres errores juntos formaron la cadena. Cada uno de ellos es conocido desde hace años y está identificado en todas las guías de endurecimiento de AWS.

La IA aceleró y automatizó el ataque, pero no lo hizo posible. Quien interprete este caso como prueba de que la IA vuelve insegura la nube, pasa por alto la verdadera causa. Y, con ello, el punto donde la defensa es efectiva. La causa es reparable, sin necesidad de defensa basada en IA.

Por qué la cifra de minutos induce a error

Un segundo dato pone las cosas en perspectiva. La unidad de seguridad de Google, Mandiant, analiza cada año cientos de miles de horas de respuesta a incidentes. En el informe M-Trends 2026 del 23 de marzo aparece una frase que contradice el alarmismo: 2025 no debe considerarse el año en que los ataques surgieron directamente por la IA.

Los números lo respaldan. La mediana de permanencia de un atacante en la red aumentó en 2025 a 14 días, frente a los 11 del año anterior. En el 52 % de los casos, las empresas detectaron la intrusión por sí mismas. Las vulnerabilidades explotadas siguen siendo, con un 32 %, el vector de entrada más común, por sexto año consecutivo. La mayoría de los ataques siguen moviéndose en escalas de días y semanas.

El caso de los ocho minutos es real, pero es la excepción, no el nuevo promedio. Fue tan rápido porque las condiciones eran ideales. Para los defensores, esta es la buena noticia: quien elimine estas condiciones, priva al ataque rápido de su base.

Cinco pasos para endurecer cuentas de AWS ahora

Ningún parche del fabricante resuelve el problema, ya que radica en la configuración. Y es precisamente ahí donde puede solucionarse. El orden está clasificado por eficacia.

1. Eliminar claves de larga duración. En lugar de claves IAM permanentes, el funcionamiento habitual debe basarse en roles de corta duración y credenciales temporales. Una clave filtrada que pierde validez tras una hora ya no abre ninguna puerta.
2. Separar administradores de roles de ejecución. Ninguna función Lambda necesita permisos de administrador para realizar su tarea. Cada rol de ejecución recibe exactamente los permisos que requiere su función, ni uno más.
3. Detectar buckets públicos. Los buckets S3 con datos de entrenamiento acaban fácilmente en la red por error. Un escaneo regular de buckets abiertos y de las credenciales que contienen cierra la vía de entrada más común.
4. Proteger Bedrock con barreras. Las Service Control Policies limitan quién puede iniciar servicios de IA costosos e instancias GPU. Esto limita el daño si una cuenta es comprometida.
5. Supervisar la ejecución en tiempo real. Nuevos usuarios administradores, llamadas externas a Bedrock e instancias GPU iniciadas de repente son señales claras. Quien las detecte en tiempo real detiene el ataque en pleno desarrollo.

Configuración incorrecta frente a configuración reforzada

La diferencia entre una cuenta de ocho minutos y un entorno seguro no radica en una nueva herramienta. Está en los valores predeterminados que hay que conocer y aplicar.

Qué pueden aprender los equipos de este caso

El revuelo en torno a los ocho minutos desvía la atención del hallazgo real. El ataque fue rápido porque faltaba la higiene básica. Credenciales de corta duración, roles asignados con moderación y una revisión de los buckets abiertos habrían interrumpido la cadena en cualquier punto. Estas medidas son antiguas, poco llamativas y eficaces.

Un detalle debería alertar especialmente a los defensores. Sysdig advierte de que las pistas reveladoras de IA en el código pronto desaparecerán. Los agentes mejorados no escribirán comentarios en serbio ni inventarán números de cuenta. La ventana en la que un ataque basado en IA puede detectarse en el código se está cerrando. Solo queda el refuerzo, que ya hoy frena cada uno de estos pasos.

Preguntas frecuentes

Fuente de la imagen: generada por IA (julio de 2026)