What is cloud penetration testing?

Cloud penetration testing is an authorised assessment of a cloud account or tenant from an attacker perspective. The tester evaluates identity and access management, exposed services, storage, compute, networking, serverless functions, container platforms, and the trust boundaries between accounts. The objective is to find the realistic paths an attacker would take from external access or a low-privilege foothold to data exfiltration or full account takeover, and to demonstrate them safely without disrupting production workloads.

How is cloud penetration testing different from a CSPM scan?

Cloud Security Posture Management (CSPM) tools list misconfigurations against a static rule set. They flag every public S3 bucket and every overprivileged role, but they do not chain findings, validate exploitability, or model the cloud trust boundary against the workload identity. A pentest connects findings into attack paths, validates blast radius with proof of concept, prioritises issues by impact rather than by rule severity, and produces evidence a remediation team can act on. Most mature programmes run CSPM continuously and pentests on a defined cadence.

How long does a cloud penetration test take?

A focused single-account engagement (one AWS account, one Azure subscription, or one GCP project) with a moderate footprint typically takes 5 to 8 testing days. Multi-account or multi-cloud estates with hundreds of resources, custom roles, and serverless workloads usually run 10 to 15 days. Add scoping, retest, and reporting time. Continuous configuration drift checks between annual assessments are increasingly expected by buyers and auditors.

Do AWS, Azure, and GCP allow customers to pentest their cloud services?

Yes. AWS permits customer-driven testing on most services without prior approval under the AWS Customer Support Policy for Penetration Testing, with stress and DDoS testing requiring a separate request. Microsoft Azure follows a similar Microsoft Cloud Unified Penetration Testing Rules of Engagement. Google Cloud allows testing of customer projects without prior notification under the Google Cloud Customer Penetration Testing Policy. In every case, testers must stay within their own account or tenant, avoid out-of-scope shared services, and document the boundary in writing before any traffic.

What are the most common findings in cloud pentests?

Overprivileged IAM roles with wildcard actions, public storage buckets containing customer data, exposed instance metadata services without IMDSv2 enforcement, hard-coded credentials in compute user data and Lambda environment variables, security groups open to 0.0.0.0/0 on management ports, missing CloudTrail or Activity Log coverage in some regions, KMS keys with overly permissive policies, cross-account trust relationships with weak condition keys, public AMIs and container images with secrets, unrotated long-lived access keys, and serverless functions invoking other services with role escalation primitives.

What tools are used for cloud penetration testing?

Recon and enumeration use the cloud CLI (aws, az, gcloud), Pacu (AWS), CloudFox, ScoutSuite, Prowler, Steampipe, and CloudBrute. Identity and privilege escalation use Pacu modules, PMapper, Aaia, Stormspotter (Azure), and IAM-Vulnerable. Storage enumeration uses S3Scanner, AzureBlobChecker, and gsutil-based fuzzing. Network and compute use nmap, masscan, and gcp-firewall-enum. Serverless work uses sam local, Lambda invoke replay, and AzureFunctionEnum. Compliance mapping uses Prowler, Steampipe, and ScoutSuite. As always, methodology and reproducible evidence matter more than tool choice.

Does cloud penetration testing satisfy compliance requirements?

When scoped correctly, yes. PCI DSS 11.4 requires external and internal testing of in-scope environments, including cloud workloads handling cardholder data. ISO 27001 A.8.8 (technical vulnerability management) and A.5.23 (information security for use of cloud services) expect cloud-specific evidence. SOC 2 CC6 logical access controls benefit from IAM review evidence. NIST SP 800-53 SA-11 and CA-8 cover developer and assessor testing of cloud systems. Cyber Essentials Plus assesses authentication and patch management on cloud-hosted devices. Document methodology, scoping, and remediation for every finding.

How do you test multi-cloud environments without doubling the cost?

Build a shared methodology that covers identity, storage, compute, network, and serverless across all three providers, then specialise the technique catalogue per cloud. Reuse scoping templates, evidence collection procedures, and reporting structures. Run cross-cloud paths first (federated identity, cross-account replication, hybrid network peering) since these often produce the highest-impact findings. Use unified tooling like Prowler and Steampipe for baseline coverage and cloud-native CLIs for depth. Track findings in one workspace so duplicate issues across clouds collapse cleanly.

← Back to Blog

Guides6 May 202617 min read

Cloud Penetration Testing Checklist: AWS, Azure, GCP

