AWS Builder Center

Builder Center

El Puzzle de AWS: De IMDSv2 a la trampa de CloudTrail por $0 USD (Parte 2: La Defensa)

El Puzzle de AWS: De IMDSv2 a la trampa de CloudTrail por $0 USD (Parte 2: La Defensa)

Cuando un descuido abre una brecha en la nube, la solución no es gastar de más sino entender la arquitectura. En esta segunda entrega remediamos el ataque de la Parte 1 forzando IMDSv2, eliminamos las llaves SSH por Session Manager y te muestro la lección que compartí en vivo en el AWS Community Day Perú 2026: por qué tus descargas confidenciales en S3 no se guardan en CloudTrail por defecto y cómo auditar tu infraestructura a costo $0 USD.

Series: El Puzzle de Descuidos en AWS (Nivel 100: Fundamentos) (2 articles)

  1. 1
    El Puzzle de AWS: ¿A poco con un simple curl se puede comprometer una cuenta? (Parte 1: El Ataque)
  2. 2
    El Puzzle de AWS: De IMDSv2 a la trampa de CloudTrail por $0 USD (Parte 2: La Defensa) This article

Roberto Flores Segundo

Líder AWS UG Playa Vicente | Seguridad Cloud, Cumplimiento y Respuesta a Incidentes

De la alerta a la remediación: blindar sin romper producción

En la primera parte de esta serie vimos el vector de ataque que presenté en el AWS User Group Minatitlán: cómo un comando curl bien dirigido podía comprometer una instancia EC2 aprovechando una vulnerabilidad en una aplicación web, consultar metadatos internos para robar credenciales temporales y escalar privilegios con el rol de IAM, abriendo la puerta a todo lo que ese rol permitía en la cuenta: desde acceder a servicios internos hasta descargar una factura confidencial en Amazon S3. En un laboratorio controlado es un ejercicio ilustrativo, pero en un entorno real representa un incidente de seguridad grave.
Para abordar la parte defensiva con una arquitectura modular, preparé una implementación con AWS CDK que presenté recientemente en el AWS Community Day Perú 2026 (Lima / Virtual). En esa sesión me enfoqué en cómo neutralizar este tipo de riesgos desde la propia infraestructura y en revisar qué registros de auditoría quedan realmente guardados en la cuenta.
Nota sobre esta serie:
Este artículo es la Parte 2 de una serie sobre seguridad y auditoría práctica en AWS (en la primera entrega vimos cómo se ejecutaba el ataque con curl y en la siguiente entrega analizaremos la postura de seguridad web en AWS). Sin embargo, esta guía defensiva está pensada para que puedas leerla, entenderla y aplicarla de forma 100% independiente en tu propia cuenta.
Hoy nos colocamos del lado defensivo (Blue Team). El reto que me propuse al diseñar este laboratorio fue directo: ¿cómo remediamos esta brecha desde la propia infraestructura de AWS, sin romper servicios en funcionamiento y manteniéndonos dentro de la capa gratuita ($0 USD)?
Veamos el camino paso a paso, desde el servidor hasta los registros de auditoría.

1. Blindar el cómputo: ¿arreglar la página web o blindar la nube?

Cuando vimos que el atacante utilizaba la aplicación web para consultar las credenciales temporales de la máquina, el primer impulso suele ser corregir el código: "abro el archivo de Python y agrego una validación para rechazar la IP 169.254.169.254".
Esto soluciona el problema puntual en ese endpoint. Pero en arquitecturas reales debemos hacernos una pregunta más profunda: ¿qué ocurre si mañana se despliega otro microservicio en la misma máquina y se omite esa validación? ¿O qué pasa si una dependencia externa instalada presenta una vulnerabilidad no identificada?
El principio fundamental en la nube es que la infraestructura debe protegerse a sí misma, independientemente de los fallos que puedan existir a nivel de código web. Y en AWS, el mecanismo nativo para mitigar este vector es IMDSv2.
Captura de la consola de AWS EC2 en la ventana de configuración de metadatos de la instancia, mostrando el parámetro HttpTokens configurado en Required.
Blindaje a nivel de infraestructura: forzar IMDSv2 en la instancia EC2 para neutralizar peticiones SSRF no autorizadas.

¿Cómo neutraliza el ataque IMDSv2?

