Cloud accounted for 39% of vulnerability volume but only 14% of penetration testing engagements, leaving it under-tested by roughly 3x relative to its share of findings, according to a 2026 state-of-pentesting report. That gap changes the question. A penetration testing cloud environment engagement isn't a port scan against virtual machines. It's an authorized examination of identity, provider rules, APIs, managed services, workloads, and trust relationships that can cross AWS accounts, Azure subscriptions, and GCP projects.
The practical risk is also moving faster than conventional testing coverage. The same report describes cloud-origin vulnerabilities rising from about 60,000 to 2.6 million in 2025, a 44x increase, while cloud testing coverage rose only 1.23x over the same period. Cloud tests also produced an average of 7,480 findings per engagement, compared with 3,060 for web testing, meaning cloud engagements generated about 2.4x more findings per engagement.
A useful assessment therefore combines legal authorization, identity analysis, attack-path validation, evidence handling, and continuous retesting. The seven phases below follow that reality: scoping, threat modeling, reconnaissance, exploitation, post-exploitation, evidence and reporting, and CI/CD integration.
Table of Contents
- Why Cloud Pentesting Needs a Different Playbook
- Scoping and Authorization Across AWS Azure and GCP
- Cloud-Native Threat Modeling for Multi-Cloud Estates
- Reconnaissance and Enumeration in Cloud Environments
- Exploitation and Post-Exploitation on Cloud Control Planes
- Evidence Collection and Compliance-Mapped Reporting
- CI/CD Integration and Continuous Cloud Pentesting
Why Cloud Pentesting Needs a Different Playbook
Traditional infrastructure testing starts with reachable hosts, exposed ports, vulnerable services, and operating-system compromise. That approach still has value, but cloud estates place the most important trust decisions in the control plane. An attacker may never need a shell if a compromised role can read secrets, assume another role, deploy a function, alter a pipeline, or access a storage data plane.
Cloud penetration testing has also become a distinct market rather than a minor extension of network assessment. A 2026 market analysis projects cloud penetration testing to grow at a 16.63% CAGR through 2031, while the broader penetration testing market is projected to rise from USD 2.36 billion in 2025 to USD 5.54 billion by 2031. The same analysis projects cloud-based platforms to grow at a 15.61% CAGR, even though on-premises deployment held 59.21% share in 2025. Those projections reflect a mixed delivery model, not the disappearance of infrastructure testing.
The perimeter is an identity graph
A generic VLAN-oriented playbook usually asks which systems respond to network probes. A cloud playbook asks different questions:
- Who can authenticate? Include federated users, service principals, workload identities, CI runners, break-glass accounts, and third-party integrations.
- What can each identity do? Review permissions, conditions, resource policies, role assignments, and inherited access.
- Where can access move? Trace cross-account roles, subscription boundaries, project hierarchies, Kubernetes identities, serverless execution roles, and data-plane permissions.
- What detects the path? Confirm that CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs, workload telemetry, and alerting capture meaningful actions.
A telemetry-based analysis reported weak IAM controls and missing logging or alerting across 80% to 98% of cloud accounts. Its practical implication is more important than the range itself: a pentester should treat identity and visibility as primary attack surfaces, not as configuration appendices. The analysis of cloud account misconfiguration patterns also supports starting with external discovery, credential and role enumeration, privilege-escalation path testing, and revalidation.
Practical rule: If the test scope names only IP ranges, it probably doesn't describe the cloud attack surface.
The engagement should connect legal review to technical execution. Before sending a request, define what can be tested, then model trust boundaries, enumerate identities, validate exploitable paths, preserve evidence, and feed lessons back into delivery pipelines. A scanner can identify a public bucket or broad policy. A pentest must determine whether that weakness connects to sensitive data, privilege escalation, lateral movement, or a control-plane change.
Scoping and Authorization Across AWS Azure and GCP
Cloud testing starts with paperwork that is precise enough to protect both sides. Before credentials are issued, create an asset inventory covering AWS accounts, Azure subscriptions and tenants, GCP projects, regions, workloads, APIs, Kubernetes clusters, serverless functions, CI/CD systems, and third-party integrations. Mark each item as in scope, out of scope, or conditionally testable.
Write the rules of engagement as an operational document, not a general permission statement. Include testing windows, source addresses, test identities, approved tools, prohibited actions, data-handling requirements, emergency contacts, escalation thresholds, and the person authorized to pause the assessment. State who absorbs costs if a test causes resource consumption or a billing anomaly, and define the procedure for account lockout, rate limiting, service degradation, or a security alert.
Provider rules must be explicit
AWS, Azure, and GCP permit customer testing within defined boundaries, but permission to test customer resources isn't permission to test the provider's platform, control plane, or another tenant. Denial-of-service testing is prohibited, and AWS applies service-specific approval rules outside its published permitted list, as described in this cloud penetration testing guide.
Azure guidance describes testing of a customer's own resources without prior notification for most test types, while prohibiting social engineering against Microsoft employees, physical datacentre testing, and automated scanning outside the customer's tenant. The governing framework is Microsoft's Cloud Unified Penetration Testing Rules of Engagement, summarized in this AWS, Azure, and GCP testing rules guide.
| Provider | Pre-Approval Required | Restricted Services | Common Triggers for Suspension |
|---|---|---|---|
| AWS | Depends on the service and activity. Verify the current AWS policy and any service-specific approval requirement. | Provider infrastructure, other tenants, denial-of-service activity, and services outside the permitted testing conditions. | Availability impact, unauthorized service testing, unexpected data access, or policy violations. |
| Azure | Most tests against the customer's own resources can proceed without prior notification, subject to Microsoft's rules. | Microsoft employees, datacentre physical security, resources outside the customer's tenant, and prohibited disruptive activity. | Tenant boundary violations, social engineering, scanning outside scope, or service impact. |
| GCP | Keep testing limited to customer-owned projects and compliant activities. Confirm restrictions before execution. | Provider infrastructure, other customers, and activity that violates Google Cloud policies. | Project-boundary violations, disruptive testing, or unauthorized resource access. |
Put authorization artifacts in the engagement file
The authorization package should include the signed statement of work, account and tenant identifiers, named resources, approved identities, provider policy references, and a shared-responsibility clause. Separate customer-owned workloads from provider-managed infrastructure. This is also where access design matters. A scoped read-only role, separate test role, and narrowly granted escalation permissions are safer than a standing administrator account. Teams that need a deeper primer on role based access control can use it to align permissions with defined responsibilities.
For regulated work, document where evidence will be stored, who can access it, how long it will be retained, and how it will be destroyed. A clear contract turns an accidental lockout or unexpected resource charge into an agreed incident procedure instead of a dispute.
Cloud-Native Threat Modeling for Multi-Cloud Estates
A useful threat model begins with identities and data, then uses network topology to explain reachability. STRIDE remains a practical structure, but the objects change. Spoofing may involve a stolen federated session or service account. Tampering may mean an altered pipeline or infrastructure plan. Elevation of privilege may occur through an AssumeRole chain, a managed identity, or a Kubernetes workload binding.
Start by listing organizations, accounts, subscriptions, tenants, folders, and projects. For each boundary, record the identities that can cross it, the services that broker the transition, and the data available after access is granted. Don't stop at VPCs or virtual networks. Include landing zones, management groups, shared services, private endpoints, tenant boundaries, and provider-managed integrations.
Map the path from user to data plane
Build an identity path for every important business workflow:
- Entry identity: federated employee, service principal, CI runner, API client, or workload identity.
- Trust transition: role assumption, subscription role assignment, project-level binding, token exchange, or managed identity attachment.
- Execution surface: EC2, Lambda, ECS, App Service, Azure Functions, GKE, Cloud Run, or a CI/CD runner.
- Data plane: S3, Blob Storage, Cloud Storage, databases, secrets stores, registries, and customer APIs.
- Cross-boundary movement: another account, subscription, project, cluster, pipeline, or third-party service.
This method exposes paths that isolated configuration checks miss. An apparently moderate permission can become serious when combined with a permissive trust policy, a deployable function, and access to a sensitive storage location.
Threat modeling for software teams also benefits from a structured process, and this threat modeling for AI coding teams provides useful context for turning architectural assumptions into explicit abuse cases. For a cloud assessment, adapt those abuse cases to hybrid identity paths and managed services. A hybrid cloud security resource can help teams frame the same exercise across mixed environments rather than treating each provider as an isolated island.
Score cloud impact, not just software severity
CVSS can describe technical conditions, but cloud prioritization needs additional dimensions:
- Data classification: What information becomes reachable?
- Blast radius: Does the path affect one workload, an account, a subscription, a project, or a shared management layer?
- Privilege consequence: Can the identity read, modify, deploy, delegate, or administer?
- Regulatory exposure: Does the path touch payment data, personal information, health data, or evidence required for an assessment?
- Detectability: Would current telemetry identify the action, or could the path operate without detection?
A strong threat model produces testable hypotheses. “This role is broad” is an observation. “This federated identity can assume a cross-account role, pass a deployment role to Lambda, and read a protected bucket” is an attack path worth validating.
Reconnaissance and Enumeration in Cloud Environments
Treat the control plane as the perimeter. External reconnaissance should identify public S3 buckets, Azure Blob containers, GCP buckets, exposed load balancers, App Service endpoints, and CloudFront or Front Door origins. It should also uncover public APIs, container registries, serverless endpoints, abandoned deployment surfaces, and developer artifacts that reveal how identities are issued.
After external discovery, use an explicitly scoped authenticated role. AWS ReadOnlyAccess, Azure Security Reader, and GCP Viewer can provide useful visibility without handing the tester unnecessary write capability. Validate the identity immediately with aws sts get-caller-identity, then enumerate EC2 instances across regions, Azure resources through Resource Graph, and GCP assets through Asset Inventory.
High-yield checks
Prioritize metadata service exposure, especially 169.254.169.254, and determine whether IMDSv2 is enforced on EC2 workloads. Inspect AMIs, container images, startup scripts, environment variables, and deployment artifacts for credential files. In Azure, look for managed identity assignments, Key Vault access, App Service SCM exposure, and service principal relationships. In GCP, map service accounts, IAM bindings, project inheritance, and workload identity configuration.
OSINT often outperforms another port scan. Review GitHub repositories, Terraform state files, build logs, artifact repositories, and CI configuration for leaked tokens, cloud identifiers, role names, and OIDC claims. A port scanner can confirm that a service is reachable. An identity graph can show how a low-privilege principal reaches a production data plane.
Use cloud attack surface mapping to organize external assets, identities, APIs, and trust relationships into one working model rather than separate spreadsheets.
| Technique | AWS Command/Check | Azure Command/Check | GCP Command/Check | Attacks |
|---|---|---|---|---|
| Identity confirmation | aws sts get-caller-identity |
az account show |
gcloud auth list and gcloud config get-value project |
Tests whether supplied credentials point to the authorized tenant and scope. |
| Compute enumeration | aws ec2 describe-instances across approved regions |
Azure Resource Graph queries for virtual machines and managed identities | Compute asset inventory for instances and service accounts | Finds exposed workloads, attached identities, and inconsistent regional controls. |
| Storage discovery | Review S3 bucket exposure and bucket policies | Query Blob containers and storage access settings | Review Cloud Storage buckets, IAM bindings, and public access settings | Tests public data exposure, weak resource policies, and unintended data-plane access. |
| Identity relationships | Inspect IAM policies, trust policies, and sts:AssumeRole paths |
Review role assignments, service principals, and managed identities | Inspect service accounts, inherited bindings, and workload identity | Reveals privilege escalation and cross-boundary movement. |
| Metadata and secrets | Check IMDS configuration, AMIs, user data, and container images | Review managed identity endpoints, App Service settings, and Key Vault access | Inspect metadata exposure, service account use, and build artifacts | Tests credential theft and workload-to-control-plane escalation. |
Keep enumeration time-boxed. Permission states and trust relationships change quickly, so revalidate important paths immediately before exploitation. Otherwise, a test may report a chain that no longer works or miss a newly reachable escalation route.
Exploitation and Post-Exploitation on Cloud Control Planes
Cloud exploitation is usually an identity problem, not a shell problem. The test objective is to prove a controlled path from an authorized foothold to a meaningful impact without crossing the agreed boundary or altering production data.
Begin with policy analysis. Wildcard actions and broad iam:* grants can enable privilege escalation, while sts:AssumeRole relationships can connect accounts that administrators think are separate. iam:PassRole deserves special attention because a principal may be able to attach a more powerful role to EC2, Lambda, or another service without directly possessing that role.
Follow managed-service escalation paths
On AWS, validate whether Lambda execution roles, ECS task roles, instance profiles, and deployment permissions create a route to higher privilege. On Azure, examine managed identity abuse, App Service SCM access, Run Command permissions, and Key Vault retrieval through a compromised identity. On GCP, test service account impersonation, project-level bindings, Cloud Functions or Cloud Run execution identities, and GKE Workload Identity.
The metadata service changes the blast radius of a workload compromise. IMDSv1 exposure can make credential retrieval easier from vulnerable workloads, while IMDSv2 enforcement adds a request control that can block some common paths. Session tags and SourceIP conditions can also determine whether a stolen or delegated session remains useful outside its intended context.
Prove impact, then stop
Post-exploitation should be controlled and reversible. Demonstrate access to a canary object, enumerate permissions without extracting unnecessary customer data, and record the exact API action, principal, resource, and response. Persistence testing may include checking whether an attacker could create access keys, add SSH public keys, reuse OAuth refresh tokens in Cloud Shell, alter a federated identity provider, or introduce a malicious Lambda layer or Cloud Function. Don't create persistence unless the rules of engagement explicitly permit it.
Detection evasion requires restraint. Regional control-plane APIs, Console-to-API token reuse, and unusual session behavior can trigger alerts even when the action succeeds. Defenders should raise signals for new keys, role-chain anomalies, unusual PassRole use, metadata access, deployment changes, and access from unexpected locations. A pentest should document those expected detections rather than trying to disappear from monitoring.
Evidence Collection and Compliance-Mapped Reporting
Evidence is a legal and operational artifact, not a screenshot added at the end. Synchronize testing systems, record the tester identity and authorized scope, capture API responses with request IDs, and export the corresponding CloudTrail, Azure Activity, and GCP Cloud Audit Logs. Hash collected artifacts and maintain signed attestations so another reviewer can connect each result to a defined action.
Transient resources need special handling. Rotated keys, ephemeral containers, deleted functions, short-lived tokens, and temporary pipeline workers can disappear before the report is reviewed. Capture the minimum proof needed to reproduce the issue, redact sensitive values, and preserve the original artifact in a restricted evidence store.
Build every finding around a reproducible path
A useful finding contains:
- Scope: Account, subscription, project, region, tenant, workload, and identity.
- Condition: The exact permission, exposure, trust relationship, or control failure.
- Attack path: The sequence of authorized test actions used to validate exploitability.
- Evidence: API responses, log records, timestamps, request IDs, screenshots, and hashes.
- Impact: Reachable data, privilege, blast radius, detection outcome, and operational consequence.
- Remediation: A specific policy, identity, workload, pipeline, or monitoring change.
- Retest criteria: The result that proves the path is closed.
Map IAM privilege escalation to relevant SOC 2 CC6.1 and ISO 27001 A.9 controls. Map public storage exposure to PCI-DSS Requirements 1 and 7 where the environment and assessment scope make those controls applicable. Map metadata exposure to FedRAMP AC-17 when the control context applies. The mapping should support an auditor without replacing the technical explanation.
FedRAMP work adds a concrete evidence obligation. Official guidance requires a description of the procedures used for transmission and storage of penetration test evidence, as summarized in this AWS, Azure, and GCP cloud pentesting guidance. That means evidence handling belongs in the methodology, authorization package, and final report.
Separate the executive narrative from the reproduction appendix and remediation backlog. Executives need business exposure and decisions. Engineers need exact policies, resources, API actions, and fixes. Auditors need scope, timestamps, control mappings, and attestations. A broader enterprise data security guide for 2026 can help teams align evidence handling with wider data governance practices.
Evidence standard: If a reviewer can't identify the tenant, principal, action, timestamp, and affected resource, the screenshot isn't enough.
Common report failures include missing tenant scope, blurred screenshots, unattested action logs, unexplained test identities, and remediation advice that says “restrict permissions” without naming the permission or trust edge. Those omissions slow remediation and can leave auditors unable to accept otherwise valid work.
CI/CD Integration and Continuous Cloud Pentesting
An annual cloud pentest is a point-in-time control in an environment that changes with every deployment, permission update, pipeline edit, and managed-service integration. The practical answer is a recurring program that combines preventive checks, deployed-workload testing, identity-graph review, and periodic adversarial exercises.
Start before deployment. Scan Terraform and CloudFormation with tools such as Checkov, tfsec, and cfn-nag. Add policy-as-code checks for public storage, unsafe identity bindings, missing logging, weak network controls, and unapproved regions or services. Trigger DAST against deployed workloads on merge or release, with production safeguards and a clearly isolated test target.
Make credentials and tools temporary
Pacu, CloudFox, and ScoutSuite can support discovery and validation, but pipeline execution should use scoped, ephemeral credentials that rotate automatically. Keep destructive actions disabled by default, require approval for exploitation stages, and retain command logs with the resulting evidence. An agentic platform such as ThreatExploit AI can orchestrate reconnaissance, exploitation, verification, and reporting across AWS, Azure, and GCP, producing evidence-backed, compliance-mapped outputs for security service providers.
The cadence should reflect change velocity. Teams deploying daily can schedule frequent authorization-graph diffs and recurring adversarial reviews. More stable estates can use periodic deep tests, provided major architecture, identity, pipeline, and workload changes trigger an assessment outside that schedule.
Check the gaps automation misses
Use this operational checklist:
- Preview environments: Include feature flags, temporary URLs, preview deployments, and copied production policies.
- State drift: Compare live permissions and resources with IaC because manual changes can bypass repository review.
- CI secrets: Remove long-lived keys from runners, logs, artifacts, and environment variables.
- Trust chains: Re-test
AssumeRole, service-account impersonation, managed identities, and workload identity after every identity redesign. - Managed services: Include Kubernetes, containers, serverless workloads, APIs, registries, and third-party integrations.
- Detection: Confirm that simulated actions create useful alerts and that responders know the approved test context.
Track maturity with operational measures such as mean time to detect a misconfiguration, the share of production accounts covered, and the number of attack paths remediated before release. Those measures tell you whether the program is reducing reachable risk, not merely generating more scanner output.
A mature program leaves an audit trail continuously. It doesn't reconstruct scope, evidence, and remediation history under deadline pressure.
ThreatExploit AI helps security service providers automate reconnaissance, exploitation, verification, and reporting across AWS, Azure, and GCP, with evidence-backed outputs and compliance mapping for recurring cloud assessments. If you need to turn cloud pentesting into a controlled CI/CD capability rather than a one-off exercise, visit ThreatExploit AI to review the platform and its deployment options.