Cloud Penetration Testing: How to Secure Your AWS, Azure, and GCP Environments

Cloud Security · AWS · Azure · GCP · April 2026

Cloud environments introduce attack surfaces that do not exist in traditional infrastructure. IAM privilege escalation, storage bucket exposure, serverless injection, container escape, and metadata service abuse require specialized testing techniques that traditional network pentesters are not equipped to perform.

💫 Key Takeaways

• Over 80% of cloud breaches involve IAM misconfigurations, not software vulnerabilities — traditional pentesting misses these entirely
• The shared responsibility model means cloud providers secure the infrastructure; you are responsible for configuration, identity, and data
• Each cloud provider has unique attack surfaces: AWS IAM policies, Azure AD integration, and GCP service account key management all require platform-specific expertise
• A single misconfigured S3 bucket, Azure Blob container, or GCS bucket can expose millions of records — storage misconfigurations are the most common critical finding
• Cloud pentesting requires provider approval or notification — AWS, Azure, and GCP each have different policies for authorized testing
• Container and Kubernetes testing is now essential — container escapes and cluster misconfigurations are a growing attack vector

The shared responsibility model is the foundation of cloud security. Your cloud provider (AWS, Azure, GCP) is responsible for securing the underlying infrastructure: physical data centers, hypervisors, networking hardware, and the foundational services. You are responsible for everything you build on top: identity and access management, data encryption, network configuration, application security, and operating system patching (for IaaS workloads).

Traditional penetration testing focuses on the layers the cloud provider has already secured. Scanning for open ports on EC2 instances, testing for OS-level vulnerabilities on managed services, or attempting to exploit hypervisor escapes are all testing the cloud provider's responsibilities. While there is some value in testing the attack surface of your workloads, the vast majority of cloud breaches come from misconfigurations in the layers you are responsible for — and those layers look nothing like traditional infrastructure.

Consider the difference: in a traditional data center, gaining initial access usually requires exploiting a software vulnerability or a weak password. In AWS, gaining initial access might mean finding an IAM access key committed to a public GitHub repository, discovering an S3 bucket with public read access containing database backups, or exploiting an SSRF vulnerability in a web application to reach the EC2 metadata service at 169.254.169.254 and steal the instance's IAM role credentials. The techniques, tools, and expertise required are fundamentally different.

Cloud environments present attack surfaces that simply do not exist in traditional infrastructure. A cloud penetration test must cover each of these:

IAM Privilege Escalation. Identity and Access Management is the backbone of cloud security and the most common source of critical findings. IAM privilege escalation occurs when a user or service with limited permissions can exploit policy misconfigurations to gain elevated access. In AWS, this might involve a user with iam:PassRole and lambda:CreateFunction permissions creating a Lambda function with an admin role attached, then invoking it to execute commands as the admin role. In Azure, a user with Contributor access to a virtual machine can execute commands on the VM and access its managed identity, which may have permissions far exceeding the user's own. We use tools like Pacu (AWS), ROADtools (Azure), and GCP IAM Analyzer to systematically identify and exploit these paths.

Storage Exposure. Public or overly permissive storage (S3 buckets, Azure Blob containers, GCS buckets) remains one of the most common and impactful cloud security issues. Testing involves enumerating storage resources, checking access control lists and bucket policies, testing for public read/write/list permissions, verifying encryption at rest, and checking for sensitive data in accessible objects. We have found database backups, customer PII exports, application source code, SSL private keys, and AWS credential files in publicly accessible storage across client environments.

Metadata Service Abuse. Cloud instances (EC2, Azure VMs, GCE instances) have a metadata service accessible at a link-local address (169.254.169.254 for AWS and GCP, 169.254.169.254 for Azure) that provides instance metadata, including IAM role credentials. Server-Side Request Forgery (SSRF) vulnerabilities in web applications can be exploited to reach this metadata service and steal temporary credentials. AWS IMDSv2 mitigates this by requiring a token, but many organizations still run IMDSv1 or have not configured the hop limit correctly. We test for SSRF paths to the metadata service and verify IMDSv2 enforcement across all instances.

Serverless Injection. Lambda functions, Azure Functions, and Google Cloud Functions are not immune to injection vulnerabilities. If a serverless function processes user input without sanitization, attackers can inject commands that execute in the function's runtime environment. Because serverless functions often have IAM roles with broad permissions (to access databases, storage, queues, and other services), a command injection in a single function can provide access to a wide range of resources. We test every serverless function that processes external input for injection vulnerabilities and verify that function IAM roles follow least privilege.

