Cloud Privilege Escalation: Common Attack Paths

📅 September 22, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single misconfigured IAM role in a cloud environment can hand an attacker the keys to your entire infrastructure — and according to the 2026 Verizon Data Breach Investigations Report, privilege escalation now appears in 74% of cloud-related breaches, making it the dominant technique adversaries leverage once they establish an initial foothold. The attack doesn’t announce itself with sirens. It unfolds quietly, one overpermissioned role assumption at a time, until your threat actor is sitting at the control plane with the same authority as your platform engineering team.

Cloud privilege escalation is not a theoretical risk confined to poorly-managed startups. It has compromised Fortune 500 organizations, government agencies, and cloud-native SaaS platforms with mature security programs. Understanding the specific attack paths — the actual sequences attackers follow — is the prerequisite to building detection and prevention that works against real-world adversary behavior, not against the sanitized scenarios that appear in compliance checklists.

What Makes Cloud Privilege Escalation Fundamentally Different

Traditional on-premises privilege escalation typically targets OS-level mechanisms: kernel exploits, SUID binaries, credential theft from the local SAM database. Cloud privilege escalation operates at a completely different abstraction layer. Attackers target the identity and access management plane — APIs, metadata services, service accounts, instance profiles, and trust relationships between cloud-native services.

This matters because cloud environments are designed around the principle of identity as perimeter. When that identity layer is exploited, traditional network controls become largely irrelevant. An attacker who has assumed a high-privilege role in AWS, Azure, or GCP is authenticated by the cloud provider itself. Firewalls don’t stop authenticated API calls.

The Shared Responsibility Gap

A persistent source of escalation exposure is what security practitioners increasingly call the shared responsibility gap. Cloud providers secure the underlying infrastructure and the APIs themselves. Customers are responsible for IAM configuration, role assignment hygiene, and least-privilege enforcement. The 2025 Cloud Security Alliance report found that 81% of organizations have at least one IAM misconfiguration that could be leveraged for privilege escalation — and in 34% of cases, those misconfigurations could lead to full administrative access without any additional vulnerability exploitation.

The gap widens in multi-team environments where developers self-provision resources. A CI/CD pipeline that was given broad permissions to “just make deployments work” becomes a persistent escalation path that outlives the original project by months or years.

Attack Path One: IAM Role Chaining and Trust Policy Abuse

Role chaining is the most architecturally elegant privilege escalation technique in cloud environments. An attacker who compromises a low-privilege identity doesn’t need to find a single path to admin — they traverse a chain of trust relationships, each hop granting incrementally broader permissions until they reach a target role with sufficient authority.

In AWS, this typically involves the sts:AssumeRole permission. If a compromised IAM user can assume Role A, and Role A has been granted the ability to assume Role B (which holds administrative policies), the attacker chains these assumptions to arrive at full access. The individual permissions at each step may appear reasonable in isolation — it’s the chain that creates the escalation path.

Real-World Illustration: The Capital One Architecture Lesson

While the 2019 Capital One breach is often cited for its WAF misconfiguration, the deeper architectural lesson involves the metadata service exploitation that followed. The compromised EC2 instance retrieved credentials from the Instance Metadata Service (IMDS), which granted access to an overpermissioned role attached to that instance. That role had ListBuckets and GetObject permissions across essentially every S3 bucket in the account. A single hop — from compromised instance to instance profile to S3 data — was all it took.

Modern attacks have grown more sophisticated. Adversaries now map entire trust graphs using tools like PMapper (Principal Mapper) to identify all possible escalation paths within an AWS environment before executing any single API call that might trigger detection. The reconnaissance is patient and methodical.

Attack Path Two: Metadata Service Exploitation

Every major cloud platform exposes a metadata API that provides running instances with information about themselves, including temporary credentials for attached service identities. In AWS, this is the IMDS at 169.254.169.254. In GCP, it’s the Compute Metadata Server. In Azure, it’s the Instance Metadata Service endpoint.

The exploitation pattern is consistent across clouds: if an attacker can trigger a server-side request forgery (SSRF) vulnerability in an application running on a cloud instance, they can redirect that request to the metadata endpoint and harvest credentials. Those credentials are rotated automatically but have a default lifetime of up to six hours — more than enough time to establish persistent access through secondary mechanisms.

IMDSv2 and Its Limitations

AWS’s IMDSv2 was introduced specifically to mitigate SSRF-based metadata theft by requiring a session-oriented, PUT-based token flow. However, a 2025 analysis by Wiz Research found that 41% of AWS EC2 instances in enterprise environments were still running IMDSv1 — the vulnerable version — due to legacy application compatibility constraints and inadequate enforcement of migration policies.

GCP and Azure have analogous protections, but their adoption patterns show similar enforcement gaps. The metadata service remains one of the most reliably productive initial access-to-escalation pathways precisely because it exists by design and requires no vulnerability in the cloud platform itself to exploit — only a vulnerability in customer-deployed application code.

Attack Path Three: Overpermissioned Service Accounts and Workload Identities

Service accounts and workload identities represent the non-human identity surface of your cloud environment. In Kubernetes deployments running on cloud infrastructure — a configuration that now describes the majority of enterprise containerized workloads — the combination of Kubernetes service account tokens and cloud workload identity federation creates layered escalation opportunities that span both the orchestration layer and the cloud control plane.

The attack pattern typically unfolds as follows: An attacker compromises a container (through a vulnerable application, supply chain attack, or misconfigured pod security policy). They read the Kubernetes service account token mounted in the container at /var/run/secrets/kubernetes.io/serviceaccount/token. If that service account has been federated to a cloud IAM role through Workload Identity (GKE) or IRSA (AWS EKS), the token can be exchanged for cloud credentials — potentially with permissions far exceeding what the containerized workload legitimately requires.