Cloud accounts collapse identity, network, storage, and compute into a single API. That is their power and their problem. One overprivileged role, one public bucket, one exposed metadata service, and an attacker walks from a stolen developer key to full account takeover. This checklist covers the practical workflow for scoping, executing, and reporting on cloud penetration tests across AWS, Azure, and GCP. It complements the broader cloud security assessment guide and aligns with the CIS AWS, Azure, and GCP benchmarks, NIST SP 800-53, and the MITRE ATT&CK Cloud matrix.

Why a Cloud Pentest Is Not a Network Pentest

A traditional network pentest assumes hosts and IP addresses are the attack surface. A cloud pentest assumes the API is the attack surface. Identity is the new perimeter, services trust each other through role assumption rather than firewalls, and a single misconfigured policy can grant cross-account read access without ever crossing a wire. Tooling that excels on internal networks misses entire categories of cloud risk.

The realistic kill chain in modern cloud environments runs through identity. A leaked access key, a developer machine compromise, or a server-side request forgery into the instance metadata service yields temporary credentials. Those credentials assume a role. That role lists S3 buckets, reads KMS-encrypted data, or invokes a Lambda function with higher privileges. Each hop is a documented technique in MITRE ATT&CK Cloud.

For broader context, see our guides on penetration testing methodology and the difference between red team and penetration test engagements.

1. Scoping a Cloud Engagement

Cloud scoping is harder than a flat network test. Accounts have organisations, regions, services, identity providers, third-party integrations, and shared responsibility boundaries with the provider. Lock the details in writing before any traffic.

Account inventory: in-scope AWS accounts, Azure subscriptions and tenants, GCP projects and folders, organisation IDs, and the relationships between them (consolidated billing, management groups, folder hierarchy).
Starting position: external network only, compromised IAM user with read-only access, developer SSO session, CI/CD service principal, or all of these. Document the source explicitly.
Provider boundaries: confirm which services are fully managed (control plane out of scope), which run on customer-managed infrastructure, and where the shared responsibility line falls. Reference each provider rules of engagement.
Out-of-scope assets: third-party SaaS integrations, partner accounts, managed services that route through provider-shared infrastructure, and any production workloads with a no-test marker.
Workload constraints: production vs staging, blackout windows, denial-of-service limits, escalation contacts, and what happens if a security control quarantines a resource mid-test.
Rules of engagement: testing windows, allowed and disallowed payloads, data handling for any exfiltration proofs. Lock them in the scope of work.
Authorisation: a signed letter of authorisation naming specific accounts, subscriptions, or projects, plus written agreement on emergency stop conditions.
Deliverable expectations: report depth, retest scope, attack chain diagrams, portal access, and time-bound remediation tracking.

2. External Reconnaissance

Before any authenticated work, gather what the public internet leaks for free. Cloud recon is fast, low-risk, and frequently produces the first foothold by itself.

Enumerate cloud-hosted domains and certificates via crt.sh, censys, and the provider DNS suffixes (s3.amazonaws.com, blob.core.windows.net, storage.googleapis.com, run.app, azurewebsites.net)
Brute-force common storage names with S3Scanner, CloudBrute, and AzureBlobChecker; check public bucket listings and individual object permissions
Probe public-facing compute (EC2 with public IP, Azure VMs with public addresses, GCE instances with external IPs) for exposed management ports and outdated services
Identify public ingress points: ELB, ALB, API Gateway, CloudFront, Azure Front Door, Application Gateway, Cloud Run, App Engine, GKE LoadBalancer services
Enumerate public Lambda function URLs, Azure Function App endpoints, and Cloud Run services for unauthenticated paths
Search GitHub, npm, Docker Hub, and Postman public collections for leaked access keys, connection strings, and service account JSON
Inspect TLS certificates on public load balancers for SAN values that reveal account names, internal hostnames, and tenant identifiers
Check public AMIs, Azure shared images, and GCP custom images for organisation-tagged instances accidentally published

3. Initial Access and Foothold Validation

The realistic starting point in most engagements is a low-privilege IAM user, a developer SSO session, or a leaked CI/CD service principal. Confirm the foothold and establish baseline visibility before pivoting.

