Cloud Reconnaissance

Before attacking a cloud infrastructure you must discover what the organization uses and what it has exposed: which provider, which public resources (buckets, functions, APIs), which domains point to cloud services, and which credentials they’ve leaked. Much of it is passive recon (see Passive Reconnaissance), but here it’s specifically aimed at identifying and enumerating cloud assets.

Identify the provider and assets

# DNS/CNAME reveal the provider
dig CNAME target.com         # *.amazonaws.com, *.azurewebsites.net, *.cloudfront.net...
# provider IP ranges (knowing whether an IP is AWS/Azure/GCP)
# certificates (crt.sh) and web fingerprint (recon-fingerprint)
# headers: Server, x-amz-*, x-azure-*, x-goog-*
curl -sI https://target.com | grep -iE 'amz|azure|goog|cloudfront|server'

Public buckets and storage (see Buckets and Public Storage)

# name patterns: 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>
# mass discovery tools
cloud_enum -k target        # searches buckets/blobs/GCS by keyword
S3Scanner / GrayhatWarfare  # public-bucket search engines

Enumeration of exposed cloud services

# serverless functions, APIs, apps
*.azurewebsites.net, *.lambda-url..., *.cloudfunctions.net, *.run.app (Cloud Run)
# API Gateway, App Service, etc. -> fingerprint and paths (recon-content)
# subdomains pointing to cloud services (recon-subdominios)

Leaked credentials (vector #1)

# in repos and code (see recon-code)
trufflehog / gitleaks -> AWS keys (AKIA...), Azure secrets, GCP service account JSON
# patterns
AKIA[0-9A-Z]{16}            AWS Access Key ID
"type": "service_account"   GCP service account key (JSON)
# in .env, logs, dumps, Pastebin

A leaked AWS key or service account JSON is direct access — the most impactful and frequent cloud finding.

Authenticated enumeration (with credentials)

If you get credentials, enumerate what you are and what you can do:

# AWS
aws sts get-caller-identity          # who am I?
aws iam get-account-authorization-details   # policies (if permitted)
enumerate-iam / pacu                 # what permissions I actually have
# Azure
az account show ; az ad signed-in-user show
ROADrecon / AzureHound               # enumerate the tenant
# GCP
gcloud auth list ; gcloud projects list

ID and tenant enumeration (without credentials)

# AWS Account ID from a bucket/ARN/error
# Azure tenant: https://login.microsoftonline.com/<domain>/.well-known/openid-configuration
# validate whether a domain uses Azure/O365 (see cloud-m365)

For the defense

Don’t expose resources publicly by default; unpredictable bucket names aren’t a defense (use policies).
Monitor credential leaks (secret scanning in repos, GitHub push protection).
Reduce the surface: don’t leave dev functions/APIs/services reachable; review DNS/CNAME pointing to cloud.
CSPM/ASM to inventory exposed cloud assets continuously.
Immediately rotate any credential that may have leaked.

Testing checklist

Identify the provider(s) by DNS/CNAME/headers
Discover buckets/blobs/GCS (cloud_enum, GrayhatWarfare)
Enumerate exposed serverless/apps/APIs
Look for leaked credentials (trufflehog/gitleaks)
With credentials: identity and permissions (sts/az/gcloud)
Account ID / tenant ID identified
Automated auditing (ScoutSuite/Prowler)
Inventory cloud assets for the attack phase