The Scope Creep Problem

Google’s 2025 Cloud Security Posture Management benchmark data indicated that the median GCP project has service accounts with 4.3 times more permissions than are actually utilized over a 90-day period. This permission bloat is not malicious — it accumulates through the natural tendency to assign broad roles at project creation and never revisit them as the actual usage pattern becomes clear.

From an attacker’s perspective, this excess is an invitation. A service account granted roles/editor at the project level because it “needs to deploy functions” also has the authority to read secrets from Secret Manager, modify IAM bindings (within certain constraints), and access virtually every data store in that project. Compromising the workload that uses that service account is equivalent to compromising the entire project.

Attack Path Four: Third-Party Integration and OAuth Token Abuse

Modern cloud environments rarely operate in isolation. They connect to dozens of third-party SaaS platforms, security tools, monitoring services, and CI/CD systems through OAuth integrations, API keys, and cross-account trust relationships. Each integration represents a potential escalation vector that exists entirely outside the organization’s core IAM boundary.

A particularly dangerous pattern involves OAuth applications granted broad administrative scopes within cloud management platforms. When a developer authorizes a third-party tool to “manage cloud resources” without restricting scope, and that tool is subsequently compromised (either through a supply chain attack or breach of the tool vendor), the adversary inherits whatever permissions were granted to that application.

The SolarWinds Precedent and Supply Chain Escalation

The SolarWinds SUNBURST campaign demonstrated at scale what cloud security researchers had been modeling theoretically: a compromised software supply chain element with legitimate integration into cloud management infrastructure can provide elevated access that bypasses virtually all standard detection mechanisms. The malicious updates executed in the context of a trusted, heavily-permissioned process — exactly the escalation path that anomaly detection systems are least equipped to flag.

In cloud-native environments, the equivalent scenario involves compromised Terraform providers, malicious GitHub Actions, or backdoored container base images that execute in the context of privileged CI/CD pipeline credentials. A 2026 Snyk report identified that 23% of enterprise CI/CD pipelines had pipeline-level credentials with production cloud administrative access — credentials that would represent catastrophic exposure if the pipeline toolchain were compromised.

Detection and Prevention Strategies That Actually Work

Effective defense against cloud privilege escalation requires moving beyond policy compliance and toward behavioral detection of the escalation pattern itself. Attackers are sophisticated enough to operate entirely within the bounds of legitimate API calls — the signal is not in whether an API call is allowed, but in whether it fits the established behavioral baseline of the identity making it.

Implementing Least-Privilege Dynamically

Static least-privilege — assigning minimal permissions at provisioning time — is necessary but insufficient. Cloud permissions need continuous right-sizing based on actual usage. Tools like AWS IAM Access Analyzer, GCP Policy Analyzer, and Azure Access Review, combined with commercial CSPM platforms, can identify and remediate excessive permissions on an ongoing basis rather than only at initial deployment.

The operational target should be permission utilization above 80%: if an identity is using less than 80% of its granted permissions over a 90-day window, those unused permissions represent escalation surface that should be revoked. This metric, tracked systematically, converts least-privilege from a one-time configuration activity into a continuous risk reduction program.

Cloud Detection Engineering Priorities

Detection engineering for privilege escalation should focus on several high-signal behavioral indicators: unusual AssumeRole chains (role A assuming role B assuming role C in rapid succession), API calls to IAM modification endpoints from identities that have not historically made such calls, metadata service requests originating from unexpected source processes, and cross-account activity initiated from identities that have not previously operated cross-account. These signals, correlated in a cloud-native SIEM or CNAPP platform, provide detection coverage that signature-based approaches fundamentally cannot replicate.

Key Takeaways

• Trust relationships are attack paths: Every IAM trust policy, service account binding, and OAuth authorization creates a potential escalation path. Map these relationships continuously, not just at deployment time.
• The metadata service remains high-risk: Force IMDSv2 enforcement across all EC2 instances without exception, and implement equivalent protections on GCP and Azure. Legacy compatibility is not an acceptable justification for SSRF exposure.
• Service account permissions demand ongoing right-sizing: Permission bloat is the norm, not the exception. Implement automated tools to identify and revoke permissions not used within a defined utilization window.
• Supply chain integrations extend your IAM boundary: Every third-party tool with cloud API access inherits your exposure. Audit OAuth scopes and cross-account trust relationships as rigorously as your internal IAM policies.
• Detection must target behavior, not signatures: Privilege escalation attacks use legitimate APIs. Detection engineering should model normal identity behavior and alert on deviations — particularly anomalous AssumeRole chains and unexpected IAM modification API activity.

Conclusion: Closing the Escalation Window

Privilege escalation in cloud environments succeeds not because attackers are finding exotic zero-day vulnerabilities — they’re exploiting the ordinary accumulation of overpermissioned identities, unreviewed trust relationships, and detection gaps that emerge when security programs can’t keep pace with infrastructure velocity. The attack paths described here are well-documented, actively exploited, and entirely defensible given the right combination of architecture discipline and behavioral detection.

The actionable next step is not another policy review. It is a purple team exercise specifically scoped to privilege escalation: commission your red team to execute IAM role chaining, metadata service exploitation, and service account abuse against a production-equivalent environment with monitoring enabled, then measure how quickly — and whether — your detection stack surfaces the activity. The gap between what your controls should catch and what they actually catch is your true risk exposure. Measure it deliberately, and close it systematically.