Container and Kubernetes Escape. Organizations running containers on EKS, AKS, or GKE face risks from misconfigured pod security policies, exposed Kubernetes API servers, overprivileged service accounts, and container runtime vulnerabilities that enable escape to the host node. A container escape on a Kubernetes node can provide access to other pods' secrets, the node's IAM role, and potentially the cluster's control plane. We test for privileged containers, host path mounts, writable service account tokens, and network policies that allow lateral movement between namespaces.

While the fundamental concepts are similar, each cloud provider implements security differently. A tester who is expert in AWS may miss critical findings in Azure or GCP without platform-specific knowledge.

Multi-cloud environments (which now represent the majority of enterprise cloud deployments) require testers with expertise across all platforms in use. A common pattern we see is an organization with strong AWS security that connects to Azure AD for identity federation — the Azure side becomes the weak link because it was configured by a team with less cloud security experience.

A cloud penetration test follows a different methodology than a traditional infrastructure test. Here is the approach we use, which has been refined across hundreds of cloud engagements:

Phase 1: Cloud Configuration Review. Before any active exploitation, we conduct a thorough review of cloud configuration. This includes IAM policy analysis (identifying overly permissive policies, unused access keys, cross-account trust relationships), storage permission auditing, network configuration review (VPC peering, security groups, NACLs, firewall rules), logging and monitoring configuration (CloudTrail, Azure Monitor, GCP Audit Logs), and encryption settings for data at rest and in transit. This phase uses read-only API access and identifies the configuration weaknesses that exploitation phases will validate.

Phase 2: External Reconnaissance. We enumerate the organization's external cloud footprint: public S3 buckets, exposed Azure Blob containers, open GCS buckets, publicly accessible cloud services (Elasticsearch, Redis, MongoDB instances with public IPs), exposed API gateways and serverless endpoints, and cloud-hosted web applications. Tools like CloudEnum, S3Scanner, and custom scripts identify resources that should not be externally accessible.

Phase 3: IAM Exploitation. With initial access (either from compromised credentials, an SSRF vulnerability, or a simulated compromised workload), we attempt to escalate privileges through IAM. We map the IAM permission graph using tools like Pacu for AWS, enumerate all paths from the current identity to higher-privilege roles, and exploit misconfigurations to demonstrate the maximum access level achievable from the starting point. This phase directly demonstrates the real-world impact of IAM policy weaknesses.

Phase 4: Service-Specific Testing. We test each cloud service in the environment for security misconfigurations. This includes databases (RDS, Azure SQL, Cloud SQL) for network exposure and authentication, compute services (EC2, Azure VMs, GCE) for metadata service exposure and weak security groups, serverless functions for injection and privilege issues, container services (EKS, AKS, GKE) for cluster misconfigurations, and key management services for rotation and access policies.

Phase 5: Lateral Movement and Impact. We demonstrate how initial access to one cloud resource can be leveraged to reach others. This might involve pivoting from a compromised EC2 instance to access RDS databases via its IAM role, using stolen Lambda execution role credentials to access S3 buckets containing sensitive data, or escalating from a single pod in Kubernetes to compromising the cluster control plane. The goal is to show the full blast radius of each initial access scenario.

A SaaS company — we will call them CloudServe — engaged us for their first cloud-specific penetration test. They had been conducting annual web application penetration tests for three years, but their AWS infrastructure had never been separately tested. They ran a multi-tenant SaaS platform on AWS with approximately 500 customer organizations. Here is what we found:

Finding 1: Public S3 bucket with application backups. During external reconnaissance, we discovered an S3 bucket named cloudserve-app-backups with public ListBucket and GetObject permissions. The bucket contained weekly application database backups in SQL dump format. These backups included customer data, hashed passwords, and configuration files with embedded credentials.

Finding 2: Embedded AWS credentials in backup. One of the configuration files in the backup contained AWS access key credentials for a service account used by the application. The credentials were for a user named app-service-user with a policy that granted s3:*, sqs:*, lambda:*, and iam:PassRole permissions.

Finding 3: IAM privilege escalation to Administrator. Using the app-service-user credentials, we exploited the combination of lambda:* and iam:PassRole to create a Lambda function that assumed an existing admin role. We created a function, attached the admin role, invoked the function, and received admin-level credentials in the function's output. Total time from stolen credentials to full account admin: 12 minutes.

