Cloud Penetration Testing: AWS, Azure & GCP

Cloud penetration testing is an adversarial assessment of cloud infrastructure — IAM configurations, storage permissions, compute instances, serverless functions, and inter-service trust relationships — using the techniques a cloud-savvy attacker would use to achieve unauthorized access. Misconfigurations are the dominant root cause of cloud breaches: the 2023 Verizon Data Breach Investigations Report found misconfiguration and errors were the second-most common action type in cloud asset incidents. A single overly permissive IAM policy can expose an entire environment.

Standard network penetration testing tools and techniques do not transfer directly to cloud environments; the attack surface and controls are fundamentally different from on-premises infrastructure.

This guide covers what cloud penetration testing actually involves: the shared responsibility model and its testing implications, what each major cloud provider permits testers to do, cloud-specific attack vectors, and the specialized tooling that makes cloud assessment effective.

The Shared Responsibility Model: What It Means for Security Testing

Every major cloud provider operates on a shared responsibility model: the provider is responsible for security of the cloud (physical infrastructure, hypervisor, core services), and the customer is responsible for security in the cloud (operating system configuration, access control, data encryption, network security groups, IAM policies).

This model has a direct implication for penetration testing scope: a cloud penetration test is an assessment of the customer's configuration and deployment choices, not an attack on the cloud provider's infrastructure. Testing the hypervisor, underlying network switches, or the cloud provider's control plane is not authorized and is not a realistic attack scenario for most threat models anyway.

What is in scope for cloud penetration testing:

IAM policies, roles, and permission boundaries
Storage configuration (S3 bucket ACLs and policies, Azure Blob public access, GCS bucket permissions)
Compute instance security (security groups, exposed ports, instance metadata access)
Serverless function configuration (Lambda, Azure Functions, Cloud Functions)
Container orchestration security (EKS, AKS, GKE cluster configuration, pod security policies)
Secrets management (Secrets Manager, Key Vault, Secret Manager — and how secrets are accessed and rotated)
Network configuration (VPC design, NACLs, peering relationships, route tables)
Logging and monitoring coverage (CloudTrail, Azure Monitor, Cloud Audit Logs)

What Cloud Providers Allow: Testing Policies by Provider

Before starting a cloud penetration test, verify compliance with your provider's current penetration testing policy. These policies evolve and supersede any summary in this document — always check the primary source.

AWS

Amazon Web Services does not require advance notification or approval for penetration testing of customer-owned AWS resources, provided testing stays within the customer's own accounts. The AWS Customer Support Policy for Penetration Testing explicitly permits testing for the following service types: EC2 instances, NAT Gateways, Elastic Load Balancers, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, and Elastic Beanstalk.

What is not permitted: DNS zone walking of Route 53 hosted zones, denial of service testing against AWS infrastructure, port flooding, protocol flooding, and request flooding (simulated DDoS). Multi-tenant testing — any test that could affect other AWS customers — is prohibited.

Azure

Microsoft Azure requires that customers agree to the Microsoft Cloud Penetration Testing Rules of Engagement before conducting testing. Testing is permitted against resources in the customer's own Azure subscription without separate approval, as long as testing complies with Microsoft's Acceptable Use Policy and the penetration testing rules. Azure explicitly prohibits testing that targets Microsoft's infrastructure, violates service availability for other customers, or involves social engineering of Microsoft employees.

GCP

Google Cloud Platform's penetration testing policy does not require advance notification for testing of customer-owned GCP resources, provided testing stays within the customer's own projects and complies with the GCP Acceptable Use Policy. As with AWS and Azure, testing that targets Google's infrastructure, involves denial-of-service attacks, or affects other GCP customers is prohibited.

The practical implication: get the current policy documentation from each provider's security page, confirm your testing activities fall within permitted scope, and document your compliance with provider policy as part of the engagement authorization paperwork.

Cloud-Specific Attack Vectors

IAM Misconfiguration: The Universal Cloud Risk

IAM (Identity and Access Management) is the core security control in every cloud environment — and the most consistently misconfigured. Common IAM attack vectors:

