Solo se necesitaron ocho minutos. Desde cloud expuestos cloud hasta el control administrativo total en AWS, el ataque documentado por Sysdig muestra lo rápido que se puede comprometer un cloud cuando convergen la automatización, el abuso de identidades y cloud permisivos cloud .
Nohubo vulnerabilidades de día cero, malware cadenas de explotación novedosas. El atacante se basó exclusivamente en credenciales válidas, servicios nativos de AWS y la toma de decisiones automatizada para pasar del acceso inicial a los privilegios de administrador a la velocidad de una máquina.
Durante las últimas semanas, hemos analizado el comportamiento inicial de los agentes autónomos de IA, cómo comenzaron a interactuar e influirse mutuamente dentro de entornos compartidos, y cómo se formó rápidamente una coordinación sin la intervención de los seres humanos.
Este incidente muestra lo que ocurre cuando esas dinámicas se aplican a un cloud real.
Lo que anticipamos ahora es observable: el reconocimiento se acelera y, una vez que un atacante controla una identidad, controla efectivamente el entorno. El resultado no es un nuevo tipo de ataque, sino uno mucho más rápido.
Este análisis detalla paso a paso la intrusión, destacando dónde se aceleró el ataque, dónde podrían haber intervenido de forma realista los defensores y por qué la detección basada en el comportamiento y centrada en la identidad es ahora la única forma viable de detener cloud que se mueven a la velocidad de la IA.
Cuando la automatización colapsa la línea temporal del ataque
Este incidente destaca porque la IA eliminó la fricción. El atacante no investigó con cautela ni encadenó vulnerabilidades. La automatización le permitió enumerar servicios, evaluar rutas de privilegios y ejecutar la escalada más rápido de lo que un operador humano podría hacer manualmente.
Para los defensores, la mayoría de las acciones implicadas parecerían legítimas si se analizaran de forma aislada. Las llamadas a la API se autenticaron, se accedió a los servicios a través de mecanismos aprobados y se abusó de los permisos, no se eludieron.
La única señal fiable era el comportamiento: quién actuaba, con qué rapidez se movían y qué secuencia de acciones se desarrollaba en los distintos servicios.
Flujo de ataque de alto nivel
A grandes rasgos, la intrusión se desarrolló en cinco fases:
- Acceso inicial a través de activos expuestos
- Reconocimiento entre servicios
- Escalada de privilegios mediante el abuso de Lambda
- Persistencia y expansión
- Abuso de recursos y externalización de datos
Aunque la secuencia completa implicaba muchos pasos individuales, solo un subconjunto era crítico para el éxito. Si esos pasos se detectan o se detienen, el ataque fracasa por completo.
Fase 1: Acceso inicial a través de Cloud expuestos Cloud
¿Qué pasó?
El ataque comenzó fuera de la cuenta de AWS y no estaba dirigido a una organización específica.
El atacante buscó buckets S3 de acceso público utilizando convenciones de nomenclatura comúnmente asociadas con herramientas de IA y cloud . Cualquier entorno AWS que siguiera esas convenciones era un punto de entrada potencial.
Dentro de uno de los buckets, el atacante encontró archivos que contenían claves de acceso IAM. Con esas credenciales válidas, se autenticó directamente en la cuenta AWS de la víctima.
Desde la perspectiva de AWS, una identidad válida había iniciado sesión correctamente.
Por qué es importante:
Aquí es donde comienzan silenciosamente muchos cloud . Los problemasCloud suelen crear la oportunidad, pero el uso indebido de la identidad determina hasta dónde puede llegar un atacante.
Una vez autenticado, el atacante pasó inmediatamente a la siguiente fase del ataque.
Fase 2: Reconocimiento entre servicios a la velocidad de la máquina
¿Qué pasó?
Tras la autenticación, el atacante llevó a cabo un amplio reconocimiento en múltiples servicios de AWS, incluidos S3, Lambda, EC2, IAM, Bedrock y CloudTrail.
La actividad fue rápida, sistemática y automatizada. Las respuestas de la API se ingestaron y evaluaron en tiempo real para identificar rutas de escalado viables.
Por qué es importante:
El reconocimiento hace posible todo lo que viene después. Sin visibilidad de los servicios, las funciones y la confianza, las vías de escalamiento permanecen ocultas.
Aquí es donde la automatización cambia la ecuación. Las herramientas asistidas por IA permiten a los atacantes recopilar respuestas de API, evaluar permisos e identificar rutas viables en cuestión de segundos.
Para los equipos SOC, esta fase representa la primera oportunidad realista de intervenir. Una vez que comienza la escalada de privilegios, las ventanas de respuesta se reducen drásticamente.
Este comportamiento se ajusta en gran medida a las técnicas documentadas en MITRE ATLAS, en torno al uso indebido de cuentas válidas y el descubrimiento cloud . En lugar de inventar nuevas técnicas, el atacante aceleró comportamientos conocidos mediante la automatización.
Fase 3: El abuso de Lambda como principal punto de estrangulamiento
¿Qué pasó?
El atacante se centró en una función AWS Lambda existente y la utilizó como mecanismo de escalada de privilegios.
En primer lugar, modificaron el código de la función y aumentaron su tiempo de espera de ejecución. Esta Lambda tenía un rol de ejecución con permisos suficientes para crear usuarios IAM y claves de acceso.
A continuación, invocaron la función modificada. Cuando se ejecutó, la función creó nuevas claves de acceso IAM con privilegios administrativos.
Cada paso era legítimo por sí solo, pero en conjunto convirtieron un componente de automatización rutinario en una vía de escalada.
Por qué es importante:
Esta secuencia fue el punto en el que el ataque se volvió irreversible.
Si alguna parte falla, la cadena se rompe. Si la función no se puede modificar, no se puede abusar de ella. Si nunca se ejecuta, no se crean nuevas credenciales. Si se ejecuta pero no puede crear claves de acceso de administrador, el atacante se queda bloqueado.
Las funciones Lambda concentran la automatización y los privilegios de una forma que pocos otros servicios hacen. Las funciones de ejecución suelen ser más amplias de lo previsto. Los cambios en el código son poco frecuentes y se examinan superficialmente. La invocación es esperada y habitual.
Nada en esta secuencia infringe la política de AWS ni provoca un fallo de control evidente. El riesgo solo se hace visible cuando se observa cómo cambió el comportamiento de la función y qué habilitó inmediatamente después.
Este es un patrón recurrente en cloud modernos cloud . Los atacantes no necesitan explotar la infraestructura. La reutilizan.
Fase 4: Escalada programática de privilegios
¿Qué pasó?
Utilizando la función Lambda modificada, el atacante creó nuevas claves de acceso IAM con privilegios administrativos.
Se trataba de una escalada de privilegios sin explotación.
El atacante simplemente utilizó una función de ejecución para realizar acciones que estaba autorizado a realizar, pero no de la forma prevista por sus creadores.
A partir de ese momento, el atacante pasó a ser el propietario efectivo de la cuenta.
Por qué es importante:
Para los defensores, aquí es donde suelen fallar los controles de seguridad tradicionales. Los sistemas de gestión de identidades y accesos aplican políticas, no intenciones.
Una vez que se obtienen privilegios de administrador, la mayoría de los controles desaparecen. Una vez que se obtiene acceso administrativo, el alcance de la respuesta se reduce y la reparación se vuelve significativamente más compleja.
Fase 5: Persistencia y expansión
¿Qué pasó?
Una vez asegurado el acceso administrativo, el atacante se centró en la persistencia.
En concreto, crearon un nuevo usuario IAM y adjuntaron el AdministradorAcceso política, generó claves de acceso adicionales para los usuarios existentes y recuperó secretos de Secrets Manager y SSM Parameter Store.
Cada acción ampliaba el control del atacante y reducía la eficacia de las medidas correctivas. Aunque se revocara una credencial, las demás seguían vigentes.
Por qué es importante:
Esta fase refleja un cambio del acceso a la garantía. El atacante se aseguraba de mantener el control incluso si los defensores respondían.
Una vez más, estas acciones se llevaron a cabo a través de API legítimas utilizando permisos válidos. La diferencia entre el mantenimiento y el compromiso radica exclusivamente en el comportamiento y el momento en que se producen.
Fase 6: Abuso de recursos y externalización de datos
¿Qué pasó?
El atacante se movió para impactar.
Lanzaron una instancia de GPU de gama alta con un grupo de seguridad abierto y expusieron la interfaz JupyterLab.
Invocaron modelos Bedrock y compartieron una instantánea de EBS externamente.
Por qué es importante:
En ese momento, el ataque ya había tenido éxito. Estas acciones revelan claramente la intención del atacante: abuso de recursos, posible filtración de datos y monetización.
Esta etapa se alinea con los patrones discutidos en nuestro episodio de podcast sobre cómo los atacantes se centran en AWS Bedrock, incluyendo LLMjacking, abuso de costes y exposición de datos una vez que se comprometen cloud .
«¿Y si...?»
El ataque documentado se detuvo donde lo hizo porque fue observado, no porque el atacante se quedara sin opciones.
Con acceso administrativo sostenido, el atacante podría haber:
- Persistencia a largo plazo establecida mediante políticas de confianza y roles entre cuentas.
- Modificación de los procesos de CI/CD para introducir código malicioso en la producción.
- Creación de una infraestructura en la sombra que reflejaba las cargas de trabajo legítimas.
- Realizó una exfiltración de datos silenciosa y gradual utilizando instantáneas y replicación.
- Utilizó servicios de IA de forma continua, mezclando el abuso de costes con el uso normal.
- Conectado a cuentas AWS o plataformas SaaS
Ninguna de estas acciones requiere exploits adicionales. Requieren tiempo. Ocho minutos fue solo el punto de partida.
La necesidad crítica de la detección posterior al compromiso
Cuando se produce el impacto, la prevención ya ha fracasado.
El valor defensivo cambia antes en la cadena de ataque, antes de que la escalada de privilegios y la persistencia aseguren el control del atacante.
Aunque la cadena completa de ataque es larga, los defensores pueden centrarse en un conjunto reducido de pasos críticos a lo largo del flujo de ataque:
- Reconocimiento amplio y rápido entre servicios
- Modificación de una función Lambda existente
- Creación programática de acceso de administrador
- Establecimiento de identidades IAM persistentes
- Externalización de datos a través de mecanismos cloud
Se trata de comportamientos que se desvían considerablemente de los patrones de uso normales cuando se observan en secuencia.
El reto es la correlación.
La mayoría de los controles cloud son estáticos por diseño y tienen dificultades con la intención.
En este incidente:
- Las credenciales eran válidas.
- Las API se utilizaron según lo previsto.
- Los permisos existían legítimamente.
La única anomalía fue el comportamiento a lo largo del tiempo.
Esta es la brecha de detección que aprovechan los ataques rápidos asistidos por IA.
Por qué es necesaria la detección basada en el comportamiento y centrada en la identidad
Cuando los ataques se producen a la velocidad de una máquina, la detección debe funcionar al mismo nivel.
Esto requiere comprensión:
- Cómo se comportan normalmente las identidades humanas, mecánicas y agenciales.
- Cómo se accede normalmente a los servicios
- ¿Qué secuencias de acciones son típicas o poco frecuentes?
- Cómo cambia el comportamiento cuando el control pasa a manos del atacante
La detección centrada en la identidad trata cloud , tanto humanas como no humanas y agencias, como la señal principal. La IA conductual modela cómo operan esas identidades en los distintos servicios y entornos.
Cuando se acelera el reconocimiento, cuando cambia el comportamiento de Lambda, cuando se concede un privilegio de forma inesperada, esos cambios se detectan en tiempo real.
Estaes la única forma práctica de interrumpir los ataques antes de que la escalada de privilegios se vuelva irreversible.
Cómo Vectra AI este tipo de ataques
La Vectra AI está diseñada precisamente para este ámbito problemático.
Mediante el análisis del comportamiento de las identidades en los planos cloud , el tráfico de red, la actividad SaaS y cloud , Vectra AI las primeras etapas de los ataques que se basan en accesos válidos y automatización.
En lugar de esperar el impacto, se centra en:
- Patrones de reconocimiento
- Abuso de privilegios
- Movimiento lateral
- Uso indebido de datos
Cuando el acceso administrativo puede verse comprometido en cuestión de minutos, la respuesta automatizada no es opcional. Es la única forma de actuar dentro del estrecho margen de tiempo que hay entre el acceso y la escalada.
Este incidente debería restablecer las expectativas.
Ocho minutos ya no es algo excepcional. Es lo que permite la automatización cuando se abusa de la identidad y las defensas se basan en suposiciones estáticas. La lección no es temer a la IA. Es reconocer que los atacantes ya la están utilizando para comprimir plazos, eliminar dudas y ampliar la toma de decisiones.
Los defensores deben responder de la misma manera: la detección debe basarse en el comportamiento, la cobertura debe centrarse en la identidad y la respuesta debe ser automatizada.
Porque cuando el acceso cloud cae a la velocidad de la IA, no queda tiempo para reconstruir las alertas después de los hechos.