Finding 4: Full account compromise. With administrator access, we could access all S3 buckets (including customer data), all RDS databases, all Lambda functions and their environment variables (containing additional secrets), all Secrets Manager entries, and the ability to create new IAM users with any permissions. We could have accessed data belonging to all 500 customer organizations, modified application code deployed through Lambda, and created persistent backdoor access that would survive credential rotation.

Kubernetes has become the de facto container orchestration platform, and most cloud-native applications run on EKS, AKS, or GKE. Container and Kubernetes security testing is now a critical component of any cloud pentest. Here are the key areas we test:

Cluster configuration. We assess the Kubernetes API server exposure (is it publicly accessible?), RBAC configuration (are default service accounts overprivileged?), admission controllers (are Pod Security Standards or OPA/Gatekeeper policies enforced?), network policies (is pod-to-pod communication restricted?), and secrets management (are secrets encrypted at rest or stored as base64 in etcd?). Misconfigured clusters frequently allow a compromised pod to query the Kubernetes API and discover other workloads, secrets, and configuration.

Container escape. We test whether containers can escape to the underlying node. This involves checking for privileged containers (which have full access to the host), containers with dangerous capabilities (SYS_ADMIN, SYS_PTRACE), host path mounts that provide access to the node's filesystem, containers running as root, and docker socket mounts that allow creating new containers on the host. A container escape on a Kubernetes node typically provides access to the node's cloud IAM role, all secrets mounted by other pods on the same node, and the kubelet credentials that can be used to query the API server.

Service mesh and network segmentation. In environments using Istio, Linkerd, or Cilium, we verify that service mesh policies actually enforce the intended communication patterns. We test whether pods can bypass the mesh, whether mTLS is properly enforced, and whether network policies prevent lateral movement between namespaces. Many organizations deploy service meshes for observability but never configure the security policies.

Image security. We assess the container images in use for known vulnerabilities (CVEs in base images and dependencies), embedded secrets (credentials, API keys, private keys baked into image layers), and image pull policies (can an attacker push a malicious image to the registry and have it pulled by the cluster?). Container images are immutable artifacts, so secrets embedded during the build process persist in every image layer and are accessible to anyone with access to the registry.

Cloud penetration testing requires more preparation than traditional infrastructure testing. Here is what you need to have ready before the engagement begins:

Access provisioning. Cloud pentesting requires API-level access, not just network access. For a configuration review, the tester needs read-only IAM access (SecurityAudit policy in AWS, Reader role in Azure, Viewer role in GCP). For exploitation testing, the tester needs credentials representing different access levels: a standard developer, a service account, and potentially an operator role. Define these access levels during scoping and provision them before testing begins.

Cloud provider notification. AWS removed the requirement for penetration testing approval in 2019 for most services, but you should still be aware of which services are permitted and which are excluded (DNS zone walking, DoS testing, etc.). Azure requires adherence to their Rules of Engagement. GCP's Acceptable Use Policy applies but does not require prior notification for testing your own projects. Your pentest provider should be familiar with each provider's current policies.

Rules of engagement. Define the rules of engagement clearly: which accounts and regions are in scope, which are excluded (production vs. staging), what the escalation process is if a critical vulnerability is found mid-test, and whether the tester is authorized to access actual customer data or should stop at proving access is possible. Cloud testing can have a wider blast radius than traditional testing if something goes wrong, so clear boundaries are essential.

Architecture documentation. Provide the tester with architecture diagrams, a list of cloud services in use, the network topology (VPCs, subnets, peering), and any existing security documentation. This allows the tester to spend time testing rather than discovering your architecture, and ensures that no critical services are missed.

Monitoring and alerting. Ensure your logging is active and your security team is aware of the testing window. A cloud pentest is also an opportunity to test whether your monitoring detects the tester's activities. Note any alerts that fire (or do not fire) during testing and include that observation in the engagement debrief. If the tester escalated to account administrator and no alert was generated, that is a critical monitoring gap independent of the vulnerability itself.

Ready to Secure Your Cloud Environment?

We conduct specialized cloud penetration testing across AWS, Azure, and GCP. Our testers focus on the attack surfaces that matter in the cloud — IAM privilege escalation, storage exposure, serverless security, and Kubernetes misconfigurations — not just port scanning your EC2 instances.