Cloud Penetration Testing: AWS, Azure & GCP Assessment Guide (2026)
Babar Khan Akhunzada
March 1, 2026
Most organisations that have pentested their web application haven't pentested their cloud environment. The two share an attack surface at the edges SSRF, exposed storage, misconfigured APIs but cloud infrastructure has vulnerabilities that a web app pentest scope doesn't touch: IAM privilege escalation, metadata service exploitation, inter-service trust abuse, storage bucket exposure, and lateral movement across cloud-native services.
If your infrastructure runs on AWS, Azure, or GCP, this guide covers what a cloud penetration test actually involves, how it differs from a misconfiguration review, what each provider's penetration testing rules actually say, and what a cloud pentest report needs to contain for SOC 2 and ISO 27001 evidence.
- What Cloud Penetration Testing Is
- Cloud Pentest vs Misconfiguration Review
- AWS, Azure & GCP Penetration Testing Rules
- What Cloud Penetration Testing Covers
- SSRF to Cloud Metadata: How Serious Is It?
- Questions Teams Actually Ask
- What a Cloud Pentest Report Contains
- Get a Cloud Security Assessment
What Cloud Penetration Testing Is
Cloud penetration testing is a manual security assessment of your cloud infrastructure the IAM configuration, storage services, compute instances, serverless functions, container orchestration, network controls, and inter-service permissions that make up your cloud environment.
A tester approaches your cloud environment the way an attacker would after gaining initial access: probing for privilege escalation paths, misconfigured storage, over-permissioned service accounts, metadata service exposure, lateral movement opportunities across services, and data exfiltration paths that exist independently of your application layer.
What distinguishes it from a web app pentest: A web app pentest tests what a user of your application can do. A cloud pentest tests what an attacker who has compromised a single service, instance, or credential can do within your cloud environment and how far they can move from that starting point. The attack paths are entirely different, and the findings that matter most (IAM privilege escalation, metadata credential theft, cross-account access abuse) are invisible in a web app scope.
What it is not: Running a CSPM tool (Prisma Cloud, Wiz, Orca) against your cloud account and generating a findings report. Those tools find known misconfiguration patterns at scale they don't test exploitability, don't chain findings into realistic attack paths, and don't find the organisation-specific trust relationships and permission combinations that a manual tester discovers by understanding your environment.
Cloud Pentest vs Misconfiguration Review
This is the most common confusion among engineering and security teams evaluating cloud security assessments. The distinction matters for both budget decisions and compliance evidence.
| Area | Misconfiguration Review | ⚡ Cloud Pentest |
|---|---|---|
| Execution | Automated CSPM tooling + config review | Manual tester simulating active attacker |
| IAM privilege escalation | ◑ Flags overly permissive policies | ✓ Exploits escalation paths to root/admin |
| Metadata exploitation | ✕ Not tested | ✓ SSRF to IMDSv1/v2 tested and evidenced |
| Lateral movement | ✕ Not simulated | ✓ Post-compromise movement across services |
| Attack chain evidence | ✕ Individual findings only | ✓ Findings chained into realistic attack paths |
| SOC 2 / ISO 27001 evidence | ◑ Accepted by some auditors | ✓ Accepted universally |
A misconfiguration review tells you what's configured wrong. A penetration test tells you what an attacker could actually do with it. For most organisations, both are useful and serve different purposes the misconfiguration review is a sensible baseline; the penetration test is required for compliance evidence and realistic risk understanding.
AWS, Azure & GCP Penetration Testing Rules
What each provider's policy actually allows and what requires pre-authorisation:
Amazon Web Services (AWS)
AWS's Customer Support Policy for Penetration Testing permits testing of your own AWS resources without prior approval for most services EC2, RDS, CloudFront, API Gateway, Lambda, and Lightsail included. What requires explicit written authorisation: simulated DDoS, DNS zone walking against Route 53, and port/protocol flooding. What is prohibited entirely: testing resources belonging to other AWS customers, and anything resembling a denial-of-service attack against AWS infrastructure itself. The core rule: you can test your cloud environment, not the underlying AWS infrastructure.
Microsoft Azure
Azure's Penetration Testing Rules of Engagement allow customers to test their own Azure resources without prior notification for most test types. Prohibited: social engineering against Microsoft employees, physical security testing of datacentres, and automated scanning of infrastructure outside your own tenant. For engagements involving significant traffic generation or patterns that could affect other tenants, Microsoft's Penetration Testing Notification Form is recommended even where not strictly required it creates a paper trail protecting the engagement.
Google Cloud Platform (GCP)
GCP does not require prior approval for penetration testing of your own resources and has no formal notification process. Testing must comply with Google's Acceptable Use Policy and Terms of Service. The constraint: testing must stay within your own project and organisation. GCP is the least restrictive of the three major providers for customer-initiated testing.
The practical takeaway: all three providers allow you to test your own cloud resources. A reputable cloud penetration testing provider scopes every engagement within these rules by default if a provider hasn't raised ToS compliance in the scoping conversation, ask explicitly.
What Cloud Penetration Testing Covers
IAM and privilege escalation. The highest-impact finding category in cloud environments. Testing evaluates whether any IAM role, user, or service account can be used to escalate to administrator-level access through permission combinations, trust relationships, or policy misconfigurations. Common paths: iam:PassRole abuse, sts:AssumeRole without sufficient conditions, Lambda execution roles with excessive permissions, and EC2 instance profiles granting broader access than the instance needs. A single over-permissioned role can represent a full account takeover path.
Storage and data exposure. S3 buckets, Azure Blob containers, and GCS buckets that are publicly accessible or accessible to any authenticated cloud account. Testing includes enumerating storage accessible from the attacker's starting position, checking bucket policies and ACLs, identifying sensitive data stored without appropriate access controls, exposed database snapshots, and misconfigured data warehouses.
Network and perimeter security. Security group and firewall rule analysis, VPC configuration, exposed management interfaces (SSH, RDP, database ports open to 0.0.0.0/0), and network ACL gaps. Over-permissive security groups are among the most consistently found cloud issues often because they were opened during development and never tightened.
Serverless and container security. Lambda function permissions, environment variable exposure (credentials in function config), API Gateway authentication gaps, ECS/EKS cluster security, container image vulnerabilities, and Kubernetes RBAC misconfigurations. Container environments have their own privilege escalation paths breaking out of a container to the underlying node, or abusing Kubernetes service account tokens to move laterally within a cluster.
Secrets and credential management. Credentials hardcoded in Lambda environment variables, EC2 user data, CloudFormation templates, or accessible through the metadata service. Testing also covers Secrets Manager and Parameter Store access who can read production secrets, and whether that access is scoped correctly.
Logging and detection gaps. CloudTrail, Azure Monitor, and GCP Cloud Audit Logs configuration are critical API calls being logged, are logs protected from tampering, and do alert rules actually fire on the attacker techniques used in the engagement? This component links directly to SOC 2 CC7.1 and ISO 27001 A.8.16 evidence requirements.
SSRF to Cloud Metadata: How Serious Is It?
Server-Side Request Forgery (SSRF) vulnerabilities in cloud-hosted applications are categorically more dangerous than the same vulnerability in an on-premise environment. Here's why and what the actual attack path looks like.
Every major cloud provider runs an instance metadata service accessible from within the compute instance on a link-local address (169.254.169.254 on AWS and Azure, metadata.google.internal on GCP). This service provides instance configuration, network information, and critically temporary IAM credentials for the role attached to the instance.
SSRF identified in web application
Any parameter that causes the server to make an outbound HTTP request URL fields, webhook configurations, image fetch endpoints, PDF generators. The tester confirms SSRF by making the server request an attacker-controlled host.
Metadata endpoint queried
The SSRF is redirected to the instance metadata service.
http://169.254.169.254/latest/meta-data/iam/security-credentials/
On IMDSv1 (no session token required), this returns the instance role name directly. IMDSv2 requires a session token but SSRF can chain an additional PUT request to obtain it.
Temporary IAM credentials extracted
The metadata service returns temporary AWS credentials — AccessKeyId, SecretAccessKey, and SessionToken valid for the session duration, carrying the exact permissions of the EC2 instance role.
Lateral movement and privilege escalation
The attacker configures the AWS CLI with stolen credentials and operates as that IAM role. If the role has broad permissions common where instance roles weren't scoped to least privilege this means access to S3, RDS, other services, and potentially paths to assume admin roles. A single SSRF can lead to full account compromise.
How serious is it? SSRF-to-metadata is rated Critical in almost every cloud pentest that produces it. The fix has two parts: enforce IMDSv2 (requires a session token, making pure SSRF exploitation harder) and ensure EC2 instance roles are scoped to the minimum permissions the instance actually needs.
Questions Teams Actually Ask
"Do we need a separate cloud pentest, or does it come with the web app test?"
It depends on scope. A web app pentest that includes SSRF testing will follow that finding to the metadata endpoint and document it that's the overlap. But IAM enumeration, privilege escalation testing, storage bucket access review, cross-service lateral movement, and logging/detection validation are not part of a standard web app pentest scope. They require cloud-native tooling, cloud provider API access, and a tester who understands IAM policy logic and cloud-specific attack paths. If your cloud environment is in scope for your compliance audit (SOC 2, ISO 27001), it needs either a dedicated cloud assessment or an explicitly expanded web app pentest scope.
"What's the difference between a misconfiguration review and a cloud penetration test?"
See the comparison table above. Short version: a misconfiguration review identifies configuration weaknesses; a penetration test exploits them. A misconfiguration review is typically faster and gives a broad picture of your posture. A penetration test produces exploit evidence showing what an attacker could actually do. For compliance evidence, auditors prefer penetration test results. For a first-time cloud security engagement, a misconfiguration review is often the right starting point followed by a penetration test before your next audit.
"We're on Azure — do we need a separate cloud pentest?"
Yes, if Azure is in scope for your compliance framework or if your application's data sits in Azure-managed services. Azure has its own identity layer (Entra ID), its own privilege escalation paths (Azure RBAC, Managed Identity abuse, App Registration over-permissioning), and its own metadata service. A web app pentest scoped to application endpoints doesn't test any of that. Azure-specific attack surfaces Managed Identity credential extraction via SSRF, Azure AD service principal abuse require dedicated cloud assessment methodology.
What a Cloud Pentest Report Contains
A cloud penetration test report that satisfies compliance audit requirements has specific components. Before selecting a provider, ask for a redacted sample and check for these:
Executive summary with cloud-specific context. The risk narrative should explain cloud attack paths in terms a CISO or board can understand. "An attacker who compromised our web application could have obtained IAM credentials providing read access to our entire S3 data store" is more actionable than "SSRF vulnerability identified."
IAM findings with policy evidence. Any privilege escalation finding should include the specific IAM policies involved, the escalation path documented step by step, and evidence of what access level was achieved. CLI output or console screenshots confirming the escalated access are the expected standard of evidence.
Attack chain mapping. The report should connect findings that individually rate as medium severity but combine into a critical attack path. A public S3 bucket containing a config file with database credentials, combined with a database instance with an overly permissive security group, is a critical chain even if each component was medium individually.
Logging and detection findings. What attacker activity was logged, what wasn't, and what should be. For SOC 2 CC7.1 and ISO 27001 A.8.16, evidence that your logging captured (or missed) test activity is important audit evidence in itself.
Cloud-provider-specific remediation. Not "fix the IAM permissions" specifically: add a condition key to the sts:AssumeRole policy, enable IMDSv2 at the account level, restrict the Lambda execution role to the specific S3 bucket path it needs. Your cloud engineering team acts directly on this.
Retest evidence. Critical and high findings retested after remediation, with updated report sections confirming resolution. This closes the loop for SOC 2 and ISO 27001 auditors and demonstrates the assessment produced measurable improvement.
Get a Cloud Security Assessment
Related reading:
- Cloud Security Services
- Penetration Testing Services
- Web Application Penetration Testing Guide
- API Penetration Testing Guide
- SOC 2 Penetration Testing Requirements
- ISO 27001 Penetration Testing Requirements
Cloud Penetration Testing, AWS Penetration Testing, Azure Penetration Testing, GCP Security Testing, Cloud Security Assessment, IAM Privilege Escalation, SSRF AWS Metadata, Cloud Misconfiguration Review, AWS Security Testing, Cloud Pentest SOC 2
Tags
About Babar Khan Akhunzada
Babar Khan Akhunzada is Founder of SecurityWall. He leads security strategy, offensive operations. Babar has been featured in 25-Under-25 and has been to BlackHat, OWASP, BSides premiere conferences as a speaker.