Cloud Pentesting: Key Differences Between AWS, Azure, and GCP
Cloud penetration testing is less about finding one bad setting and more about proving how far one weak link carries an attacker. Each provider has its own identity model and its own footguns, but the pattern is the same everywhere: an over-permissive identity plus an exposed resource equals a path to your data. Here is what we look for on AWS, Azure, and GCP, and a few checks you can run yourself.
AWS: identity is the attack surface
Most AWS engagements start with IAM. A role that can assume other roles, a wildcard in a policy, or a trust relationship that is too broad becomes a ladder to higher privilege. On top of that, storage and metadata: public or misconfigured S3 buckets, presigned URLs that never expire, and instances still allowing the older instance metadata service (IMDSv1), which SSRF can abuse to steal credentials. A quick self-check for over-broad policies:
bash
# Find IAM policies that grant wildcard actions on all resources
aws iam list-policies --scope Local --query 'Policies[].Arn' --output text | tr ' ' '
' | while read arn; do
v=$(aws iam get-policy --policy-arn "$arn" --query 'Policy.DefaultVersionId' --output text)
aws iam get-policy-version --policy-arn "$arn" --version-id "$v" --query "PolicyVersion.Document.Statement[?Action=='*'||Resource=='*']" --output text | grep -q . && echo "OVER-BROAD: $arn"
doneAzure: Entra ID and RBAC drift
Azure work usually begins in Entra ID. App registrations with lingering client secrets, over-scoped Graph permissions, and consent phishing are common openings. Then RBAC drift: a casual Contributor role on a whole subscription, or a custom role with surprising data actions. Storage brings SAS-token sprawl and public blobs; Key Vault brings access policies that trust too many principals.
GCP: service accounts in the spotlight
On GCP the recurring theme is service accounts. Primitive roles like Owner and Editor, cross-project service-account use, and over-broad Workload Identity bindings open doors. GKE clusters can leak node identities that reach far more than they should. Auditing who can impersonate a service account is a good starting point:
bash
# List members who can act as (impersonate) service accounts in a project
gcloud projects get-iam-policy PROJECT_ID --format=json | jq -r '.bindings[] | select(.role|test("iam.serviceAccount(User|TokenCreator)")) | .role, .members[]'The real risk is the chain. The findings that matter are rarely a single setting. They are an SSRF that steals a token, that assumes a higher role, that reads a bucket, that unlocks the next account. We test for the chain, then measure how quickly your logging and alerting notice.
Close the loop
Hardening means narrowing the script: least privilege enforced with service control policies or organization policies, mandatory IMDSv2, restricted egress, and immutable audit trails with alerts on unusual token use. Every finding should become a policy-as-code check so the same hole never reappears.
Running on AWS, Azure, GCP, or a mix and want a senior tester to prove your real blast radius? That is our cloud penetration testing service, get a quote.