Overpermissive IAM roles: AWS IAM roles attached to EC2 instances or Lambda functions that carry AdministratorAccess or wildcard actions ("Action": "*") create direct privilege escalation paths. Testing maps every role to its effective permissions and identifies whether any compute resource carries permissions beyond what its function requires.

AssumeRole privilege escalation: An IAM user or role with sts:AssumeRole permissions targeting a more-privileged role can escalate to that role's permission set. Testing requires enumerating trust relationships across all roles and identifying escalation chains — a path that goes through three low-privilege roles before reaching admin access is still an escalation path.

Unused access keys and long-lived credentials: AWS root account access keys, IAM user access keys that have not rotated in months, and service account keys committed to source code repositories are all common entry points. The AWS Credential Report provides a starting point for reviewing key age and usage.

Confused deputy attacks: Cloud services that act on behalf of a customer (service roles) can be manipulated into performing cross-account actions if cross-account trust relationships and External ID conditions are not properly implemented.

S3 Bucket Exposure and Storage Misconfiguration

Publicly accessible S3 buckets remain one of the most frequent sources of cloud data breaches. Common findings:

Public read ACL with sensitive data — buckets containing backup files, database exports, or log files with PII set to public-read
Public bucket policy — a bucket policy with "Principal": "*" grants access to any AWS principal, including unauthenticated requests
Static website hosting with sensitive content — S3 static website hosting makes bucket contents accessible via HTTP to any requestor
Server access logging disabled — without server access logging, unauthorized access to bucket contents leaves no evidence

Testing covers enumeration of all S3 buckets accessible from the tested accounts, public access status verification, bucket policy analysis, and Object Lock and versioning configuration review.

Metadata Service SSRF: A Critical Cloud Attack Path

The EC2 Instance Metadata Service (IMDS) at http://169.254.169.254/latest/meta-data/ is accessible from within any EC2 instance and provides temporary IAM credentials for the instance's attached role. A Server-Side Request Forgery (SSRF) vulnerability in any application running on EC2 can be used to retrieve these credentials and use them to interact with the AWS API as the instance's role.

AWS introduced IMDSv2 (requiring session tokens for metadata access) to mitigate this attack, but many deployments remain on IMDSv1 or configure IMDSv2 as optional rather than required. Testing verifies IMDSv2 enforcement status on all relevant instances.

Azure and GCP have equivalent metadata services at http://169.254.169.254/metadata/instance and http://metadata.google.internal/computeMetadata/v1/, respectively, with their own access control requirements.

Container and Kubernetes Misconfiguration

Container environments introduce a distinct attack surface:

Privileged containers: A container running with --privileged or hostPID: true can interact with the host OS and escape the container boundary
Exposed Kubernetes API server: A Kubernetes API server accessible without authentication (or with overly permissive RBAC) allows an attacker to enumerate pods, secrets, and service accounts, and to exec into running containers
Kubernetes secrets in environment variables: Secrets mounted as environment variables are accessible to any process in the container and appear in pod specifications readable by anyone with kubectl get pods -o yaml
Overpermissive service accounts: Kubernetes service accounts with cluster-admin binding or access to secret-reading permissions create lateral movement paths within the cluster

Specialized Cloud Security Tooling

Tool	Cloud Provider	Role
Prowler	AWS, Azure, GCP	Open-source CIS Benchmark compliance scanning, configuration assessment
ScoutSuite	AWS, Azure, GCP	Multi-cloud security posture assessment, generates HTML report of misconfiguration findings
Pacu	AWS	AWS exploitation framework; IAM enumeration, privilege escalation, persistence
ROADtools	Azure	Azure AD enumeration, token manipulation, conditional access bypass analysis
WeirdAAL	AWS	AWS attack library for post-compromise enumeration
CloudSplaining	AWS	IAM policy analysis for privilege escalation and data exfiltration paths
Trivy	Multi-cloud	Container image and IaC (Terraform, CloudFormation) misconfiguration scanning
Checkov	Multi-cloud	Infrastructure-as-code static analysis for AWS, Azure, GCP resource misconfigurations