For AWS: aws sts get-caller-identity, aws iam list-attached-user-policies, aws iam get-account-summary
For Azure: az account show, az role assignment list --assignee, az ad signed-in-user show
For GCP: gcloud auth list, gcloud projects list, gcloud iam roles list --filter
Identify the assumed identity type: IAM user, role chain, federated SSO principal, service account, or workload identity
Enumerate granted policies and inline statements; note wildcards in actions or resources
Check whether MFA is enforced on the principal and whether session policies apply additional restrictions
Test which regions or subscriptions the principal can list; cross-region resources are often forgotten in scope
Confirm logging coverage: is CloudTrail recording your activity in every region, are Activity Logs flowing to a centralised workspace, are GCP Audit Logs enabled?

4. Identity and Access Management

IAM is the most common path to cloud compromise. Overprivileged roles, weak condition keys, and chained assume-role relationships show up in nearly every assessment. Map the graph systematically.

AWS specifics

List every IAM role; flag wildcard actions and unrestricted resources in policies
Map AssumeRolePolicyDocument trust relationships; identify roles trusting external accounts, services, or the entire AWS organisation
Run Pacu enumeration modules and PMapper to graph privilege escalation paths
Check for the iam:PassRole, iam:CreatePolicyVersion, lambda:CreateFunction, ec2:RunInstances, and sts:AssumeRole primitives that escalate to admin
Enumerate IAM users with long-lived access keys; check key age and last-used timestamps
Inspect SCPs at the organisation level; identify accounts not covered by guardrails
Look for cross-account roles with weak ExternalId or no condition keys at all

Azure specifics

Enumerate role assignments at management group, subscription, resource group, and resource scope
Identify Owner, Contributor, and User Access Administrator assignments at higher scopes than necessary
Check Entra ID (formerly Azure AD) directory roles: Global Administrator, Privileged Role Administrator, Application Administrator
Map service principals and managed identities; flag any with privileged Graph API permissions (RoleManagement.ReadWrite.Directory, Application.ReadWrite.All)
Run Stormspotter or Azucar for graph-based path discovery
Inspect Conditional Access policies for gaps (legacy authentication allowed, no MFA on privileged roles)
Check for Privileged Identity Management (PIM) coverage; standing privileged access is a finding

GCP specifics

Enumerate IAM bindings at organisation, folder, project, and resource level
Identify primitive roles (roles/owner, roles/editor) granted at high scope
Check for service account impersonation grants (roles/iam.serviceAccountTokenCreator) and the actAs primitive (roles/iam.serviceAccountUser)
Map service account keys; long-lived JSON keys are a findings magnet
Run Aaia or hayat for graph-based privilege escalation discovery
Check for cross-project trust via shared VPC, service account impersonation, and federated workload identity pools
Inspect Org Policies for gaps in iam.allowedPolicyMemberDomains or iam.disableServiceAccountKeyCreation

Capture the IAM graph as evidence. Privilege escalation screenshots in the final report are far more persuasive when they show the exact paths an attacker would take.

5. Storage and Data Exposure

Cloud storage is the most exfiltrated asset class. Public buckets, weak ACLs, missing encryption, and overly broad bucket policies remain common across all three providers.

Enumerate every S3 bucket, Azure storage account, and GCS bucket; check public access settings, ACLs, and bucket policies
Test object-level ACLs even when the bucket is private; legacy ACLs sometimes grant world-read on individual objects
Check for unencrypted storage; look for missing default encryption, missing customer-managed KMS keys, and weak key policies
Inspect lifecycle policies; older objects sometimes downgrade to public storage classes
Enumerate signed URL generation patterns; long-lived signed URLs in code are credential equivalents
Check S3 Block Public Access at account level; absence is a high-impact finding even when no buckets are public today
For Azure: check storage account network rules, allow trusted services exceptions, and shared access signature (SAS) token usage
For GCS: check uniform bucket-level access, retention policies, and IAM conditions on storage admins
Look for SQL backups, log archives, application configuration dumps, and customer datasets in shared buckets

6. Compute and the Metadata Service

The instance metadata service is the single highest-impact cloud attack primitive. Every workload that exposes it to a server-side request forgery becomes a credential laundering machine.

For AWS EC2: check whether IMDSv2 is enforced (HttpTokens: required) on every instance and every Auto Scaling launch template
For EC2 user data: read instance user data fields for hard-coded credentials, registry tokens, and bootstrap configuration
For ECS and Fargate: check task IAM roles for excessive permissions; flag tasks with no task role separation from execution role
For EKS: review the cluster IAM role and node IAM role; pair with the dedicated Kubernetes pentest guide
For Azure VMs: check whether the IMDS endpoint at 169.254.169.254 is reachable from workloads and whether Managed Identity is appropriately scoped
For Azure Function Apps: inspect App Settings for hard-coded secrets and the assigned managed identity
For GCE: check whether the metadata server enforces version 1 (legacy v0 endpoints leak service account tokens without authentication header)
For GKE: check workload identity pool bindings and the default node service account scopes
Test for SSRF on every public web tier; an SSRF that reaches IMDS is a critical-severity finding
Check for AMI, Azure VM Image, and GCE Image metadata exposing sensitive build artefacts