Todas las instancias EC2 cuentan con el servicio interno de metadatos (IMDS), que permite a las aplicaciones consultar información sobre su propia configuración y obtener credenciales temporales asociadas a su rol de IAM.
En la versión anterior (IMDSv1), el servicio respondía a solicitudes GET simples sin autenticación previa. Si una aplicación web vulnerable realizaba una petición interna hacia 169.254.169.254, el servicio entregaba los tokens de seguridad a quien los solicitara. Por eso el ataque con SSRF funcionó en la primera entrega.
IMDSv2 cambia este comportamiento al exigir una sesión orientada a tokens:
  1. Primero, el cliente debe enviar una petición HTTP PUT con un encabezado especial (X-aws-ec2-metadata-token-ttl-seconds) para solicitar un token de sesión de corta duración.
  2. Posteriormente, utiliza ese token en el encabezado de cada petición GET sucesiva.
¿Por qué esto detiene el ataque de raíz? Porque una vulnerabilidad web SSRF estándar únicamente puede forzar al servidor a realizar peticiones GET simples. No tiene la capacidad de inyectar encabezados personalizados ni de ejecutar el flujo PUT previo para obtener el token. La petición es rechazada de inmediato con un código HTTP 401 Unauthorized.
Para forzar IMDSv2 en tu instancia desde la terminal:
1
2
3
4
aws ec2 modify-instance-metadata-options \
--instance-id <ID-DE-TU-INSTANCIA> \
--http-tokens required \
--http-put-response-hop-limit 1
El propósito de estos dos parámetros: --http-tokens required: Exige el uso obligatorio de tokens de sesión. Cualquier petición que intente usar IMDSv1 queda rechazada automáticamente. --http-put-response-hop-limit 1: Define que la respuesta del token solo puede viajar 1 salto de red. Si la aplicación corre dentro de un contenedor en la máquina, el paquete no puede cruzar el puente de red hacia el contenedor, evitando que aplicaciones aisladas puedan solicitar tokens del host anfitrión.

Validar en caliente: la prueba de fuego

En seguridad y auditoría nunca asumimos que algo quedó protegido solo por marcar una casilla o ejecutar un comando. Hay que validar volviendo a probar el vector de ataque.
En nuestro script interactivo ./redteam (Opción 6 - Modo Blue Team), tras forzar IMDSv2 y activar S3 Block Public Access, volvemos a lanzar las pruebas:
  1. Prueba contra IMDSv2: Lanzamos la petición SSRF buscando el rol en 169.254.169.254. La instancia responde HTTP 401 Unauthorized. La aplicación web mantiene el fallo en su código, pero a nivel de infraestructura la extracción de credenciales quedó completamente bloqueada.
  2. Prueba contra S3: Intentamos descargar el archivo confidencial con curl -I. Amazon S3 devuelve HTTP 403 Forbidden. El candado global bloquea la descarga anónima aunque la política del bucket permita lectura pública.

El dilema en producción: ¿por qué no todas las empresas activan IMDSv2 de inmediato?

En guías y laboratorios se lee sencillo: "activa IMDSv2 como obligatorio". Pero en entornos corporativos reales este cambio requiere evaluar dependencias para evitar interrupciones en producción:
  • Sistemas heredados (Legacy): Si una organización cuenta con software desarrollado con versiones antiguas del SDK de AWS (Java SDK v1, Python boto2 o librerías heredadas de PHP), esas versiones no implementan el flujo de tokens en dos pasos. Forzar IMDSv2 sin validar provocará que la aplicación no pueda renovar credenciales y el servicio se detenga.
  • Estrategia de mitigación segura:
    1. Monitoreo previo con CloudWatch: Revisa la métrica MetadataNoToken. Si el valor se mantiene en cero de forma constante, es seguro forzar IMDSv2. Si registra llamadas, aún existen procesos que requieren actualización de SDK.
    2. Controles a nivel de sistema operativo: Si temporalmente no puedes forzar IMDSv2, puedes configurar reglas en el firewall interno de Linux (iptables) para impedir que el usuario del servidor web (www-data) acceda a 169.254.169.254, permitiendo el acceso únicamente a los procesos autorizados del sistema.
    3. Principio de menor privilegio: El rol de IAM asignado a la instancia nunca debe contener permisos de administrador (*). Al limitar los permisos a lo estrictamente necesario, el impacto de una eventual filtración se reduce al mínimo.

La auditoría de metadatos en 5 segundos (a costo $0 USD)

