Reconocimiento en cloud

Antes de atacar una infraestructura cloud hay que descubrir qué usa la organización y qué tiene expuesto: qué proveedor, qué recursos públicos (buckets, funciones, APIs), qué dominios apuntan a servicios cloud y qué credenciales han filtrado. Gran parte es recon pasivo (ver Reconocimiento pasivo), pero aquí se orienta específicamente a identificar y enumerar activos cloud.

Identificar el proveedor y los activos

# DNS/CNAME revelan el proveedor
dig CNAME target.com         # *.amazonaws.com, *.azurewebsites.net, *.cloudfront.net...
# rangos de IP de los proveedores (saber si una IP es AWS/Azure/GCP)
# certificados (crt.sh) y fingerprint web (recon-fingerprint)
# cabeceras: Server, x-amz-*, x-azure-*, x-goog-*
curl -sI https://target.com | grep -iE 'amz|azure|goog|cloudfront|server'

Buckets y almacenamiento público (ver Buckets y almacenamiento público)

# patrones de nombres: target-backups, target-dev, target-assets...
# AWS S3
https://<bucket>.s3.amazonaws.com
# Azure Blob
https://<account>.blob.core.windows.net/<container>
# GCS
https://storage.googleapis.com/<bucket>
# herramientas de descubrimiento masivo
cloud_enum -k target        # busca buckets/blobs/GCS por palabra clave
S3Scanner / GrayhatWarfare  # buscadores de buckets públicos

Enumeración de servicios cloud expuestos

# funciones serverless, APIs, apps
*.azurewebsites.net, *.lambda-url..., *.cloudfunctions.net, *.run.app (Cloud Run)
# API Gateway, App Service, etc. -> fingerprint y rutas (recon-content)
# subdominios que apuntan a servicios cloud (recon-subdominios)

Credenciales filtradas (el vector nº1)

# en repos y código (ver recon-code)
trufflehog / gitleaks -> AWS keys (AKIA...), Azure secrets, GCP service account JSON
# patrones
AKIA[0-9A-Z]{16}            AWS Access Key ID
"type": "service_account"   GCP service account key (JSON)
# en .env, logs, dumps, Pastebin

Una AWS key o un service account JSON filtrado es acceso directo — el hallazgo cloud más impactante y frecuente.

Enumeración autenticada (con credenciales)

Si consigues credenciales, enumeras qué eres y qué puedes:

# AWS
aws sts get-caller-identity          # ¿quién soy?
aws iam get-account-authorization-details   # políticas (si permiso)
enumerate-iam / pacu                 # qué permisos tengo realmente
# Azure
az account show ; az ad signed-in-user show
ROADrecon / AzureHound               # enumerar el tenant
# GCP
gcloud auth list ; gcloud projects list

Enumeración de IDs y tenants (sin credenciales)

# AWS Account ID desde un bucket/ARN/error
# Azure tenant: https://login.microsoftonline.com/<dominio>/.well-known/openid-configuration
# validar si un dominio usa Azure/O365 (ver cloud-m365)

Para la defensa

No exponer recursos públicamente por defecto; nombres de bucket no predecibles no es defensa (usar políticas).
Monitorizar filtraciones de credenciales (secret scanning en repos, GitHub push protection).
Reducir la superficie: no dejar funciones/APIs/servicios de dev accesibles; revisar DNS/CNAME que apuntan a cloud.
CSPM/ASM para inventariar activos cloud expuestos continuamente.
Rotar inmediatamente cualquier credencial que haya podido filtrarse.

Checklist de prueba

Identificar el/los proveedor(es) por DNS/CNAME/cabeceras
Descubrir buckets/blobs/GCS (cloud_enum, GrayhatWarfare)
Enumerar servicios serverless/apps/APIs expuestos
Buscar credenciales filtradas (trufflehog/gitleaks)
Con credenciales: identidad y permisos (sts/az/gcloud)
Account ID / tenant ID identificados
Auditoría automatizada (ScoutSuite/Prowler)
Inventario de activos cloud para la fase de ataque