7. Network and Perimeter

Cloud networks default to permissive within an account. Attackers who reach one workload often reach many. Test the segmentation that should contain the blast radius.

Enumerate every VPC, VNet, and VPC Network; identify any with public ingress on management ports (SSH, RDP, WinRM, database engines)
Map security groups, NSGs, and firewall rules; flag rules with 0.0.0.0/0 source and a privileged destination port
Check for VPC peering, VNet peering, and shared VPC connections; identify trust relationships across account or organisation boundaries
Inspect Transit Gateways, Azure Virtual WAN, and GCP Network Connectivity Center for over-broad route propagation
Test internal reachability: from a compromised compute resource, attempt to reach RDS, Azure SQL, Cloud SQL, internal load balancers, and other private services
Check for unencrypted data in transit; lack of TLS on internal load balancers is a finding even when external is TLS-enforced
Look for VPC endpoints, Azure Private Link, and GCP Private Service Connect for service-side endpoint policies allowing cross-account access
For hybrid environments, test VPN and Direct Connect/ExpressRoute trust boundaries

8. Serverless and Managed Services

Serverless functions, container platforms, and managed databases inherit a different threat model. The host is gone, but identity, code, and configuration become the substrate.

For Lambda: enumerate every function, read environment variables for hard-coded secrets, inspect execution role permissions, and check resource policies for overly broad invoke permissions
For Lambda function URLs: check authentication type and the IAM resource-based policy
For Azure Function Apps: read App Settings, check the managed identity assignment, and inspect deployment slots for staged credentials
For Cloud Run and Cloud Functions: check ingress settings, the runtime service account, and authentication requirements
For API Gateway, Azure API Management, and GCP API Gateway: check authentication, throttling, and the Lambda or backend integration role
For DynamoDB, Cosmos DB, Firestore, BigQuery, and Redshift: enumerate table-level IAM and access keys; check for read-only public access patterns
For Step Functions, Logic Apps, and Workflows: inspect execution role privileges and any resources they invoke
For SQS, SNS, EventBridge, Service Bus, and Pub/Sub: check resource policies for cross-account or wildcard subscriptions
For SageMaker, Azure ML, and Vertex AI: check notebook instance IAM, training job roles, and model endpoints exposed publicly

9. Logging, Detection, and Audit Trail

Detection capability is part of the assessment. A finding becomes more compelling when it shows an entire attack chain executed without alarms.

For AWS: confirm CloudTrail multi-region trail with management and data events; check log file integrity validation and KMS encryption
For Azure: confirm Activity Log export to Log Analytics, Storage, or Event Hub; check Diagnostic Settings on key resources
For GCP: confirm Cloud Audit Logs (Admin Activity, Data Access, System Event); check log sink coverage at organisation level
Test which detection capabilities exist: GuardDuty, Security Hub, Defender for Cloud, Sentinel, Security Command Center, Chronicle
Run high-signal techniques and check whether they generate alerts: console login from a new geography, IAM user creation, root user activity, large data downloads, unusual API calls
Check for log retention gaps; some teams retain only 30 days, which is below most compliance baselines
Inspect log integrity controls; logs writable by the same role being tested are not trustworthy evidence
Document detection coverage as findings, not asides; missing detection is a finding by itself

10. Cross-Cloud and Hybrid Boundaries

Single-cloud testing misses the most damaging modern attack paths. Identity federation, cross-cloud replication, and hybrid network peering create trust relationships that often outlive the people who built them.

Identify federated identity providers: Okta, Entra ID as IdP, AWS IAM Identity Center, Workspace SAML, GitHub Actions OIDC, GitLab OIDC
For each OIDC trust relationship, inspect the audience and subject conditions; over-broad trust on GitHub OIDC is a recurring critical finding
Test SAML assumption flows; weak signature validation or unrestricted assume-role with SAML primitives are exploited in the wild
For Entra ID Connect (on-prem to Azure AD): check the synchronisation account permissions and the AD Connect server posture
For AWS-Azure or AWS-GCP federations: enumerate trust policies for cross-cloud assume role and identify principals that span environments
For data replication (S3 cross-region, Azure GRS, GCP turbo replication): check destination account permissions and KMS key access
For hybrid networking (Site-to-Site VPN, Direct Connect, ExpressRoute, Cloud Interconnect): test for over-routing and missing route filtering
Document each cross-cloud path as an attack chain; remediation often spans multiple teams and benefits from explicit narrative

