Cloud13 min · avançado · atualizado 2026-06-29

Superfície de ataque em Cloud (AWS / GCP / Azure)

IAM, buckets, metadata service, chaves vazadas e movimentação lateral entre serviços gerenciados. Onde os atacantes ganham e o que monitorar.

🎧 audiobook · nível 1

1/1vozvel

nível 1 · introdução acessívelnível 2 · em brevenível 3 · em breve

Quase todo incidente sério em cloud nos últimos anos começou por um destes: chave de longa duração vazada, bucket público, role com '*' excessivo, ou SSRF que alcança o metadata service da instância.

Reconhecimento autorizado

# Enumeração de buckets S3 por permutação de nome
cloud_enum -k empresa --quickscan

# Análise de permissões IAM da sua própria conta (auditoria)
prowler aws --compliance cis_2.0_aws

# GCP
scout suite gcp --service-account key.json

# Azure
ROADtools roadrecon auth -d alvo.onmicrosoft.com

Os 5 vetores que mais aparecem

Access keys em repositório público (Trufflehog/GitGuardian acham em segundos).
Buckets S3/GCS com ACL pública por engano.
EC2/GCE com SSRF na aplicação → metadata service → roubo de credenciais temporárias.
Roles IAM com 'iam:PassRole' permissivo → escalada para administrador.
Backups, snapshots e AMIs compartilhados com 'all'.

Metadata service v1 ainda mata

Em AWS, force IMDSv2 (hop-limit=1). Em GCP, use o header Metadata-Flavor obrigatório (padrão). Em Azure, restringir saída para 169.254.169.254 quando possível.

Detecção mínima viável

CloudTrail/Audit Logs centralizados, retenção mínima 90 dias, alarmes em ConsoleLogin sem MFA.
GuardDuty / Security Command Center / Defender for Cloud ativos.
Rotação obrigatória de chaves > 90 dias, ou eliminação em favor de OIDC federation.
SCP/Org Policies bloqueando regiões não usadas e criação de usuário IAM.

Referências

Template OffSec · aplicar antes de rodar

Objetivo → Preparação → Execução → Evidência → Ética

→ guia do lab

Objetivo

Encontrar má configuração em recursos cloud (buckets, IAM, metadata, chaves expostas) sem sair do escopo autorizado.

Pré-requisitos

Conta cloud de teste (AWS free-tier / GCP sandbox)
aws-cli/gcloud/az configurados com credenciais dedicadas ao teste
ScoutSuite, Prowler ou CloudSploit para auditoria

Passos

Inventário: listar recursos por região usando credenciais de teste
Auditar buckets/objetos públicos e políticas IAM permissivas
Checar chaves em repos, secrets em variáveis de ambiente e metadata endpoint
Simular escalonamento (assume-role) apenas em conta de teste
Consolidar achados em relatório com severidade CVSS-like

Evidências a coletar

Relatório JSON do Prowler/ScoutSuite
Screenshot da política IAM problemática
Comando reproduzido + saída (redigida para remover ARNs sensíveis)

Regra prática: se você não guardou evidência reprodutível, o achado não existe.

Guia prático (lab autorizado)

alvo · Sua própria conta AWS sandbox (nunca de terceiros sem contrato)

prowler aws -c iam_password_policy,s3_bucket_public_access -M json

verificar · Reproduza o achado manualmente com aws-cli antes de reportar. Auditoria automática erra — humano confirma.

Checklist interativo

Checklist ético (marcar antes do primeiro comando)

Autorização, escopo, lab e proteção de dados. Sem 100%, não roda fora do lab.

0/5

01Autorização escrita e assinada (escopo, janela, contatos)Sem papel, não roda. Pede ao dono do sistema um e-mail formal listando IPs/hosts, horários e ponto focal.
02Escopo confirmado — só o que está na lista é alvoFora do escopo = fora do teste. Se descobrir algo interessante fora, documenta e para.
03Rodei tudo antes num lab isolado (Docker/VM host-only)
04Tenho plano de rollback e canal direto se algo quebrar
05Não vou exfiltrar/gravar PII real além do mínimo para provaLGPD: só o suficiente para evidenciar o achado. Mascara o resto.

Prática segura · Cloud

→ guia do lab

Monte um ambiente isolado antes de qualquer teste — use Docker (DVWA/juice-shop), uma VM host-only ou um alvo autorizado (HTB, TryHackMe, PortSwigger Academy).

Nunca aponte para alvo em produção. Se estiver no celular, use proot-distro + Debian para não sujar o Termux principal.