Why Cloud Pentesting Requires a Different Approach
Traditional penetration testing methodology (scan, enumerate, exploit, escalate) doesn't translate directly to cloud environments. There are no open ports to scan on IAM policies. You can't run Nmap against an S3 bucket configuration. The attack surface is fundamentally different: it's configuration, identity, and API-driven rather than network and application-driven.
This post outlines a structured methodology for cloud penetration testing that accounts for these differences, with specific techniques for AWS, Azure, and GCP.
Context decides more than tooling
The biggest difference between a mediocre cloud test and a good one is not the toolset, it is context. Two kinds matter. The first is your own grounding in the provider: which services are in play, how their identity controls interact, and where they are commonly abused. The second is the client's context: what the workload actually does, what data it holds, which systems it talks to, and the regulatory or business constraints that shape its risk. Miss either and you will raise false positives or misjudge severity, which is the fastest way to lose a client's trust.
The mechanics reinforce the point. There are no IP ranges to sweep and no ports to knock on. You usually begin from a single credential, work out what it can do (sometimes blind), then hunt for the resource identifiers you need to make an API call at all, in an environment that may be shifting under you. Progress comes from building a mental model of the account, not from a scan. Many engagements are framed as assumed breach, starting from a realistic foothold such as a compromised developer, a workload instance, or a third-party principal, and asking how far that foothold reaches.
Phase 1: Cloud-Specific Reconnaissance
Cloud reconnaissance discovers the target's cloud footprint using passive techniques before any active engagement with infrastructure begins, yielding high-value information about which providers are in use and what services they operate.
DNS and subdomain enumeration reveals cloud service usage. Subdomains resolving to AWS CloudFront distributions, Azure Front Door endpoints, or GCP load balancers indicate which providers are in use. CNAME records pointing to S3 buckets, Azure Blob Storage, or GCS buckets identify storage services that may be misconfigured.
Certificate transparency logs expose subdomain patterns that DNS enumeration might miss. Organizations frequently issue certificates for internal-facing cloud services that leak naming conventions, environment identifiers, and service architectures.
Public cloud resource discovery targets exposed storage buckets, container registries, and serverless function URLs. Tools like cloud_enum systematically check for resources matching the target's naming patterns across all three major providers.
GitHub and source code analysis remains one of the highest-yield reconnaissance techniques. Developers frequently commit cloud credentials, service account keys, connection strings, and infrastructure-as-code files that expose the entire cloud architecture. Searching for the organization's domain, known employee names, and common cloud configuration filenames produces results more often than most teams expect.
Phase 2: Initial Access Vectors
Initial access to cloud environments typically comes through one of several vectors, each requiring different exploitation techniques and establishing varying privilege levels from which enumeration proceeds.
Exposed credentials, whether from source code repositories, public configuration files, or credential stuffing attacks, provide the most direct access path. The key skill isn't finding the credential; it's quickly determining what access it grants. An AWS access key might belong to an IAM user with AdministratorAccess, or it might be scoped to a single S3 bucket. The enumeration phase determines the value of the initial access.
Web application vulnerabilities on cloud-hosted applications serve as entry points, particularly SSRF (Server-Side Request Forgery). An SSRF vulnerability on an EC2 instance can reach the metadata service at 169.254.169.254 and retrieve IAM role credentials. On Azure, the same technique targets the Instance Metadata Service for managed identity tokens. GCP's metadata server at metadata.google.internal serves a similar purpose.
Federated identity abuse targets the trust relationships between identity providers and cloud accounts. Misconfigured SAML assertions, overly permissive OIDC trust policies, or compromised identity providers provide access that bypasses cloud-native authentication entirely.
Phase 3: IAM Enumeration and Privilege Escalation
Once initial access is established, the methodology diverges significantly by cloud provider. Each implements fundamentally different identity models requiring distinct enumeration and escalation approaches.
AWS IAM enumeration focuses on understanding the effective permissions of the compromised principal. The iam:GetUser, iam:ListAttachedUserPolicies, and iam:ListUserPolicies calls reveal directly attached permissions. But effective permissions also include group memberships, permission boundaries, session policies, and resource-based policies, all of which require additional enumeration.
AWS privilege escalation paths are well documented, most comprehensively in pathfinding.cloud, Datadog Security Labs' library of AWS IAM privilege escalation paths, and AWS itself warns that a broad iam:PassRole grant opens the possibility of unintended privilege escalation: iam:CreateAccessKey on other users, iam:PassRole combined with service creation permissions, lambda:CreateFunction with iam:PassRole, and many others. The key is recognizing which combinations of permissions enable escalation, not just memorizing individual dangerous permissions.
Azure RBAC and Entra ID enumeration requires understanding both the Azure resource hierarchy (management groups, subscriptions, resource groups, resources) and the Entra ID directory. A user might have limited Azure RBAC roles but significant Entra ID permissions, or vice versa.
Azure privilege escalation often involves Entra ID rather than Azure RBAC directly. Techniques include dynamic group abuse, application consent attacks, administrative unit manipulation, and exploiting custom role definitions with overly permissive action wildcards.
GCP IAM operates on a different model: permissions are bound to roles, roles are bound to members at various hierarchy levels (organization, folder, project, resource). GCP's IAM enumeration requires checking bindings at each level and understanding how permissions inherit downward through the hierarchy.
GCP-specific escalation paths include exploiting service account impersonation (iam.serviceAccounts.getAccessToken), deploying Cloud Functions with high-privilege service accounts, and abusing owner permissions that grant full project control including IAM policy modification.
Phase 4: Lateral Movement
Cloud lateral movement bypasses network-based pivoting entirely, instead moving between identities, services, and accounts through API-driven access and stored credentials.
Service account key discovery, finding keys stored in environment variables, configuration files, or metadata, provides pivot points to other services and potentially other projects or accounts. Cross-account role assumption in AWS, cross-subscription access in Azure, and cross-project service account impersonation in GCP all enable movement beyond the initial access scope.
Shared storage is another lateral movement vector. S3 buckets, Azure Storage accounts, and GCS buckets frequently contain credentials, configuration files, or application data that enables access to additional services.
Phase 5: Impact Demonstration
Cloud pentesting impact isn't about popping shells. It's about demonstrating business risk through concrete access to sensitive resources, data exposure, or infrastructure modification.
Accessing production databases, exfiltrating sensitive data from storage services, modifying infrastructure-as-code pipelines, or achieving persistent access through backdoored IAM policies demonstrates the real consequences of the identified weaknesses. The most compelling findings connect technical access to business impact: "We accessed the production customer database containing 2M records through an exposed service account key found in a public GitHub repository" tells a clearer story than "We achieved AdministratorAccess in the AWS account."
Scoping and Authorization in the Cloud
Cloud penetration testing has an authorization problem that traditional testing does not. The infrastructure belongs to the provider, the account belongs to the client, and the applications may involve third parties, so agreeing what is in scope requires naming accounts and subscriptions rather than IP ranges.
Each major provider publishes a policy on what customers may test without prior approval, and those policies have relaxed considerably over the past several years. Most permit testing of your own resources while prohibiting anything that affects the shared platform, such as denial of service against provider infrastructure or testing services you do not own. Read the current policy rather than relying on what was true a few years ago.
The practical scoping question is which identities the test starts from. An assessment beginning with no credentials answers a different question from one beginning with a low privilege user, and the second usually produces more findings per day because it reflects how real intrusions actually begin.
Two habits keep the engagement safe. Give the test read-only access across every in-scope account or subscription, even when the exercise starts from a single identity, because broad read access speeds up enumeration and mapping without changing anything. And stay conservative on action: default to read-only calls, prove destructive techniques in your own environment rather than the client's, only check the validity of any credentials you find rather than using them, and get explicit permission before running an exploit. Where you cannot confirm an issue safely, say so in the report and explain why.
What Good Cloud Pentest Reporting Looks Like
A finding that says an IAM role is over-permissioned tells a client nothing they can act on. A finding that says this specific role can reach production data through two impersonation hops, and here is the sequence, gets fixed.
Cloud findings benefit from being expressed as paths rather than as issues, because the individual permissions are usually defensible in isolation and the risk lives in the composition. Showing the chain also makes remediation obvious, since breaking any single link resolves it and the client can choose the cheapest one.
Include the detection question alongside each finding. Whether the client's logging would have shown the activity is frequently more valuable than the finding itself, and it is the part that turns a penetration test into an improvement in defensive capability rather than a list to remediate.
Scoring cloud findings takes judgment. Automated configuration and posture tooling is a useful first pass across every account, but its output is noisy, and pasting it into a report unfiltered destroys trust. Filter it through context, set aside what the client cannot or will not act on, and go manual for what the tools miss, identity above all. Severity is where cloud work strains a raw CVSS number, which was never built for misconfigurations and skews badly when a test starts from an assumed foothold. A likelihood-times-impact matrix that can weigh business, operational, and regulatory consequences usually communicates cloud risk more honestly, as long as the tester can explain the reasoning behind each rating.
Building Cloud Pentesting Proficiency
Cloud pentesting skills develop through structured practice in realistic environments that present genuine technical complexity rather than simplified exercises. Reading about SSRF-to-metadata-service exploitation differs fundamentally from executing it against running instances, troubleshooting token formats, and determining what stolen credentials can access.
Practitioners should look for training environments that present connected scenarios across multiple cloud services, require genuine enumeration rather than providing breadcrumbs, and cover the full methodology from reconnaissance through impact demonstration. Pwned Labs' bootcamps (ACRTP for AWS, MCRTP for Azure and Microsoft 365, GCRTP for GCP) implement this complete methodology in hands-on environments. The field moves quickly, and techniques that worked six months ago may be mitigated by new default security configurations, so current, actively maintained training is essential.
Bottom Line
Cloud penetration testing requires a fundamentally different methodology from network-focused traditional pentesting: cloud-specific reconnaissance reveals infrastructure through DNS/certificate logs/source code, initial access typically comes through exposed credentials or SSRF to metadata services, and IAM enumeration differs significantly across AWS (permission-based), Azure (RBAC + Entra ID), and GCP (hierarchy-based models). Lateral movement happens through service chains and stored credentials rather than network pivoting, and impact demonstration focuses on business risk tied to data access or infrastructure modification. Proficiency develops through structured practice in production-like environments that present connected scenarios across multiple cloud services and require both offensive execution and understanding of current provider configurations.