Short answer: Cloud penetration testing is a security assessment of AWS, Azure, and GCP environments that finds misconfigurations, over-permissive IAM, exposed credentials, and insecure services. Because of the shared responsibility model you test what you configure, not the provider's hardware, using tools like ScoutSuite, Prowler, and Pacu combined with manual review.
Businesses have moved to the cloud, but many carry old on-premise security habits with them. The result is predictable: open storage buckets, leaked access keys, and IAM roles that can do far too much. This guide explains how cloud penetration testing works across AWS, Azure, and GCP, what the shared responsibility model means for you, the most common misconfigurations, and the tools professionals rely on.
The Shared Responsibility Model
Every cloud provider follows a shared responsibility model, and misunderstanding it is the root cause of most breaches. In simple terms, the provider secures the cloud, and you secure what you put in it.
| Layer | AWS / Azure / GCP responsibility | Your responsibility |
|---|---|---|
| Physical data centres | Yes | No |
| Hardware and networking | Yes | No |
| Hypervisor | Yes | No |
| Operating system patching (IaaS VMs) | No | Yes |
| IAM, roles, and permissions | No | Yes |
| Data, encryption, and buckets | No | Yes |
| Application code and configuration | No | Yes |
Cloud penetration testing focuses almost entirely on the right-hand column, the things you control. You cannot pentest the provider's data centre, but you absolutely can and should test your own configuration.
Common Cloud Misconfigurations
Across hundreds of assessments, the same issues appear again and again. These are the findings that lead to real breaches.
- Publicly open storage: S3 buckets, Azure Blob containers, or GCS buckets set to public, exposing customer data, backups, and secrets.
- Over-permissive IAM: Users and roles with wildcard Action: * or AdministratorAccess when they only need to read one bucket. This enables privilege escalation.
- Exposed access keys: Long-lived AWS keys hard-coded in GitHub repos, mobile apps, or front-end JavaScript.
- Unrestricted security groups: Ports like SSH (22), RDP (3389), or databases (3306, 5432) open to 0.0.0.0/0.
- Disabled logging: CloudTrail, Azure Monitor, or GCP audit logs turned off, so attacks go unnoticed.
- Unencrypted data: Volumes, snapshots, and databases stored without encryption.
- Weak metadata protection: SSRF against the instance metadata service (IMDS) to steal temporary credentials, a leading cloud escalation path.
Config Review vs Cloud Penetration Test
These two are related but different, and a strong engagement uses both.
Cloud configuration review
A configuration review (also called a cloud security posture assessment) uses read-only API access to audit your entire account against best practice: IAM policies, bucket permissions, encryption, logging, and network rules. It is broad, fast, and finds misconfigurations at scale using tools like ScoutSuite and Prowler.
Cloud penetration test
A penetration test is adversarial. The tester acts like an attacker, attempting to actually exploit findings: escalating IAM privileges, pivoting between services, extracting data, and chaining weaknesses into a full compromise. It proves real-world impact rather than just listing issues. To understand the broader discipline, read what is penetration testing.
AWS, Azure, and GCP Specifics
AWS penetration testing
AWS testing centres on IAM (the heart of AWS security), S3 bucket policies, EC2 security groups, Lambda functions, and the instance metadata service. Privilege-escalation paths through misconfigured IAM policies are a primary focus. Pacu is the go-to exploitation framework here.
Azure penetration testing
Azure testing revolves around Entra ID (formerly Azure AD), role-based access control, storage accounts, managed identities, and Azure Key Vault. Because Azure integrates tightly with Microsoft 365, identity attacks and consent phishing are important. Tools like MicroBurst and ROADtools are widely used.
GCP penetration testing
GCP testing focuses on IAM roles, service accounts (a frequent escalation vector), Cloud Storage buckets, and Compute Engine metadata. Overly broad service-account permissions are the most common route to compromise.
Provider Rules on Cloud Penetration Testing
You cannot simply attack cloud infrastructure whenever you like. Each provider has rules, and following them keeps testing legal and safe.
- AWS: Permits testing of many services (EC2, RDS, Lambda, and more) without prior approval, but denial-of-service and certain activities remain prohibited. Always review the current AWS customer support policy.
- Azure: Allows penetration testing of your own resources under the unified Microsoft cloud testing rules; DoS testing is restricted.
- GCP: Does not require notification to test your own projects, provided you stay within the acceptable use policy and only target assets you own.
The golden rule: only test resources you own or have written authorisation to test, and never launch destructive attacks against shared infrastructure.
Top Cloud Penetration Testing Tools
| Tool | Purpose |
|---|---|
| ScoutSuite | Multi-cloud (AWS, Azure, GCP) security auditing that produces a clear posture report. |
| Prowler | AWS-focused (now multi-cloud) hardening and compliance scanner mapped to CIS benchmarks. |
| Pacu | AWS exploitation framework for privilege escalation and post-exploitation. |
| CloudSploit / cloudmapper | Configuration analysis and visualising cloud network exposure. |
| MicroBurst / ROADtools | Azure and Entra ID enumeration and attack tooling. |
| trufflehog / gitleaks | Finding leaked access keys and secrets in code repositories. |
These tools automate discovery, but interpreting findings, chaining privilege escalation, and judging real business impact requires an experienced tester. See our full VAPT tools list for more.
IAM Privilege Escalation: The Heart of Cloud Attacks
If there is one theme that dominates cloud penetration testing, it is identity and access management. In the cloud, identity is the new perimeter. Attackers rarely break the hypervisor; instead they find a low-privileged credential and escalate it step by step until they control the whole account. A typical chain looks like this.
- An access key is discovered leaked in a public GitHub repository or a mobile app.
- The tester enumerates what that identity can do, often finding an overlooked permission such as iam:PassRole, iam:CreatePolicyVersion, or the ability to attach policies.
- That single permission is abused to grant the identity administrator rights.
- With full control, the attacker reads databases, snapshots, and secrets across the account.
This is why the principle of least privilege matters so much. Every identity, human or machine, should have only the permissions it genuinely needs. Wildcards in IAM policies are the most common finding we report, and removing them prevents the majority of escalation paths.
Container and Kubernetes Considerations
Modern cloud environments increasingly run on containers and Kubernetes, which add their own attack surface on top of the underlying cloud. A complete cloud penetration test often extends to these layers.
- Exposed Kubernetes dashboards and APIs: An unauthenticated kubelet or dashboard can hand an attacker control of the cluster.
- Over-privileged service accounts: Pods that mount powerful service-account tokens allow lateral movement.
- Vulnerable container images: Outdated base images and embedded secrets in image layers are common.
- Escaping the container: Misconfigured privileged containers can break out to the host node and, from there, into the cloud account.
Because containers, IAM, and cloud services are so interconnected, a weakness in one layer frequently becomes the pivot into another. Testing them together, rather than in isolation, is what reveals the true blast radius of a compromise.
How Often Should You Test Your Cloud?
Cloud environments change constantly. A new developer spins up a bucket, a role gets an extra permission "just for now", or a service is deployed to meet a deadline. Each change can introduce a misconfiguration. Because of this pace, cloud security is not a once-a-year exercise. We recommend a formal cloud penetration test at least annually, a configuration review every quarter, and continuous automated posture monitoring in between. Any major architectural change, migration, or new product launch should also trigger a fresh assessment. This cadence keeps pace with how quickly cloud environments drift from their secure baseline.
Cloud Penetration Testing with Cyber Defence
Cyber Defence is an ISO-certified, GeM-registered security provider founded by Amit Kumar (CEH, CRTA). We combine automated cloud configuration review with manual, adversarial penetration testing across AWS, Azure, and GCP. Every engagement follows our documented VAPT process and methodology and includes a prioritised report, remediation support, a free retest, and a certificate. Network testing starts from Rs 20,000, web application testing from Rs 25,000, and API/cloud/mobile testing from Rs 30,000. We serve clients nationwide, including Haryana and Delhi. To learn cloud and infrastructure security hands-on, see our VAPT training.
FAQ
What is cloud penetration testing?
Cloud penetration testing is a security assessment of AWS, Azure, or GCP environments that identifies and exploits misconfigurations such as open storage, over-permissive IAM, and exposed keys. It tests the parts of the cloud you are responsible for under the shared responsibility model.
Can I legally pentest AWS, Azure, or GCP?
Yes, you can test resources you own within each provider's acceptable use policy. AWS and GCP allow testing of your own assets without prior notice for most services, while destructive attacks like DoS are prohibited. Always confirm the current provider policy first.
What is the shared responsibility model?
It defines who secures what: the provider secures the physical infrastructure and hypervisor, while you secure your data, IAM, configurations, and applications. Cloud pentests focus on your side of that line.
What is the difference between a config review and a cloud pentest?
A configuration review audits your account settings against best practice using read-only access, while a penetration test actively exploits weaknesses to prove real-world impact. A strong engagement combines both.
Which tools are used for cloud penetration testing?
Popular tools include ScoutSuite, Prowler, Pacu, CloudSploit, MicroBurst, and secret scanners like trufflehog. Tools accelerate discovery, but manual analysis is essential for privilege escalation and impact assessment.
How much does cloud penetration testing cost?
At Cyber Defence, cloud and infrastructure testing starts from Rs 30,000 depending on the number of accounts, services, and scope, and includes a full report, remediation guidance, a free retest, and a certificate.
Moving to the cloud or already there? Get an expert AWS, Azure, or GCP penetration test from Cyber Defence with a free retest and certificate. Call or WhatsApp +91-75175-72000.