> aws sts get-caller-identity && echo 'whose cloud is it anyway?'_
A mid-sized fintech company migrates its core platform to AWS. It runs annual penetration tests — has done for years. The next engagement is scoped identically to the previous one: test the IP addresses, probe the services, scan for vulnerabilities. The report comes back clean. A few informational findings about HTTP headers, a medium-severity TLS configuration issue, and a recommendation to disable an unused port.
Three months later, a security researcher contacts the company. An S3 bucket containing 2.3 million customer records is publicly accessible. The IAM policy on the application's Lambda execution role allows s3:* on * — full access to every bucket in the account. The CloudTrail logging that would have detected the exposure was never enabled. And the credentials for the CI/CD pipeline's deployment user — with administrative permissions — were committed to a public GitHub repository eight months ago.
None of this appeared in the pen test. Not because the testers were incompetent — but because they tested the cloud as if it were a traditional data centre. They scanned IP addresses and probed exposed services. They never examined IAM policies, bucket configurations, logging posture, or the CI/CD pipeline. They tested the compute and ignored the cloud.
Traditional infrastructure testing asks: "Can I exploit a vulnerability in the services running on this machine?" Cloud testing asks: "Can I abuse the permissions, configurations, and trust relationships that connect these services to each other and to the organisation's data?" They are fundamentally different questions — and answering the first tells you almost nothing about the second.
Every major cloud provider operates a shared responsibility model. The provider secures the infrastructure — the physical data centres, the hypervisors, the networking fabric, the hardware. The customer secures everything they build on top of it — the configurations, the identity policies, the data, and the applications.
The practical consequence is that the vast majority of cloud breaches aren't caused by vulnerabilities in the cloud platform. They're caused by how the customer configured it. AWS doesn't ship S3 buckets as publicly accessible by default. Azure doesn't create storage accounts without access controls. The customer — or the Terraform template, or the developer who needed it working quickly, or the deployment script that was copied from a blog post — made it that way.
| Provider Responsibility | Your Responsibility | |
|---|---|---|
| Compute | Physical servers, hypervisors, host OS patching, hardware security modules | Guest OS patching, application code, runtime configuration, network security groups, instance metadata protection |
| Storage | Physical storage infrastructure, storage service availability, encryption at the hardware layer | Bucket/blob policies, public access settings, encryption configuration (SSE-S3 vs SSE-KMS vs client-side), access logging, lifecycle policies |
| Networking | Physical network infrastructure, backbone connectivity, DDoS mitigation at the platform level | VPC/VNet architecture, security groups, NACLs, route tables, VPN/peering configuration, DNS records, load balancer settings |
| Identity | IAM service availability, authentication infrastructure, MFA platform functionality | IAM policies, role trust relationships, permission boundaries, MFA enforcement, access key rotation, federation configuration, conditional access |
| Data | Storage medium reliability, service-level encryption options | Classification, encryption key management, access controls, retention policies, backup strategy, regulatory compliance |
| Logging and monitoring | CloudTrail/Azure Monitor/Cloud Audit Logs service availability | Enabling logging, configuring retention, setting up alerts, monitoring for anomalies, ensuring logs can't be tampered with |
A cloud penetration test operates almost entirely in the "your responsibility" column. That's where the misconfigurations live, where the excessive permissions accumulate, and where the breaches originate.
Cloud penetration testing shares the goal of traditional testing — find the weaknesses before an attacker does — but the methodology, the attack surface, and the tooling are substantially different.
| Traditional Infrastructure Testing | Cloud Penetration Testing | |
|---|---|---|
| Primary attack surface | Exposed services, open ports, software vulnerabilities, network protocols, OS-level misconfigurations | IAM policies, resource configurations, trust relationships between services, API permissions, serverless function roles, cross-account access, CI/CD pipeline credentials |
| Initial access | Exploit a vulnerability in an internet-facing service. Brute-force a credential. Phish a user. | Abuse a misconfigured IAM role. Exploit leaked credentials (API keys, access tokens). Leverage an over-permissive Lambda/Function execution role. Access publicly exposed storage. |
| Lateral movement | Move between machines on the network. Pass hashes, relay credentials, exploit trust relationships between domain-joined systems. | Escalate through IAM: assume roles across accounts, chain permissions through role trust policies, pivot from one service to another via the permissions each service's identity grants. No network required — it's all API calls. |
| Privilege escalation | Local admin → Domain Admin via AD misconfigurations, cached credentials, vulnerable services. | Read-only → Admin via IAM policy misconfigurations: iam:PassRole, iam:AttachUserPolicy, sts:AssumeRole with overly-broad trust, Lambda creation with a high-privilege execution role. Over 30 documented IAM escalation paths in AWS alone. |
| Data access | Access file shares, database servers, email — typically requires network access and credentials. | Access storage buckets, databases, secrets managers — often requires only the right IAM permissions, obtainable through role chaining without ever touching the network layer. |
| Detection evasion | Avoid AV/EDR, clear logs, use living-off-the-land binaries, blend with legitimate network traffic. | Avoid CloudTrail/Azure Monitor detection, use API calls that aren't logged by default, operate within assumed roles whose activity is attributed to the service rather than the attacker. |
| Key tooling | Nmap, Metasploit, BloodHound, Responder, Mimikatz, Burp Suite | Pacu, ScoutSuite, Prowler, CloudFox, enumerate-iam, AWS CLI / Az CLI / gcloud, Steampipe, custom API scripts |
The fundamental shift is from network-centric to identity-centric. In traditional testing, the attacker moves through the network — machine to machine, subnet to subnet. In the cloud, the attacker moves through the identity layer — role to role, permission to permission, API to API. The network barely features.
Unlike traditional pen testing where you need authorisation only from the asset owner, cloud testing operates within the provider's acceptable use policies as well. Each major provider has different rules about what testing is permitted, what requires notification, and what is prohibited.
| Provider | What's Permitted | What's Restricted | Notification Required? |
|---|---|---|---|
| AWS | Pen testing of your own resources (EC2, RDS, Lambda, API Gateway, CloudFront, etc.) is permitted without prior approval for most services. | DNS zone walking via Route 53. DoS/DDoS attacks. Port flooding. Protocol flooding. Any testing against AWS infrastructure itself (not your resources). | No — AWS removed the pre-approval requirement in 2019. However, you must only test resources you own, and your testing must comply with the AWS Customer Support Policy. |
| Azure | Pen testing of your own Azure-hosted resources is permitted under the Microsoft Cloud Unified Penetration Testing Rules of Engagement. | DoS testing of any kind. Scanning or testing resources belonging to other Azure customers. Port scanning that generates excessive traffic. Any testing targeting Microsoft's infrastructure. | No — Azure removed the pre-approval requirement in 2017. Testing must follow the unified rules of engagement. |
| GCP | Pen testing of your own GCP resources is permitted. Google's Acceptable Use Policy applies. | DoS testing. Intentional disruption to other GCP customers. Testing Google's infrastructure or other customers' resources. | No — GCP does not require pre-notification for testing against your own resources. |
The critical point: you can test your configuration of the provider's services, but you cannot test the provider's infrastructure itself. You're testing how you've used the cloud, not the cloud itself — which aligns perfectly with the shared responsibility model.
In traditional environments, the network is the primary control plane — firewalls, VLANs, and segmentation determine what can reach what. In the cloud, IAM is the control plane. Every API call, every resource access, every service interaction is governed by IAM policies. Compromise IAM and you compromise the cloud — without sending a single network packet.
This is why IAM assessment is the single most important component of a cloud penetration test. It's also the component most often skipped — because it doesn't look like traditional pen testing and requires a different skill set.
| IAM Weakness | How We Find It | What an Attacker Achieves |
|---|---|---|
Wildcard permissions — policies using "Action": "*" or "Resource": "*" |
Enumerate all IAM policies attached to users, roles, and groups. Flag any policy with * actions or resources. Assess whether the wildcard is necessary or a shortcut. |
A role with s3:* on * can read, write, and delete every object in every bucket in the account. A role with * on * is effectively the account root. |
| Privilege escalation paths — combinations of permissions that allow self-elevation | Analyse IAM policies for known escalation primitives: iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PassRole combined with lambda:CreateFunction, iam:PutRolePolicy, sts:AssumeRole with overly-broad trust. |
A user with iam:AttachUserPolicy attaches AdministratorAccess to themselves. A user with iam:PassRole and lambda:CreateFunction creates a Lambda with an admin execution role and invokes it. Over 30 documented escalation paths exist in AWS alone. |
| Overly-broad role trust policies — roles that can be assumed by too many principals | Examine each role's trust policy. Identify roles that trust entire accounts ("Principal": {"AWS": "arn:aws:iam::123456789012:root"}), all services, or external accounts without conditions. |
If a role trusts an entire account, any principal in that account can assume it — including principals the role owner doesn't control. Cross-account role assumption is one of the primary lateral movement techniques in cloud. |
| Long-lived access keys — static credentials that never rotate | List all IAM users with active access keys. Check when each key was last rotated. Identify keys that have never been rotated or were created more than 90 days ago. | Long-lived access keys are the cloud equivalent of a password written on a sticky note. They appear in environment variables, CI/CD configurations, developer laptops, and — most dangerously — public code repositories. A stolen access key with admin permissions is instant account compromise. |
| Missing permission boundaries — no guardrails on what delegated users can create | Check whether IAM users who can create other users or roles are constrained by permission boundaries. Test whether a developer who can create Lambda functions can assign those functions any execution role. | Without permission boundaries, a developer who can create IAM roles can create one with administrator access. The boundary they're supposed to operate within exists only in policy, not in enforcement. |
Beyond IAM, cloud assessments consistently surface the same categories of misconfiguration. These findings appear across AWS, Azure, and GCP — they're not provider-specific issues but universal patterns of how organisations misconfigure cloud services.
To make the methodology concrete, here's a composite of a typical AWS cloud penetration test — from initial access through to demonstrated impact.
Eight findings. A complete exploitation chain from a public GitHub repository to 2.3 million customer records. Zero findings that a traditional port-and-service scan would have discovered. The infrastructure was patched. The services were hardened. The cloud configuration was wide open.
Cloud security testing is still relatively young compared to traditional pen testing, and misconceptions are widespread. These are the ones we encounter most frequently — and each one creates a gap that attackers readily exploit.
| Misconception | Reality |
|---|---|
| "Our cloud provider handles security." | The provider secures the platform. You secure your configuration, your data, your identity policies, and your applications. The shared responsibility model is explicit: the most commonly exploited layer — configuration — is entirely your responsibility. |
| "We already have a pen test — it covers the cloud." | If your pen test scope is defined by IP addresses and URLs, it tests the compute and applications running in the cloud. It does not test IAM policies, storage configurations, logging posture, cross-account trust, or any of the cloud-native attack surface. These require explicit, cloud-specific testing. |
| "We run CIS benchmarks, so we're covered." | CIS benchmarks are excellent for configuration compliance. They check whether best-practice settings are applied. They do not test whether IAM permissions can be chained to escalate privileges, whether cross-account roles create unintended trust, or whether a realistic attack path exists through your specific configuration. Benchmarks are a baseline, not a test. |
| "We can't pen test in the cloud — the provider won't allow it." | All three major providers (AWS, Azure, GCP) permit penetration testing of your own resources without prior notification. The restrictions apply to DoS testing and attacks against the provider's own infrastructure — not to testing your configuration and applications. |
| "Our cloud is more secure than our on-premises environment." | The cloud can be more secure — it offers powerful security tooling, granular access controls, and infrastructure-level protections that most on-premises environments can't match. But those tools have to be correctly configured. An unconfigured cloud environment is no more secure than an unconfigured server room. |
| "We use Infrastructure as Code, so our configuration is consistent." | IaC ensures consistency — including consistent misconfigurations. If the Terraform module defines an S3 bucket without encryption or a security group with 0.0.0.0/0 inbound, every deployment reproduces the vulnerability perfectly. IaC is a delivery mechanism, not a security control. |
| "The staging account doesn't matter — there's no customer data there." | The staging account matters if it has a trust relationship with the production account. The staging account matters if its CI/CD credentials can deploy to production. The staging account matters if its IAM users have the same passwords as their production counterparts. Attackers don't care about data in staging — they care about the path from staging to production. |
A cloud pen test scoped by IP address will miss almost everything that matters. The scope needs to be defined in cloud-native terms — accounts, services, roles, and configurations — not in network terms.
| Scope Element | What to Include | Why It Matters |
|---|---|---|
| Account structure | All AWS accounts / Azure subscriptions / GCP projects in scope. Include non-production accounts if they have trust relationships with production. | Cross-account role assumption is a primary lateral movement path. Testing production in isolation misses the staging-to-production pivot. |
| IAM review scope | All users, roles, groups, and policies. Service-linked roles. Cross-account roles. Permission boundaries. SCPs at the organisation level. | IAM is the control plane. If it's not in scope, the test isn't a cloud test — it's a traditional test running on cloud compute. |
| Storage and data services | All S3 buckets / Azure Blob containers / GCS buckets. RDS/Azure SQL snapshots. Secrets Manager / Key Vault / Parameter Store. | Misconfigured storage is the most common path to data exposure. Shared snapshots and unencrypted secrets are consistently high-impact findings. |
| Serverless and container workloads | Lambda / Azure Functions / Cloud Functions execution roles. ECS/EKS/AKS task roles. Container registry access. | Serverless functions often have over-permissive execution roles because they're created quickly and iterated rapidly. Each function is an identity in the IAM graph. |
| Logging and detection | CloudTrail / Azure Monitor / Cloud Audit Logs configuration. GuardDuty / Defender for Cloud / Security Command Centre status. | Testing whether attacks are detected is as important as finding the vulnerabilities themselves. A cloud without logging is a cloud where breaches go unnoticed. |
| CI/CD pipeline | Deployment tool credentials, pipeline permissions, source code repository access, deployment roles. | The CI/CD pipeline is often the most privileged identity in the entire environment — and the least secured. It deserves explicit testing. |
Cloud penetration testing is not traditional infrastructure testing relocated to AWS. The attack surface has shifted from ports and services to IAM policies and resource configurations. The lateral movement path has shifted from network protocols to role assumption and permission chaining. The breach vector has shifted from software vulnerabilities to cloud misconfigurations.
A traditional pen test against cloud infrastructure will find the web application bugs and the unpatched services — and it will miss the publicly accessible storage, the overly-permissive IAM roles, the cross-account trust relationships, the absent logging, and the CI/CD pipeline that serves as the shortest path to complete environment compromise.
The cloud can be extraordinarily secure — more secure than most on-premises environments. But only when it's tested as a cloud, not as a collection of IP addresses. The methodology must match the platform. Anything less is a pen test that covers the surface and misses the substance.
Our cloud penetration testing covers the full cloud-native attack surface — IAM, storage, cross-account trust, logging, serverless, and CI/CD pipelines — not just the compute layer.