Cloud Pentesting: Key Differences Between AWS, Azure, and GCP

Cloud Pentesting Across AWS, Azure, and GCP
Cloud pentesting is less about spotting a single misconfiguration and more about proving how far one weak link can carry an attacker. Each provider has its own characters - roles, tokens, storage quirks, metadata services - and the plot unfolds when you chain them together.
AWS: where identity and data collide
In AWS, the story often starts with IAM. A role that can PassRole and AssumeRole, a policy wildcard, or an unintended ARN turns into a ladder. S3 tells its own tale: ACL drift, permissive bucket policies, presigned URLs that refuse to expire, and KMS keys that silently allow cross-account decrypts. Runtime checks look for IMDSv1 fallbacks exploitable via SSRF, Lambda environment secrets, and ECR repositories anyone can push to. Good SCPs, complete CloudTrail, and Config rules are the guardrails that decide whether the blast radius stays small.
Azure: the Entra and resource dance
Azure's plot begins with Entra ID. App registrations with lingering secrets, multi-tenant app abuse, consent phishing, and over-scoped Directory.ReadWrite.All permissions create early openings. RBAC drift shows up as a casual Contributor role on a subscription or a custom role with surprising DataActions. Storage and secrets bring SAS token sprawl, public blobs, and Key Vault policies that trust too many services. In AKS, the API server, PodSecurityAdmission, and managed identity hop paths decide whether containers stay penned in or roam free.
GCP: service accounts in the spotlight
GCP stories usually feature service accounts. Primitive roles like Owner and Editor, cross-project serviceAccountUser privileges, or overly broad Workload Identity Pools open doors. GCS buckets with IAM or ACL drift and replayable signed URLs expose data. GKE clusters leak metadata or run with node service accounts that reach too far. Cloud Run or Functions may inherit identities that were meant for something else. Detection relies on complete Cloud Audit Logs, Event Threat Detection, and sensible VPC Service Controls.
Chaining the scenes
The most revealing moments come from chains: an SSRF to metadata steals a token that assumes a higher role; a public object plus a weak presigned URL becomes a cross-account pivot; a leaked CI or CD credential lets an attacker write to an image registry and slide into production; an over-scoped managed identity or service account spills database contents, then key vault secrets, then everything else.
Closing the loop
Hardening is about narrowing the script. Enforce least privilege with SCPs, Blueprints, or Organization Policies. Require IMDSv2 and block metadata hops. Restrict egress, sign and attest build artifacts, and keep audit trails immutable with alerts on odd STS or token use. Every finding should become a regression test in Terraform policy checks or OPA so the same hole never reappears. Measure not just what you can exploit, but how quickly the environment notices and responds.