En los manuales oficiales te dicen: "Detectar instancias con IMDSv1 se resuelve activando la regla de AWS Config ec2-imdsv2-check". En el papel suena perfecto.
Pero seamos sinceros: en una pequeña empresa, en una startup o en tu proyecto personal, ¿realmente tienes AWS Config encendido en todas las regiones, o lo apagaste el primer mes para que no te infle la tarjeta de crédito?
AWS Config es una herramienta muy potente, pero no es la única opción. Si no tienes presupuesto para tenerlo activo 24/7, puedes auditar qué máquinas tienen IMDSv1 permitido en 5 segundos y a costo $0 USD con un solo comando en tu terminal:
1
2
3
4
aws ec2 describe-instances \
--filters Name=metadata-options.http-tokens,Values=optional \
--query 'Reservations[*].Instances[*].[InstanceId, State.Name, Tags[?Key==`Name`].Value|[0]]' \
--output table
En la nube no existe una sola verdad absoluta: hay equipos que prefieren bloquearlo desde la raíz con Service Control Policies (SCP) en AWS Organizations, o auditarlo con herramientas de código abierto como Prowler. Lo importante es verificar tus entornos sin depender de herramientas que no puedas costear.

2. Blindar el acceso: migrar del Puerto 22 a AWS Systems Manager

Una vez que la instancia está blindada contra la extracción de metadatos, el siguiente descuido habitual está en cómo nos conectamos a ella para administrarla.
Un error frecuente al iniciar en AWS es abrir el puerto 22 (SSH) a 0.0.0.0/0 en el Security Group con la intención de acceder desde cualquier lugar, manteniendo llaves privadas .pem almacenadas en la computadora local.
Este enfoque presenta riesgos operativos graves: cualquier servicio expuesto al puerto 22 recibe constantes escaneos automatizados, y el extravío o filtración accidental de una llave privada en un repositorio puede comprometer el servidor.
La alternativa recomendada y disponible sin costo adicional es AWS Systems Manager (Session Manager). En lugar de exponer puertos o administrar llaves SSH, la conexión se realiza de forma autenticada mediante la consola web o el AWS CLI:
1
aws ssm start-session --target <ID-DE-TU-INSTANCIA>
Ventajas operativas de Session Manager:
  • Cero puertos de entrada abiertos a Internet: El Security Group no requiere reglas de ingreso para administración.
  • Eliminación de llaves .pem: No se requiere generar ni compartir archivos de llaves privadas.
  • Control centralizado con IAM: El acceso se gestiona mediante identidades de AWS con soporte de autenticación multifactor (MFA).
  • Trazabilidad y auditoría: Cada sesión y comando ejecutado puede registrarse en CloudTrail o CloudWatch Logs.

3. Blindar los datos y los registros: La gran trampa de CloudTrail

Con la máquina protegida y el puerto 22 cerrado sin depender de llaves en la computadora, pasamos a los datos en Amazon S3 y a una creencia muy común: asumir que CloudTrail lo estaba vigilando todo.
Existe la idea extendida de que AWS CloudTrail almacena automáticamente todas las operaciones que ocurren en la cuenta por el simple hecho de estar habilitado.
Esto fue lo que mostré durante la charla del AWS Community Day Perú 2026: tras realizar la descarga de un archivo en Amazon S3, ingresamos a la consola de CloudTrail para buscar el evento GetObject... y el historial no mostró ningún registro.
Consola de AWS CloudTrail mostrando cero resultados al filtrar por el evento GetObject en el historial de eventos predeterminado.
La trampa de CloudTrail: el historial de eventos a costo $0 USD solo registra Management Events; auditar descargas en S3 requiere activar Data Events.
La razón técnica radica en la distinción que realiza CloudTrail entre tipos de eventos:
  • Eventos de administración (Management Events): Creación de instancias, modificaciones en Security Groups o eliminación de roles. Vienen habilitados por defecto en el historial de eventos y son gratuitos durante los últimos 90 días.
  • Eventos de datos (Data Events): Operaciones a nivel de objetos en Amazon S3 (GetObject, PutObject). No vienen activos por omisión por una razón de costos y escala: imagina una plataforma de comercio electrónico o un sitio con alto tráfico donde se descargan millones de imágenes por hora; si CloudTrail registrara cada descarga individual, la factura y el almacenamiento se dispararían en un solo día.
Si un tercero descarga información confidencial con curl, el historial gratuito a costo $0 USD no registrará qué objetos fueron leídos.
En auditoría y cumplimiento normativo (ISO 27001 o SOC 2) la evidencia documentada es la base del control. La estrategia no es activar Data Events en toda la cuenta a ciegas, sino hacerlo de forma selectiva en los buckets críticos:
  1. Buckets con respaldos (backups del sistema o bases de datos).
  2. Buckets con facturación, contratos o información confidencial.
  3. Si requieres monitoreo activo, configurar disparadores (triggers de eventos con Amazon EventBridge o notificaciones de S3) para alertar sobre accesos sospechosos.
