Cloud Penetration Testing: What We Find in AWS, Azure, and GCP Assessments
Most cloud breaches don't come from zero-days. They come from misconfigurations that have been sitting in production for months. Here's what we find in nearly every cloud assessment, and how attackers use them.
Cloud environments move fast. Development teams spin up infrastructure in minutes, permission boundaries blur across accounts, and the security controls that work on-premises often don't translate cleanly to IAM policies and service configurations. The result: most production cloud environments contain at least a few misconfigurations that would give an attacker meaningful access.
We conduct cloud security assessments across AWS, Azure, and GCP, and the same classes of issues appear consistently regardless of the platform, the organization's size, or how mature their security posture is in other areas. What follows is a breakdown of the most common high-impact findings and what they look like from an attacker's perspective.
IAM Privilege Escalation Paths
IAM is the most consistently misconfigured component in cloud environments, and it's where most cloud penetration tests yield their most significant findings. The core issue isn't that permissions are granted; it's that the full consequences of permission combinations aren't visible until you model them as an attacker would.
Wildcard permissions on non-production roles that trust production
A dev/staging IAM role with iam:* or sts:AssumeRole that has a trust relationship with a production account creates a lateral movement path from development to production. We find this in roughly 40% of multi-account AWS environments.
PassRole + Lambda/EC2 CreateFunction = privilege escalation
A user with iam:PassRole and lambda:CreateFunction can create a Lambda function that executes as a higher-privileged role, even if they can't directly assume that role. This is one of the most commonly missed escalation paths in AWS IAM reviews.
# Check for dangerous PassRole combinations
aws iam get-user-policy --user-name <user>
aws iam list-attached-user-policies --user-name <user>
# Look for any policy containing PassRole + a creation action
# iam:PassRole + ec2:RunInstances
# iam:PassRole + lambda:CreateFunction
# iam:PassRole + ecs:RunTask
Publicly Exposed Storage
S3 bucket exposure is a well-known problem that somehow remains prevalent. The subtler version, and the one that gets missed, isn't public buckets, it's buckets that are private but accessible via misconfigured bucket policies granting cross-account access, or pre-signed URLs with excessively long expiry times circulating in application logs.
S3 bucket accessible to any authenticated AWS account
"Principal": {"AWS": "*"} in a bucket policy with no Condition block doesn't mean publicly accessible to the internet; it means accessible to any authenticated AWS principal in any account. Widely misunderstood, frequently misconfigured.
Logging buckets without public access blocks
CloudTrail, VPC flow logs, and ALB access logs often land in buckets that were created before account-level public access blocks were enabled. These buckets contain detailed records of your infrastructure and API call history. Exactly what an attacker wants for reconnaissance.
Metadata Service Exposure (SSRF to Cloud Takeover)
If an EC2 instance, ECS container, or GCP compute instance running a vulnerable application is reachable from the internet, Server-Side Request Forgery against the instance metadata service is a standard escalation path. IMDSv1 in AWS returns credentials without any additional authentication: a single SSRF request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns temporary credentials for the instance role.
We covered this in detail in our SSRF to AWS takeover post. IMDSv2 mitigates this but requires a PUT request to get a session token first, and many organizations have enforced IMDSv2 at the account level while leaving older instances running IMDSv1.
Azure: Managed Identity Abuse
Azure Managed Identities solve the credential rotation problem but introduce a new attack surface: any code running on a resource with a managed identity can request tokens from the IMDS endpoint. If an attacker achieves code execution on an Azure VM, App Service, or Function App, they inherit the managed identity's permissions.
Overpermissioned managed identities on internet-facing resources
Contributor or Owner role assignments on managed identities attached to public-facing App Services are the Azure equivalent of giving your web server a domain admin account. We find this pattern regularly in environments that migrated from service principal secrets to managed identities without revisiting the permission scope.
GCP: Service Account Key Files
GCP's service account key files are long-lived credentials that don't expire unless explicitly rotated. Unlike AWS IAM access keys which can be tied to a user and audited via CloudTrail, service account key files created for automation often end up in source code, Docker images, or artifact repositories, and stay there indefinitely.
In GCP assessments, we routinely find service account keys in CI/CD configuration files checked into internal repositories, in environment variables exposed through misconfigured container runtime APIs, and embedded in application packages deployed to Cloud Run or GKE.
Cross-Cloud Risks in Multi-Cloud Environments
Organizations running workloads across multiple cloud providers add a layer of complexity that security tooling often doesn't cover well. Federation between AWS and Azure AD, GCP Workload Identity Federation to AWS, and shared Terraform state files that contain credentials for multiple environments create attack paths that span provider boundaries and are rarely modeled in threat assessments.
What a Cloud Penetration Test Actually Looks Like
A cloud security assessment isn't a compliance scan against CIS benchmarks (though that's a useful starting point). It's an adversary-driven exercise that starts from an assumed initial access position (compromised IAM credentials, SSRF from a web application, malicious insider with limited permissions) and attempts to escalate to the most impactful objectives: cross-account access, data exfiltration, persistent access, or disabling security controls.
The findings that matter aren't the ones a scanner catches. They're the privilege escalation paths that require understanding how IAM permission combinations interact, the lateral movement routes that cross account boundaries, and the detection gaps that let an attacker operate undetected for weeks.
Running workloads in AWS, Azure, or GCP?
Our cloud security assessments cover IAM analysis, storage exposure, network segmentation, and adversary-driven escalation testing across all major platforms.
View Cloud Security Services