These tools accelerate reconnaissance and configuration analysis, but the most impactful cloud security findings — IAM privilege escalation chains, cross-account trust abuse, SSRF to metadata credential theft — require a tester who understands cloud architecture well enough to chain discovered misconfigurations into realistic attack scenarios. The red team vs. penetration testing guide explains when a full adversary simulation is the right choice for validating cloud detection and response capabilities.

CSA Cloud Controls Matrix and Compliance Context

The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is the most comprehensive cloud-specific security control framework, providing 197 control objectives across 17 domains aligned to AWS, Azure, and GCP service models. Organizations pursuing CSA STAR certification use the CCM as their control baseline, and cloud penetration testing provides evidence for controls in the CCM's IAM, infrastructure security, and audit and assurance domains.

For regulated industries, cloud security assessments must consider:

PCI DSS v4.0 — if cardholder data is processed or stored in cloud infrastructure, the cloud environment is in PCI scope and requires penetration testing (Requirement 11.4) and compliance with Requirement 3 (data storage) in the cloud context
HIPAA — cloud infrastructure processing ePHI requires an assessment of technical safeguards per §164.312; Business Associate Agreements (BAAs) with cloud providers must be in place and their scope limitations understood
SOC 2 — cloud infrastructure configuration directly supports or undermines Common Criteria controls CC6.1 (logical access), CC6.6 (points of access), and CC6.7 (data transmission); penetration testing provides evidence for CC7.1 (security monitoring)

Real-World Use Case: Findings That Only Exist in the Cloud

A fintech company migrated from on-premise infrastructure to AWS over eighteen months. Six months after the migration completed, they commissioned their first cloud penetration test as part of a SOC 2 Type II audit preparation.

The tester identified three critical findings, none of which would have appeared in a traditional network penetration test of the prior on-premise environment. First: an IAM role attached to an EC2 instance carried iam:PassRole and sts:AssumeRole permissions. By chaining three role assumptions — each individually appearing low-privilege — the tester achieved AdministratorAccess to the production AWS account. The escalation path crossed three different role assignments created by three different teams at three different points in the migration; no single team was aware the chain existed. Second: an S3 bucket containing application logs with customer PII had been configured with a public-read bucket policy. The misconfiguration originated from a developer copying a bucket policy template from a staging bucket, where public-read had been set for convenience during testing and never removed. Third: an EC2 instance running the web application had IMDSv1 enabled. The application contained a Server-Side Request Forgery (SSRF) vulnerability in its URL preview feature. The tester used the SSRF to reach http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve temporary IAM credentials for the instance role — credentials that provided read access to every S3 bucket in the account.

The migration team's prior focus had been on replicating application functionality. None of the three findings reflected a vulnerability in application code — they were all products of cloud configuration decisions made during the migration. A network pentest of the on-premise environment would have found zero of them.

Frequently Asked Questions

Does a cloud penetration test require permission from the cloud provider?

For AWS, Azure, and GCP, you do not need to notify or obtain advance approval from the cloud provider to test your own resources, as long as testing stays within your own accounts or subscriptions and complies with each provider's penetration testing policy. AWS's Customer Support Policy for Penetration Testing, Microsoft's Cloud Penetration Testing Rules of Engagement, and GCP's Acceptable Use Policy each define what is permitted. The key restrictions are consistent across providers: testing must not affect other customers' resources, denial-of-service testing against provider infrastructure is prohibited, and testing that targets the provider's control plane is not permitted. Always review the current policy documentation directly from each provider before starting — policies are updated and supersede any summary in this or any other document. Retain copies of the policy documentation applicable at the time of testing as part of your engagement authorization records.

What is the difference between a cloud security review and a cloud penetration test?