Eso sí, hay que tener claro el aspecto financiero: los Data Events en CloudTrail son una función de pago (tienen un costo por cada 100,000 eventos registrados). Por eso, en proyectos de estudio o pruebas controladas, debes activarlos únicamente mientras realizas la auditoría y recordar apagarlos al finalizar para mantener tu cuenta en cero.

4. De parchear a diseñar: Los 4 puntos ciegos con AWS CDK

Parchear una instancia en caliente y ajustar reglas a mano resuelve una urgencia. Pero en un entorno profesional el objetivo como Blue Team es diseñar arquitecturas seguras por defecto utilizando Infraestructura como Código (IaC).
Para la sesión en vivo en Perú, desarrollé un laboratorio modular con AWS CDK (TypeScript) (repositorio oficial en GitHub ) donde abordamos los 4 puntos ciegos más habituales en la nube:
  1. IAM con Menor Privilegio: En lugar de credenciales estáticas o roles permisivos con *, la aplicación solo tiene autorizada la acción s3:PutObject delimitada al prefijo de subida. (Hoy en día herramientas open source de AWS Labs como IAM Policy Autopilot permiten generar estas políticas analizando el código de la aplicación).
  2. Perímetro de Red Multinivel: Combinación de Security Groups (firewall con estado a nivel de interfaz) con Network ACLs (filtrado sin estado a nivel de subred) para aplicar bloqueos inmediatos de direcciones IP sospechosas mediante reglas DENY.
  3. Amazon S3 Privado + URLs Prefirmadas (STS SigV4): Para entregar archivos confidenciales (como PDFs o certificados), el bucket permanece 100% privado. La aplicación solicita un pase temporal a AWS STS con firma SigV4 y caducidad de 15 minutos.
  4. Auditoría con CloudTrail: Aprovechamiento del historial de 90 días para auditar qué identidades o roles ejecutaron cambios en la infraestructura.

5. Cómo replicar, observar o destruir el laboratorio ($0 USD)

Para que puedas aprender a tu propio ritmo y según tus posibilidades, pongo a tu disposición tres opciones:

Opción A: Replicar el vector de ataque y la remediación (CloudFormation)

Si quieres recrear el ataque de la Parte 1 y aplicar la defensa en caliente con el menú interactivo:
1
2
3
git clone https://github.com/Siegfried-FS/lab-red-team.git
cd lab-red-team
./redteam
(Usa la Opción 6: Modo Blue Team para forzar IMDSv2 y validar el bloqueo del SSRF).

Opción B: Desplegar la Arquitectura Segura de la Charla (AWS CDK)

Si prefieres desplegar con infraestructura como código la aplicación modular presentada en el AWS Community Day Perú 2026:
1
2
3
git clone https://github.com/Siegfried-FS/aws-cloud-security-lab.git
cd aws-cloud-security-lab
./cloudsec
Portada oficial de las diapositivas de la charla 'Tu App ya Corre en AWS... pero ¿Realmente es Segura?' presentada en el AWS Community Day Perú 2026 por Roberto Flores Segundo.
Ponencia oficial en el AWS Community Day Perú 2026: arquitectura segura en AWS CDK, mitigación de puntos ciegos y demo en vivo.
Descarga las diapositivas oficiales de la charla:
Puedes consultar o descargar el material visual en PDF utilizado en la sesión de Lima/Virtual directamente desde el repositorio: AWSCommunityDayPeru2026_RobertoFlores.pdf en GitHub .

Opción C: Para aprender sin instalar nada ni crear cuentas de AWS

A veces no tenemos una tarjeta bancaria a la mano para registrar una cuenta en AWS, estamos en una computadora donde no podemos instalar herramientas, o simplemente queremos entender el concepto visualmente antes de tocar una terminal.
Para que nadie se quede con las ganas de aprender, grabé 8 videos cortos de pantalla directamente en la consola de AWS (sin costo, sin registro y sin instalaciones). Puedes abrirlos en el navegador y ver qué pasa tras bambalinas:
  • Cómo brinca la advertencia de AWS al abrir un Security Group a 0.0.0.0/0.
  • Cómo funciona una URL prefirmada de S3 con STS SigV4 en vivo.
  • Cómo se aplica el bloqueo de una IP sospechosa con Network ACLs.
  • Cómo auditar eventos en CloudTrail y validar que la cuenta quede limpia en $0 USD.
  • Ver los 8 videos demostrativos paso a paso en GitHub 