11. Reporting and Remediation Tracking

Cloud findings chain. A leaked access key leads to a privileged role leads to KMS decrypt leads to S3 customer data. A list of isolated CVSS scores hides that story. Structure the deliverable so platform engineering can follow the path and prioritise the chokepoints.

Executive summary with business impact, attack narrative, and the chokepoints that break each chain
Technical findings with reproduction commands, evidence, and CVSS scores validated using the CVSS calculator
IAM graph screenshots that match the attack chain in the narrative
Per-finding remediation guidance distinguishing root cause from compensating control
Mapping to compliance frameworks (PCI DSS 11.4, ISO 27001 A.5.23 and A.8.8, SOC 2 CC6, NIST SP 800-53 SA-11, CIS AWS, Azure, and GCP benchmarks)
Prioritisation using CVSS plus EPSS plus asset tier, with privilege escalation and storage exposure paths always at the top
Delivery in a portal that supports retest workflows and persistent remediation status, not just a static PDF

SecPortal's findings management ships with templates for common cloud findings (overprivileged IAM, public storage, IMDS exposure, weak KMS policies, missing CloudTrail coverage), AI-generated executive and technical reports, and a branded client portal so platform and application teams remediate without losing context. See the report template for the full structure.

12. Between Engagements: Hardening and Monitoring

Annual cloud pentests find the issues. Continuous hygiene keeps them found. Pair the engagement with ongoing controls and detection so the next test does not surface the same drift.

Enforce IMDSv2 on every AWS instance and template; default-deny IMDS access from pods on EKS
Block public access at the storage account level; require KMS-encrypted defaults
Adopt least-privilege IAM with attribute-based access where possible; expire long-lived access keys
Enforce MFA for all human users; require Conditional Access for privileged Entra ID roles; gate GCP super admin behind hardware tokens
Disable service account key creation by default in GCP; rotate any remaining keys on a schedule
Restrict OIDC trust on GitHub Actions and GitLab to specific repositories and branches
Run CSPM (Prowler, Steampipe, ScoutSuite, or a managed equivalent) on a schedule; alert on regressions
Enable provider-native detection: GuardDuty, Defender for Cloud, Security Command Center; route findings into the workspace where they will be triaged
Schedule recurring external scans and continuous monitoring against public ingress so configuration drift is caught quickly

For programme-level structure, see building continuous security monitoring and the vulnerability management programme guide.

The Quick Cloud Pentest Checklist

A condensed version to use during the engagement.

Lock scope to specific accounts, subscriptions, projects, regions, and organisation boundaries
Confirm signed authorisation, provider rules of engagement, and emergency stop conditions before any traffic
Enumerate public DNS, certificates, storage, ingress endpoints, and leaked secrets in code repositories
Validate the foothold: list identity, granted policies, regions reachable, and logging coverage
Map the IAM graph; flag wildcards, weak trust conditions, and chained assume-role primitives
Run privilege escalation tools (Pacu, PMapper, Stormspotter, Aaia) and validate paths manually
Inspect every storage bucket, blob container, and GCS bucket for ACLs, encryption, and public exposure
Check IMDS enforcement, instance user data, function environment variables, and managed identity scope
Map network ingress, VPC and VNet peering, and hybrid connectivity for over-broad routes
Enumerate serverless functions and managed services; review execution roles and resource policies
Validate logging coverage and detection capability; record what fires and what does not
Test cross-cloud and federated identity boundaries; OIDC trust on CI providers is high-impact
Score findings with CVSS, prioritise with EPSS plus asset tier, deliver in a portal that supports retest
Schedule continuous CSPM coverage and external monitoring between assessments

Frequently Asked Questions About Cloud Pentesting

Run cloud penetration tests with findings, IAM paths, retests, and reports in one place

SecPortal gives security teams findings management with templates for cloud attacks, CVSS scoring, AI-assisted reporting, external and authenticated scanning, continuous monitoring, and a branded client portal so platform and application teams remediate fast. See pricing or start free.

Get Started Free