De bucket S3 abierto a admin de AWS en ocho minutos
Un atacante tomó control de una cuenta AWS en ocho minutos mediante un bucket S3 expuesto y un rol Lambda con permisos de administrador. La IA solo aceleró el ataque.
6 min. de lectura
El 28. noviembre 2025, un atacante tomó control de una cuenta AWS completa en ocho minutos. Desde la primera clave de acceso robada hasta derechos de administrador completos. El equipo de seguridad de Sysdig documentó el caso. La rapidez del incidente es alarmante: una IA realizó el análisis y la creación de scripts en tiempo real. La puerta de entrada fue un conocido error de configuración.
Lo esencial en breve
- Ocho minutos hasta admin: Según Sysdig, un atacante comprometió una cuenta AWS en menos de diez minutos. Desde claves robadas en un bucket S3 abierto hasta la creación de un usuario admin propio.
- El error estaba en la configuración: Una función Lambda tenía un rol de ejecución con privilegios de administrador. Quien podía reescribir la función heredaba esos derechos. No se necesitaba un nuevo exploit.
- La IA fue el turbo: La IA escribió código de ataque y exploró la cuenta en tiempo real. El tiempo medio de la industria para ataques, según Mandiant, sigue siendo de 14 días. El caso de ocho minutos es una excepción con condiciones especiales.
Relacionado:Cómo una brecha de Argo-CD abre todo el clúster / AWS y Azure bajo supervisión de la UE
Ocho minutos desde el bucket S3 hasta la clave de administrador
El acceso quedó expuesto en la red. En un bucket S3 accesible públicamente se encontraban datos de entrenamiento para un sistema de IA, entre ellos claves de acceso válidas de un usuario de IAM. Este usuario apenas tenía permisos, pero con uno bastaba: podía modificar el código de una función Lambda específica. La función se llamaba EC2-init. Adjunta a ella había un rol de ejecución con derechos de administrador.
Desde aquí todo ocurrió rápidamente. 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 pasar por un servidor externo, sin usar una reverse shell. Luego accedió a 19 diferentes identidades de AWS, creó un segundo admin puerta trasera y se aseguró así el acceso en múltiples ocasiones.
Luego se volvió costoso. A través del servicio de IA Amazon Bedrock, el atacante consumió modelos de lenguaje ajenos a costa de la víctima. Paralelamente, lanzó una instancia GPU por alrededor de 30 Euro por hora para ejecutar sus propios modelos. AWS terminó la instancia después de cinco minutos por límites de capacidad. El código del atacante delató el delito: comentarios serbios y números de cuenta AWS falsos revelaron que un modelo de lenguaje había participado.
Sin cero día, sino una cadena de errores conocidos
El número de ocho minutos suena a una ruptura con todo lo que se sabe sobre la seguridad en la nube. La mirada al camino de ataque muestra lo contrario. No hay vulnerabilidad desconocida, ni exploit específico de IA. Cada paso utilizó una configuración errónea documentada.
Credenciales de acceso persistentes estaban en un bucket público. Un rol de ejecución de Lambda tenía permisos de administrador, aunque nunca los necesitó. Un usuario poco autorizado podía sobrescribir código de funciones ajenas. Estos tres errores, cada uno por separado, forman la cadena. Cada uno es conocido desde hace años y aparece en cada guía de endurecimiento de AWS.
La IA aceleró y automatizó el ataque. No lo permitió; quien lo lea como prueba de que la IA hace la nube insegura, se equivoca de causa. Y esa es la parte donde la defensa puede actuar. La causa es reparable, sin necesidad de contramedidas de IA.
¿Por qué el número de minutos desorienta?
Un segundo dato contextualiza la situación. 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, fechado el 23 de marzo, aparece una frase que contradice el pánico: se debe mirar el 2025 no como el año en que los ataques surgieron directamente gracias a la IA.
Los números lo respaldan. La mediana de la permanencia de un atacante en la red se elevó a 14 días en 2025, frente a 11 del año anterior. En el 52 por ciento de los casos, las empresas detectaron la intrusión por sí mismas. Las vulnerabilidades explotadas siguen siendo la vía de entrada más frecuente, con un 32 por ciento, por sexto año consecutivo. La mayoría de los ataques siguen occurring en escalas de días y semanas.
El caso de los ocho minutos es real, pero representa una excepción, no la media. Ocurrió tan rápido porque las condiciones fueron ideales. Para los defensores, esa es la buena noticia: quien elimine esas condiciones priva al ataque veloz de su fundamento.
Cinco pasos que ahora endurecen las cuentas de AWS
Ningún parche de fabricante soluciona el problema, porque está en la configuración. Exactamente allí se puede arreglar. La lista está ordenada por impacto.
- Eliminar claves persistentes. En lugar de claves IAM permanentes, deben usarse roles de corta duración y credenciales temporales en el entorno de producción. Una clave comprometida que se vuelve inútil después de una hora ya no abre ninguna puerta.
- Separar al administrador de los roles de ejecución. Ninguna función Lambda necesita privilegios de administrador para cumplir su tarea. Cada rol de ejecución recibe exactamente los permisos necesarios para su función, nada más.
- Encontrar buckets públicos. Los buckets S3 con datos de entrenamiento terminan fácilmente en la red por accidente. Un escaneo regular en busca de buckets abiertos y las credenciales que contienen cierra la vía de acceso más común.
- Proteger Bedrock mediante una política de control. Las políticas de control de servicios limitan quién puede iniciar servicios de IA costosos y recursos GPU. Esto limita el daño si una cuenta se ve comprometida.
- Monitorear el tiempo de ejecución. Nuevos usuarios administradores, llamadas extrañas a Bedrock y GPU que se inician de repente son señales claras. Quien los detecta en tiempo real detiene el ataque en pleno curso.
Configuración errónea frente a un entorno endurecido
La diferencia entre la cuenta de ocho minutos y un entorno seguro no está en una nueva herramienta. Está en configuraciones predefinidas que hay que conocer y aplicar.
| Aspecto | Caso vulnerable | Configuración endurecida |
|---|---|---|
| Clave de acceso | larga duración, en el balde abierto | roles de corta duración |
| Rol de ejecución de Lambda | derechos de administrador | solo derechos de función |
| Baldes de S3 | público con credenciales | privado, escaneado regularmente |
| Efecto de una clave filtrada | camino al admin de la cuenta | sin valor después de una hora |
Qué pueden aprender los equipos del caso
La polémica sobre los ocho minutos distrae del hallazgo real. El ataque fue veloz porque faltó la higiene básica. Credenciales temporales, roles concedidos con mesura y la inspección de cubos abiertos habrían detenido la cadena en cualquier punto. Estas acciones son antiguas, poco llamativas y eficaces.
Un detalle debería alertar a los defensores. Sysdig advierte que las huellas de IA maliciosa en el código pronto desaparecerán. Los mejores agentes no dejan comentarios serbios ni inventan números de cuenta. La ventana para detectar un ataque impulsado por IA en el código se estrecha. Queda el endurecimiento, que ya hoy frena cada uno de esos pasos.
Preguntas frecuentes
¿Qué es LLMjacking?
En el LLMjacking, los atacantes usan accesos a la nube robados para ejecutar modelos de lenguaje costosos a través de servicios como Amazon Bedrock. La factura la paga la víctima. En el caso de Sysdig, el atacante tomó modelos ajenos y además lanzó una instancia de GPU a costa ajena.
¿Proviene el número de ocho minutos de Google o de GTIG?
No. El caso concreto de los ocho minutos proviene del equipo de seguridad de Sysdig. El informe de Mandiant de Google, M‑Trends 2026, proporciona la información y menciona una permanencia mediana de 14 días. Ambas fuentes juntas ofrecen la imagen completa.
¿Hubo una vulnerabilidad desconocida?
No. El ataque utilizó exclusivamente configuraciones erróneas: claves persistentes en un bucket S3 abierto y una función Lambda con permisos de administrador. No estuvo involucrado ningún Zero‑Day, ni se requiere un parche.
¿Cuál es el paso de protección más rápido?
Reemplazar claves IAM persistentes por roles efímeros y no asignar permisos de administrador a ninguna función Lambda de ejecución. De este modo, el ataque observado carece tanto de punto de entrada como de escalada a administrador.
RECOMENDACIONES DE LA REDACCIÓN
Fuente de la imagen: generada por IA (Juli 2026)