Presupuesto Real y Validación de Costos

  • Costo en AWS: $0.00 USD. Ambos laboratorios corren bajo el AWS Free Tier (1 instancia t2.micro y pocos kilobytes en S3).
  • Destrucción limpia: El script ./scripts/destroy.sh (en lab-red-team) o ./cloudsec opción destruir (en aws-cloud-security-lab) eliminan los recursos automáticamente.
Una lección indispensable sobre costos y auditoría:
"El script en la terminal puede mostrarte un mensaje en verde muy bonito diciendo que ya terminó y que la cuenta está limpia. Pero jamás te quedes solo con lo que dice un script: entra siempre a la consola web de AWS o consulta con el CLI para validar con tus propios ojos que las instancias realmente estén en estado 'Terminated'. Si un volumen EBS o una IP elástica queda huérfana por algún fallo silencioso, AWS te la seguirá cobrando a fin de mes."
Captura de dos fases: Fase 1 mostrando el desmantelamiento automatizado con vaciado de S3 y cierre de CloudFormation, y Fase 2 validando con AWS CLI que la instancia EC2 está en estado terminated.
Validación de costos en auditoría: desmantelamiento automatizado y verificación en AWS CLI confirmando el estado Terminated para garantizar costo cero ($0 USD).

Las preguntas que me tuve que hacer...

Para cerrar esta entrega, no quiero dejarte un cuestionario de examen. Prefiero compartirte las preguntas honestas que yo mismo me tuve que hacer cuando empecé a auditar mis propios entornos y laboratorios:
  1. ¿Qué tipo de vulnerabilidad en mi aplicación o mala configuración en la red podría exponer mi servidor y permitir que alguien alcance la IP de metadatos 169.254.169.254? Durante años IMDSv1 vino habilitado por defecto y muchas plantillas o AMIs aún lo permiten como opcional. Si un fallo de código como SSRF ocurre, forzar IMDSv2 en la infraestructura es lo único que impide la extracción de credenciales.
  2. ¿En cuántos proyectos asigné permisos excesivos con * a un rol de IAM por la prisa de que la app funcionara sin errores? Hoy ni siquiera tenemos que inventar políticas a ciegas: herramientas open source como IAM Policy Autopilot de AWS Labs o IAM Access Analyzer permiten generar políticas con el menor privilegio analizando el código o las llamadas reales.
  3. ¿Realmente asumí que CloudTrail registraba todo lo que ocurría en mi cuenta? En el laboratorio quedó demostrado: el historial gratuito a costo $0 USD solo guarda eventos de gestión. Si alguien descarga archivos confidenciales de S3, sin Data Events activos la extracción ocurre en total silencio.
  4. ¿Por qué seguimos arrastrando llaves .pem en nuestras laptops si en cada charla y meetup recordamos que es una mala práctica? Abrir el puerto 22 a 0.0.0.0/0 y guardar archivos de llaves privadas en computadoras personales es un riesgo innecesario cuando AWS Systems Manager (Session Manager) nos da acceso seguro, autenticado por IAM y 100% auditable sin exponer puertos.
En la seguridad, como en la comunidad, nadie nace sabiéndolo todo. Reconocer estos descuidos en nuestros propios proyectos es el verdadero primer paso para construir arquitecturas más sólidas, limpias y transparentes.
¿Te ha tocado toparte con alguno de estos descuidos en tus propios despliegues o en casos que te tocó vivir? Me encantaría leer tu experiencia y reflexiones en los comentarios.

El Puente a la Parte 3: ¿Qué pasa cuando expones tu sitio web?

Ya vimos cómo blindar la infraestructura a nivel de cómputo, almacenamiento e identidades (EC2, S3 e IAM). Pero la seguridad no termina en el servidor ni en las políticas de acceso.
¿Qué ocurre cuando publicas aplicaciones web o sitios comunitarios en servicios administrados como AWS Amplify?
En la Parte 3 analizaremos un punto ciego muy habitual: por qué tantos proyectos en producción reprueban las evaluaciones de seguridad web por omisiones en la capa de entrega, qué obstáculos reales existen al intentar alcanzar una calificación alta y cómo abordar esta postura desde la perspectiva de un auditor.
#content-creators-latam #AWS #Seguridad #Comunidad #BlueTeam #Auditoria
# security# compliance# architecture# best-practices# cybersecurity

Series: El Puzzle de Descuidos en AWS (Nivel 100: Fundamentos) (2 articles)

  1. 1
    El Puzzle de AWS: ¿A poco con un simple curl se puede comprometer una cuenta? (Parte 1: El Ataque)
  2. 2
    El Puzzle de AWS: De IMDSv2 a la trampa de CloudTrail por $0 USD (Parte 2: La Defensa) This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article