A cloud security review — sometimes called a cloud security posture assessment or CSPM audit — is a configuration analysis. Tools like Prowler, ScoutSuite, or vendor-native tools (AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center) evaluate your cloud configuration against benchmarks like the CIS AWS Foundations Benchmark and flag deviations. This produces a list of configuration findings — public S3 buckets, unencrypted volumes, overpermissive security groups — ranked by severity. A cloud penetration test goes further: a tester actively attempts to exploit the misconfigurations identified and identifies attack chains that configuration tools cannot see. The IAM privilege escalation example above — three separately innocuous role assignments chaining to administrator access — will not appear in a Prowler report because no single role is misconfigured in isolation. It requires a tester who understands how the policies interact. For most organizations, the right approach is both: use automated CSPM tooling continuously, and layer cloud penetration testing on top to identify the exploitable subset of configuration findings and the chained attack paths that tools miss.

How does cloud pentesting handle multi-account AWS environments?

Modern AWS deployments commonly use AWS Organizations to manage dozens or hundreds of accounts — separate accounts for production, staging, development, security tooling, and each business unit or product line. A cloud penetration test of a multi-account environment must address cross-account trust relationships as a primary attack surface: IAM roles with cross-account trust policies, AWS Organizations Service Control Policies (SCPs) that may be overpermissive, and shared services accounts whose compromise could provide lateral movement to production accounts. Testing scope for a multi-account environment should be defined in terms of the account hierarchy, not just a list of individual accounts. The tester needs sufficient permissions to enumerate trust relationships across the organization — typically read access to IAM in each account and access to the management account's AWS Organizations configuration. Scope the engagement to cover the accounts that process sensitive data and the accounts with administrative privileges over those accounts, as a minimum.

What tools are used in cloud penetration testing?

Cloud penetration testing combines configuration analysis tools with exploitation frameworks tailored to each provider. On AWS, Prowler and ScoutSuite perform automated configuration assessment against CIS benchmarks; Pacu provides an exploitation framework for IAM enumeration, privilege escalation simulation, and post-compromise enumeration; CloudSplaining analyzes IAM policies for privilege escalation and data exfiltration paths. On Azure, ROADtools handles Azure AD enumeration, token manipulation, and conditional access policy analysis; Stormspotter maps Azure RBAC and resource relationships for lateral movement path analysis. For Kubernetes environments running on any provider, kube-hunter and kube-bench test cluster security configuration. For infrastructure-as-code review, Checkov and Trivy analyze Terraform, CloudFormation, and ARM templates for misconfigurations before they reach production. Manual techniques — using the AWS CLI, Azure CLI, or gcloud with the credentials of a compromised identity to enumerate what is reachable — are essential for finding the chained privilege escalation paths that no automated tool surfaces.

How often should cloud infrastructure be tested?

At minimum, annually — but cloud environments change faster than annual testing can track. A cloud environment that has been through a major migration, a new product launch, or a significant expansion of services in the past twelve months has a materially different attack surface than it did when last tested. A practical framework: conduct a comprehensive cloud penetration test annually, run automated CSPM tooling continuously to catch configuration drift between tests, and commission a targeted cloud security review whenever significant infrastructure changes occur — new account structures, new IAM federation configurations, adoption of new services that handle sensitive data. Organizations in regulated industries (financial services, healthcare, payments) or those pursuing SOC 2 Type II, PCI DSS, or ISO 27001 certification should treat annual testing as a floor and calibrate frequency to their change rate.

Effective cloud penetration testing combines automated configuration analysis tools with manual assessment of IAM privilege escalation chains, storage exposure, metadata service attack vectors, and container security — mapped to the specific services and configurations in your environment, not against a generic benchmark. When evaluating providers, look for demonstrated experience with multi-cloud environments and evidence of manual IAM escalation analysis beyond what tools like Prowler or ScoutSuite surface automatically.

WhiteJaguars, a Costa Rica-based pentesting firm, applies PTES + OWASP + MITRE ATT&CK methodology to cloud security assessments across AWS, Azure, and GCP, includes unlimited retests, and fields a team with OSCP, CISSP, CEH, and CISM certifications, among others.

Cloud Penetration Testing (AWS/Azure/GCP) Essentials