Cloud / AWS: el fallo casi nunca es un exploit — es la configuración
La mayoría de brechas cloud son malas configuraciones y permisos excesivos, no exploits. Aquí entiendes el modelo de responsabilidad compartida, IAM/S3/roles, cómo se usa awscli y los fallos que de verdad se explotan (S3 público, credenciales filtradas, SSRF→IMDS, IAM) — con 2 labs gratis y 4 retos para practicarlo sin gastar un euro.
☁La nube no es “el ordenador de otro”: es un modelo de responsabilidad compartida
El error mental nº1 en cloud. AWS/Azure/GCP protegen la infraestructura; tú eres responsable de cómo la configuras. La mayoría de brechas cloud no son "hackeos a AWS": son fallos de configuración del cliente.
| De AWS (la nube) | hardware, red física, hipervisor, servicios gestionados. No es tu problema. |
| Tuyo (en la nube) | permisos IAM, buckets públicos, security groups, cifrado, secretos, parcheo de tus instancias. |
| Dónde se rompe | S3 público, credenciales en código/repos, IAM demasiado amplio, IMDS sin proteger, security groups abiertos a 0.0.0.0/0. |
Regla: en cloud casi nunca atacas un exploit; atacas una mala configuración y unos permisos excesivos.
🔑El vocabulario que necesitas (IAM, S3, roles, STS)
| IAM | quién puede hacer qué. Usuarios, grupos, roles y políticas (JSON con Allow/Deny). |
| Clave de acceso | AKIA... (usuario) o ASIA... (temporal, de rol/STS) + secret key. Si se filtran, es acceso directo. |
| Rol | identidad que asume una máquina o servicio para obtener credenciales temporales sin guardar claves. |
| S3 | almacenamiento de objetos (buckets). El servicio que más datos filtra por dejarlo público. |
| STS / sts:get-caller-identity | el whoami de AWS: te dice qué identidad eres con unas credenciales. |
| SSM / Secrets Manager | donde se guardan parámetros y secretos. Objetivo típico tras conseguir credenciales. |
🧰awscli: tu herramienta principal (y el truco del endpoint)
Todo se hace con aws. El truco para practicar gratis y sin cuenta: apuntar el CLI a un AWS emulado en local (moto/LocalStack) con --endpoint-url. La sintaxis es idéntica a la real.
El --no-sign-request = "sin credenciales". Si eso te lista o descarga algo, el bucket está público — el fallo cloud más común del mundo.
⚔Los fallos que vas a explotar (y ver en la vida real)
public-read o ACL abierta: cualquiera lista y descarga. Enuméralo con --no-sign-request.AKIA... en código, repos, buckets, variables, histórico de git. Con ellas entras como ese usuario.http://169.254.169.254/... y robar las credenciales del rol. Mitiga con IMDSv2.*, iam:PassRole, iam:CreatePolicyVersion... permiten escalar a admin. Enuméralo antes de atacar.ssm get-parameter y secretsmanager get-secret-value suelen soltar oro.0.0.0.0/0: superficie directa a internet.🔧El arsenal cloud
| awscli | el CLI oficial. Todo pasa por aquí: S3, IAM, SSM, STS. Con --endpoint-url para los labs. |
| ScoutSuite | audita una cuenta entera (multi-cloud) y saca un informe HTML de malas configuraciones. |
| Prowler | cientos de checks de seguridad y cumplimiento (CIS) sobre AWS/Azure/GCP. |
| Pacu | el 'Metasploit de AWS': framework de explotación y escalada de privilegios post-credencial. |
| cloud_enum / S3Scanner | buscan buckets y recursos públicos por nombre de empresa. |
| moto / LocalStack | emulan AWS en local para practicar gratis (moto es 100% libre). |
🎯🎯 Labs puntuables: Cloud roto
Dos laboratorios gratis y locales (AWS emulado con moto, 0 €) y 4 retos · 150 puntos:
| Lab 1 · Bucket → creds → SSM | enumeras un S3 público sin credenciales, sacas unas claves filtradas y pivotas al secreto de producción en SSM. |
| Lab 2 · SSRF → IMDS → S3 | la cadena de Capital One: SSRF en una web → robas las credenciales del rol en el metadato → lees el bucket de secretos. |
⬇ Pack Lab 1 (cloud-s3) ⬇ Pack Lab 2 (cloud-ssrf) ▶ A los retos · categoría “Cloud · AWS”
Necesitas awscli (ya lo lleva el Kali de la academia) y Docker. Cada lab se levanta con docker-compose up -d y se apaga con docker-compose down.