A financial services company commissioned a penetration test of their AWS environment in 2022. The testers found an EC2 instance with an IAM instance profile attached — the role looked low-privileged.
Its policy allowed one action: iam:PassRole. That single permission, overlooked because it did not sound dangerous, allowed the testers to pass any role in the account to any service. They used it to pass an AdministratorAccess role to a Lambda function they created, invoked the function, and had full account control within four minutes of their first API call. Total time from "low-privileged EC2 instance" to "root-equivalent cloud admin": seven minutes.
Cloud penetration testing is a fundamentally different discipline from traditional network penetration testing. The attack surface is largely built from misconfigured IAM policies, exposed storage objects, over-permissive service accounts, and exploitable trust relationships between cloud services — not from network-reachable services with known CVEs.
The tools are different, the methodology is different, and critically, the legal requirements are different: most cloud providers have specific policies about what testing activities require advance notification and what is prohibited entirely.
This guide covers the complete cloud penetration testing methodology for AWS, Azure, and GCP — the legal requirements for each provider, the phases from reconnaissance through post-exploitation, the specific misconfigurations and attack chains that most often produce critical findings, the tooling used by professional cloud security testers in 2026, and how to scope, report, and remediate findings.
- Cloud vs traditional penetration testing — key differences
- Legal requirements — AWS, Azure, and GCP policies
- Scoping a cloud pentest engagement
- Cloud pentest methodology — six phases
- AWS attack techniques — IAM, S3, EC2, and privilege escalation
- Azure and Entra ID attack techniques
- GCP attack techniques
- Cloud penetration testing toolchain
- Reporting cloud pentest findings
- Frequently asked questions
Traditional network penetration testing focuses on discovering and exploiting vulnerabilities in network-reachable services — open ports, outdated software with CVEs, weak network configurations. Cloud penetration testing focuses on a different attack surface entirely.
In traditional pentesting, the primary attack surface is network services — web applications, databases, SMB shares, RDP endpoints. In cloud environments, the primary attack surface is IAM — permissions, roles, policies, service accounts, and trust relationships between cloud services. A cloud attacker with low-privileged API credentials can do more damage than a traditional attacker with network access to most of the infrastructure, if the IAM configuration is weak enough. The most critical skill in cloud penetration testing is reading and reasoning about IAM policies — understanding what each permission allows, what combinations create privilege escalation paths, and what the attacker can chain together.
Cloud attacks are almost entirely conducted via cloud provider APIs — the same APIs administrators use to manage infrastructure. The attacker uses stolen credentials or tokens to call AWS/Azure/GCP API endpoints. There is no port scanning of cloud-native services, no exploitation of network-layer vulnerabilities in managed services like S3 or Lambda. The "exploit" is an API call with valid credentials and a misconfigured permission that allows more than intended.
Cloud penetration testers cannot test the cloud provider's own infrastructure — only the customer's deployment within the cloud. You cannot test AWS's S3 service itself; you test whether your S3 bucket configuration allows unintended access. This boundary is both a legal requirement and a logical one — the customer is responsible for their configuration, not for the provider's infrastructure security.
In traditional pentesting, a common path to compromise involves exploiting a known CVE in an outdated service. In cloud pentesting, the dominant finding category is misconfiguration — a bucket policy that permits public reads, an IAM role that allows privilege escalation, an EC2 instance with IMDSv1 enabled that allows SSRF-based credential theft, a storage account with public blob access. These are not software vulnerabilities; they are configuration errors that require no exploitation code.
| Aspect | Traditional network pentest | Cloud penetration test |
|---|---|---|
| Primary attack surface | Network-reachable services, open ports, web apps | IAM policies, storage permissions, service configurations, API credentials |
| Initial access | Service exploits, web app vulns, weak credentials on exposed services | Exposed credentials, public storage, SSRF to metadata API, misconfigured SSO |
| Privilege escalation | Local exploits, kernel vulns, misconfigs (sudo, SUID) | IAM privilege escalation via iam:PassRole, iam:CreateRole, iam:AttachRolePolicy, etc. |
| Lateral movement | Network scanning, credential reuse, SMB, RDP | Cross-service trust exploitation, role chaining, instance profiles, federated identity abuse |
| Primary tooling | Nmap, Metasploit, Burp Suite, Mimikatz | Pacu, ScoutSuite, Prowler, CloudMapper, ROADtools, aws-cli |
| Legal complexity | Standard Rules of Engagement with the target organisation | Standard RoE PLUS cloud provider-specific penetration testing policies |
| Finding type | Mostly CVEs, known vulns, protocol weaknesses | Mostly misconfigurations, logic flaws, privilege escalation chains |
The penetration tester must have explicit written authorisation from the legal owner of the cloud accounts being tested — not just verbal permission from an IT contact. For AWS, this means the account owner (the entity whose credit card is on the account). For shared cloud environments (multiple tenants), the scope must clearly define which accounts and resources are in-scope. Written authorisation must specify: the scope of testing, the duration, the testing methods permitted, and the contact to notify in case of unexpected findings.
The RoE document supplements the written authorisation with operational details: testing hours (cloud testing often runs 24/7 but business impact should be confirmed), emergency stop procedures (who to call and how fast they respond if production is impacted), out-of-scope items (specific accounts, specific services, shared infrastructure with third parties), data handling (what to do with sensitive data discovered during testing), and reporting timeline.
If the target environment hosts services from third parties — a SaaS provider running on AWS, a managed services provider's shared infrastructure — those third parties may need to be notified or provide separate authorisation. Testing infrastructure shared between your client and other tenants without those tenants' knowledge violates the cloud provider's terms and may expose testers to computer fraud liability.
The tester starts with only the organisation name and public-facing infrastructure. This tests external attack surface: public S3 buckets, exposed APIs, publicly accessible cloud storage, and OSINT-discoverable cloud misconfigurations. This is the scenario where an external attacker has no inside knowledge. Black box cloud tests are useful for finding externally visible misconfigurations but miss the majority of cloud security issues, which require internal access to discover. Most cloud providers do not expose the internal IAM configuration publicly — a black-box tester cannot see that an IAM role is over-permissive until they have credentials.
The most realistic and valuable cloud pentest scenario. The tester receives the credentials of a low-privileged IAM user — simulating what an attacker would have after compromising an employee's credentials, finding a leaked access key in a public repository, or obtaining access through a web application vulnerability. From here, the tester attempts to enumerate the environment, identify privilege escalation paths, and achieve the most significant compromise possible. This tests the organisation's IAM design, least privilege implementation, and detection capabilities simultaneously.
The tester receives administrative or near-administrative access to review the full configuration — IAM policies, resource configurations, network topology, logging configuration, and security controls. This is a configuration review rather than a penetration test — systematic evaluation of every security control against best practices. White box assessments are faster, more comprehensive, and better suited to compliance evidence gathering, but do not test whether an attacker could actually exploit the findings.
The tester starts with credentials representing a specific compromised identity — "assume this EC2 instance profile has been compromised" or "assume these Lambda execution role credentials have been stolen." This tests the blast radius of a specific credential compromise. Particularly useful for testing whether the principle of least privilege has been correctly implemented: if the compromised role can only do what it is supposed to do, the assumption of breach cannot escalate further.
Before touching any cloud API, map the external attack surface — what is visible to an unauthenticated attacker from the internet.
- Public S3 bucket enumeration — enumerate bucket names using permutation wordlists (company-name, company-name-backup, company-name-prod, company-name-logs, etc.) and check for public access. Tools: cloud_enum, s3scanner, bucket_finder.
- GitHub/GitLab secret scanning — search public repositories for hardcoded AWS access keys, Azure client secrets, GCP service account JSON files. Tools: truffleHog, gitleaks, git-secrets. Search for the organisation name plus common credential patterns.
- Certificate Transparency logs — query crt.sh for subdomains that may reveal cloud-hosted services. Cloud storage subdomains, API gateways, and CloudFront distributions visible in CT logs.
- Shodan / Censys — search for cloud IP ranges hosting the target's infrastructure. Find exposed management interfaces, development servers, and misrouted cloud services.
- DNS enumeration — identify cloud provider CNAME targets (*.s3.amazonaws.com, *.blob.core.windows.net, *.storage.googleapis.com) that may reveal storage endpoints and services.
- Job postings and LinkedIn — identify the cloud technologies in use. A job posting for "AWS EKS administrator" reveals the container platform; "Terraform with AWS" reveals IaC tooling. This intelligence informs the attack surface later.
With credentials in hand (whether found during reconnaissance or provided in a grey-box engagement), systematically enumerate the environment. The goal is building a complete picture of what exists, what is accessible, and what the current identity can see.
- Identity enumeration — determine who the current identity is, what policies are attached, what groups it belongs to, and whether it can enumerate other users and roles.
- Resource enumeration — list EC2 instances, S3 buckets, Lambda functions, RDS instances, EKS clusters, IAM users and roles across all in-scope regions.
- Configuration review — run automated tools (ScoutSuite, Prowler, Pacu's enumeration modules) to collect configuration data across all services simultaneously.
- Trust relationship mapping — identify IAM roles with trust policies that allow assumption by other services, accounts, or external entities. These are privilege escalation and lateral movement vectors.
Analyse enumeration output to identify specific exploitable conditions. In cloud environments, this means looking for:
- IAM privilege escalation paths — permissions that allow creating more powerful roles, attaching policies, or passing roles to services. Use cloudsplaining and PMapper to map privilege escalation paths automatically.
- Publicly accessible storage — S3 buckets, Azure Blob containers, or GCS buckets accessible without authentication. Check content for credentials, configuration files, and sensitive data.
- Instance metadata API exposure — EC2 instances with IMDSv1 enabled that are reachable via SSRF in web applications hosted on those instances.
- Overly permissive cross-account roles — IAM roles with trust policies that allow assumption from any account or broad external principals.
- Secrets in environment variables — Lambda functions, ECS task definitions, and EC2 user data containing hardcoded credentials.
- Unencrypted sensitive resources — RDS snapshots, EBS snapshots shared publicly, unencrypted S3 buckets containing sensitive data.
Exploit identified vulnerabilities to demonstrate real-world impact. Cloud exploitation is primarily API-call based — no shellcode, no buffer overflows. The "exploit" is calling an API with valid credentials and a permission that allows more than intended. Document every API call made during exploitation for the report.
- IAM privilege escalation — chain together available permissions to escalate to AdministratorAccess. Common paths: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction, or iam:CreatePolicyVersion, or ec2:RunInstances with a high-privileged instance profile.
- SSRF to credential theft — exploit SSRF in a web application to reach the EC2 instance metadata service (169.254.169.254) and retrieve the instance profile credentials. With IMDSv1 enabled, this is a simple HTTP GET with no token required.
- Public storage data access — access and exfiltrate data from publicly accessible storage to demonstrate the real content exposed.
- Cross-account role assumption — assume a role in the target account from a tester-controlled account if the role trust policy permits it.
Once elevated access is achieved, demonstrate the maximum attainable blast radius from that position. Do not cause actual damage — demonstrate the capability and document the evidence.
- Persistence mechanisms — demonstrate how an attacker could maintain access: creating a backdoor IAM user, adding a new trusted account to a role's trust policy, creating a Lambda with a scheduled trigger.
- Lateral movement across services — use admin IAM access to enumerate all resources across all regions. Access databases, read S3 content across all buckets, review Secrets Manager and SSM Parameter Store for additional credentials.
- Cross-account movement — if the compromised account has assume-role permissions to other accounts, enumerate accessible accounts and attempt to pivot.
- Data exfiltration simulation — list sensitive data (do not actually exfiltrate customer data) and document what an attacker could copy: database contents, application secrets, encryption keys, configuration files.
- Detection evasion evidence — assess whether GuardDuty and CloudTrail alerts were triggered during the test. Findings that avoided detection indicate detection gaps to address.
After testing, remove all artefacts created during the engagement and deliver the report. Cloud testing cleanup is critical — any IAM users, roles, Lambda functions, or EC2 instances created during testing must be deleted. A forgotten backdoor IAM user created to demonstrate persistence becomes a real backdoor.
If an identity has these three permissions, they can escalate to any role they can pass. Create a Lambda function, pass a high-privileged role as its execution role, invoke the function, and receive back the credentials or the output of any API call made as that role.
If the current identity can create new versions of an existing IAM policy, they can modify that policy to grant themselves AdministratorAccess — even if the policy currently grants limited permissions. Create a new policy version with Action: "*", Resource: "*" and set it as default.
If a web application running on an EC2 instance is vulnerable to SSRF and the instance uses IMDSv1, the attacker can reach the metadata service at 169.254.169.254 and retrieve the instance profile credentials — giving them whatever permissions the instance profile has.
- Overly permissive Storage Account access — containers with Blob (public read) or Container (public list + read) access level
- No MFA for Entra ID users — accounts reachable via password spray or credential stuffing without MFA challenge
- Password spraying via legacy authentication — Basic Auth and legacy protocols bypass Conditional Access MFA requirements; often left enabled for older applications
- Service Principal with Owner role at subscription level — excessive permissions for application identities that should have narrow scope
- Key Vault accessible from all networks — should be restricted to specific virtual networks or private endpoints
- Unrotated client secrets — application registrations with secrets that have not been rotated in years and may be discovered in leaked code
- Service account with Editor or Owner role at project level — the most common GCP privilege escalation finding. Editor grants read/write on nearly all services; Owner grants IAM management.
- Service account key files in source code — GCP service account keys are JSON files that developers often commit to repositories. Unlike AWS access keys, they do not expire automatically.
- allUsers access on GCS buckets — grants read (or sometimes write) to anyone on the internet. Check for sensitive data including service account key files stored in the bucket.
- Compute Engine instances with default service account — GCP creates a default service account for Compute Engine instances. If left at default, it has Editor access to the project — equivalent of running every EC2 instance as a project admin.
- No organisation policy constraints — GCP Organisation Policies can enforce controls (e.g. prevent public IPs on VMs, restrict domain identities) but are often not configured.
| Tool | Cloud | Category | What it does | Licence |
|---|---|---|---|---|
| Pacu | AWS | Exploitation framework | Modular AWS exploitation framework — enumeration, privilege escalation, persistence, defence evasion. 40+ modules. | Open-source (BSD) |
| ScoutSuite | AWS, Azure, GCP, Alibaba | Configuration review | Multi-cloud security auditing tool. Collects configuration data from all services and generates interactive HTML report with findings. | Open-source (GPL) |
| Prowler | AWS, Azure, GCP | Compliance scan | CIS benchmark, AWS FSBP, GDPR, HIPAA, SOC2 checks. 300+ security checks. Excellent for quick posture assessment. | Open-source (Apache) |
| PMapper (Principal Mapper) | AWS | IAM analysis | Graph-based IAM privilege escalation analysis. Finds paths from any identity to AdminAccess. Visualises IAM relationships. | Open-source (Apache) |
| cloudsplaining | AWS | IAM policy analysis | Analyses IAM policies for excessive permissions — data exfiltration risk, resource exposure, credential exposure, infrastructure modification. | Open-source (BSD) |
| cloud_enum | AWS, Azure, GCP | Reconnaissance | Multi-cloud resource enumeration — finds S3 buckets, Azure blobs, GCS buckets, and other storage using wordlist permutations. | Open-source (MIT) |
| ROADtools | Azure / Entra ID | Enumeration | Entra ID (Azure AD) enumeration — users, groups, roles, apps, conditional access, trust relationships. Includes GUI explorer. | Open-source (MIT) |
| AzureHound | Azure | Attack path analysis | BloodHound data collector for Azure/Entra ID. Identifies privilege escalation paths through Azure RBAC and Entra ID roles. | Open-source (Apache) |
| MicroBurst | Azure | Assessment toolkit | Azure security assessment — blob enumeration, password extraction, subdomain discovery, authentication testing. | Open-source (BSD) |
| AADInternals | Azure / M365 | Identity testing | PowerShell module for Azure AD / M365 reconnaissance, authentication testing, backdoor creation, token manipulation. | Open-source (MIT) |
| CloudMapper | AWS | Network visualisation | Generates network diagrams of AWS environments. Identifies publicly exposed resources and network-level misconfigurations. | Open-source (BSD) |
| gitleaks | All | Secret detection | Scans git repositories for hardcoded secrets — AWS keys, GCP service account files, Azure client secrets, API tokens. | Open-source (MIT) |
| trufflehog | All | Secret detection | Deep git history scanning for secrets. Verifies whether discovered credentials are active against the target API. | Open-source (GPL) |
| CloudSploit | AWS, Azure, GCP | Configuration scan | Automated configuration scanning — 500+ checks across cloud services. API-based, no agent. Outputs CSV or JSON. | Open-source (Apache) |
| enumerate-iam | AWS | Permission bruting | Brute-forces which IAM actions the current identity can perform by trying each one. Useful when iam:List* is denied. | Open-source (MIT) |
Standard CVSS scores do not map well to cloud misconfigurations — a misconfigured S3 bucket has no CVE and no network attack vector, but may be Critical severity because it exposes sensitive data publicly. Use a cloud-specific severity framework:
| Severity | Definition for cloud findings | Example findings | Remediation SLA |
|---|---|---|---|
| Critical | Direct path to account takeover or full data exposure without any additional exploitation | Public bucket with credentials; IMDSv1 + SSRF = admin credentials; IAM privesc to AdministratorAccess | 24–48 hours |
| High | Significant data exposure or privilege escalation requiring one additional step | Over-permissive IAM role on EC2; public database snapshot; exposed application secrets | 7 days |
| Medium | Limited data exposure or privilege escalation requiring multiple steps or specific conditions | Missing bucket logging; IMDSv1 enabled (no exploitable SSRF identified); unencrypted EBS volumes | 30 days |
| Low / Informational | Best practice deviation with minimal direct security impact in current context | Access key rotation policy not enforced; CloudTrail not in all regions; MFA not required for non-privileged users | 90 days |
⚡ Getting started with cloud penetration testing
- Build a practice lab in your own AWS free tier account — create a deliberately misconfigured environment using CloudGoat (Rhino Security Labs' vulnerable-by-design AWS environment): pip install cloudgoat && cloudgoat create iam_privesc_by_rollback. This gives you a legal, isolated environment to practise every IAM privilege escalation technique in this article without risk. CloudGoat has 15+ scenarios covering real-world attack paths found in actual engagements.
- Master IAM policy reading before anything else — the most critical cloud pentesting skill is the ability to read an IAM policy and immediately understand what it permits, what it denies, and what privilege escalation paths it creates. Practise with the AWS IAM Policy Simulator and by reading the policies generated by CloudGoat scenarios. IAM guide →
- Run ScoutSuite and Prowler against your own AWS account — if you have any AWS account (even a personal free tier account), run both tools against it. The findings will be educational even if the account has no real data — you will see exactly what misconfiguration looks like from a tester's perspective and understand what you need to fix. AWS security guide →
- Work through flaws.cloud and HackTheBox cloud challenges — flaws.cloud (by Scott Piper) and flaws2.cloud are free, deliberately vulnerable AWS environments designed for learning. Work through each level using only the AWS CLI — this builds the enumeration and exploitation intuition that tools like Pacu automate but that you need to understand at the API level first.
- Understand the legal foundation before any real engagement — bookmark the penetration testing policies for AWS, Azure, and GCP. Read each one completely before touching a client environment. Have written authorisation reviewed by legal counsel for your first few commercial engagements. The rules are straightforward but the consequences of violating them are severe.
Cloud penetration testing is legal when conducted with explicit written authorisation from the cloud account owner against resources they own. All three major providers — AWS, Azure, and GCP — permit testing of your own cloud resources without prior approval (though they prohibit DoS testing, testing other customers' infrastructure, and attacking provider-managed infrastructure). Testing someone else's cloud environment without authorisation — or testing infrastructure shared with other tenants without their consent — violates the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), and equivalent laws globally, regardless of whether the cloud provider permits the activity. Always obtain written authorisation and read each provider's penetration testing policy before beginning any engagement.
For most testing activities against your own AWS resources, no prior notification to AWS is required. AWS permits penetration testing of EC2 instances, RDS databases, CloudFront distributions, API Gateway, Lambda, Lightsail, Elastic Beanstalk, and Fargate resources in accounts you own without advance approval. However, DoS and DDoS testing require a separate request to AWS. Large-scale simulated attacks (flood testing, protocol testing against AWS infrastructure) are prohibited. AWS recommends (but does not require for standard testing) notifying them via their penetration testing request form for large engagements. Always check the current policy at aws.amazon.com/security/penetration-testing as it is updated periodically.
The most consistently found critical findings in cloud penetration tests are: IAM privilege escalation paths (an identity with seemingly limited permissions that can chain API calls to reach AdministratorAccess — particularly via iam:PassRole, iam:CreatePolicyVersion, or iam:AttachRolePolicy); publicly accessible storage containing sensitive data (S3 buckets, Azure Blob containers, or GCS buckets with public access containing credentials, configuration files, or PII); and exposed credentials in public code repositories or EC2 user data (hardcoded access keys, service account JSON files, or database connection strings). IAM privilege escalation is particularly common because permissions that enable it (iam:PassRole, for example) do not immediately appear dangerous to developers unfamiliar with their security implications.
SSRF (Server-Side Request Forgery) is a web vulnerability where an attacker makes the server send requests to internal endpoints on their behalf. In cloud environments, the most valuable SSRF target is the instance metadata service (169.254.169.254 on AWS and Azure, metadata.google.internal on GCP) — a local HTTP endpoint that provides EC2/VM metadata including the temporary IAM credentials associated with the instance's role. With IMDSv1 (the older AWS metadata protocol), any SSRF can reach this endpoint with a simple HTTP GET and retrieve valid AWS credentials. These credentials have whatever permissions the instance role has — often far more than needed. With IMDSv2 (the current AWS default), a PUT request with a token is required first, which most SSRF vulnerabilities cannot perform, breaking the attack chain. Enforcing IMDSv2 is one of the most impactful AWS security controls for web-facing EC2 instances.
The core cloud pentesting toolchain in 2026: Pacu (AWS exploitation framework — modular, covers enumeration through post-exploitation), ScoutSuite (multi-cloud configuration review — generates HTML report across all services), Prowler (compliance-focused scanning — CIS, FSBP, PCI, HIPAA checks), PMapper/cloudsplaining (IAM privilege escalation path analysis), ROADtools and AzureHound (Azure/Entra ID enumeration and attack path mapping), MicroBurst (Azure assessment toolkit), gitleaks and trufflehog (secret detection in code repositories), and cloud_enum (public storage enumeration across AWS, Azure, and GCP). All of these tools are open-source and free. The AWS CLI, Azure CLI, and gcloud CLI are also fundamental — many findings require manual API calls that no automated tool covers.
A cloud security audit (or configuration review) systematically evaluates every security control against a standard (CIS Benchmark, AWS FSBP, NIST CSF) using tools like ScoutSuite, Prowler, and Security Hub. It produces a comprehensive list of configuration deviations with severity ratings. A cloud penetration test goes further — it attempts to actually exploit identified misconfigurations to prove they are exploitable and demonstrate real-world impact. The pentest answers "can an attacker actually get to AdministratorAccess from this misconfiguration?" while the audit answers "does this misconfiguration exist?" Both are valuable: audits are faster and more comprehensive; pentests provide proof of exploitability that drives faster remediation. For compliance evidence, audits are typically more useful; for board-level risk communication, a pentest that shows "we obtained admin access in 23 minutes" is more compelling.