Cloud Privilege Escalation: AWS and GCP Attack Paths That Don't Require Admin Access

Most security teams model privilege escalation as an on-premises problem — a junior AD account abusing a Kerberoastable service principal, or a misconfigured GPO granting local admin rights. Cloud environments require a fundamentally different mental model. In AWS and GCP, privilege escalation is policy-based, API-driven, and frequently invisible to defenders who haven't specifically configured cloud-native audit logging to capture it. An attacker with a single misconfigured IAM permission can move from a developer's compromised credentials to full administrative control of an AWS account — without ever touching a traditional "admin" action.

This is not theoretical. Misconfigured IAM is the most consistently exploited finding across cloud penetration tests, and the attack paths are well-documented in cloud provider documentation — which means motivated attackers know them. The question is whether your security team does too.

Why Cloud Privilege Escalation Is Different

In a traditional on-premises environment, privilege escalation typically involves exploiting software vulnerabilities, abusing trust relationships between systems, or leveraging credentials that grant direct access to privileged groups. The escalation is often detectable because it produces noisy artifacts — failed logon attempts, lateral movement over SMB, or unexpected process execution.

Cloud environments are fundamentally different. Every action is an API call. Privilege escalation occurs through permission chains — sequences of individually low-risk permissions that, when combined, allow an attacker to grant themselves additional access, create new privileged credentials, or execute code under a more privileged identity. The API calls that constitute an escalation chain often look identical to legitimate developer activity in CloudTrail or GCP Audit Logs, making detection without specific alerting rules difficult.

What makes this especially dangerous is that cloud IAM policies are complex enough that engineering teams routinely grant permissions they don't fully understand the implications of. The iam:PassRole permission in AWS, for example, is often granted broadly to developers who "need to deploy Lambda functions" — without understanding that the same permission, combined with lambda:CreateFunction and lambda:InvokeFunction, creates a direct path to assuming any IAM role in the account.

AWS Privilege Escalation Paths

iam:PassRole — The Gateway Permission

The iam:PassRole action allows a principal to assign an IAM role to an AWS service. On its own, this seems benign — it's how developers tell Lambda "run with this role." The problem arises when an attacker combines iam:PassRole with service invocation permissions. If a principal can pass a high-privilege role to Lambda (lambda:CreateFunction + lambda:InvokeFunction), they can create a function that executes under the target role's permissions and exfiltrate credentials or perform privileged actions — without ever directly assuming the role themselves.

The same pattern applies with EC2: iam:PassRole combined with ec2:RunInstances allows an attacker to launch a new EC2 instance with an administrator role attached, then access the instance metadata service to retrieve temporary credentials for that role. This path is remarkably common in real environments because EC2 deployment automation frequently requires both permissions.

iam:CreatePolicyVersion

If a principal has the iam:CreatePolicyVersion permission for a policy attached to a privileged role or group, they can create a new version of that policy granting themselves or all principals full administrative access. AWS allows up to five versions of a managed policy — an attacker can set the new version as the default, instantly granting administrator access to whatever the policy is attached to.

sts:AssumeRole Chains

Cross-account role assumption chains are a consistent source of privilege escalation in multi-account AWS environments. An attacker who compromises credentials in a development account may find roles with trust policies permitting assumption from other accounts, or roles in shared services accounts that have excessive permissions in production. Enumerating role trust policies and testing which can be assumed from a compromised principal is a core component of any cloud penetration test.

EC2 Instance Metadata Service v1 SSRF

IMDSv1 (the original EC2 Instance Metadata Service) accepts unauthenticated HTTP requests to 169.254.169.254 from any process running on the instance — including web application processes. If an application running on EC2 is vulnerable to Server-Side Request Forgery (SSRF), an attacker can pivot from a web vulnerability to retrieving the instance's IAM role credentials from the metadata service. From there, the scope of compromise is determined entirely by the permissions of the attached role. This is the attack chain behind the Capital One breach.

GCP Privilege Escalation Paths

Service Account Impersonation via iam.serviceAccounts.actAs

In GCP, the iam.serviceAccounts.actAs permission allows a principal to act as — impersonate — a service account. This permission is required when deploying Cloud Functions or Cloud Run services with a specific service account, which means it's broadly granted in many organizations. An attacker with this permission on a privileged service account can generate short-lived OAuth tokens for that account, effectively assuming its identity and inheriting all of its project-level or org-level IAM bindings.

Project-Level vs. Org-Level Bindings

GCP's IAM model distinguishes between bindings at the project level and the organization level. A common misconfiguration grants a service account a high-privilege role (like roles/editor or roles/owner) at the project level — which may be intentional — while failing to restrict which principals can impersonate that service account. An attacker with access to any project that can impersonate the privileged account has effectively escalated to organization-wide access if the service account has org-level bindings.

Workload Identity Abuse

GCP Workload Identity allows Kubernetes service accounts to impersonate GCP service accounts — a powerful feature for removing the need to manage service account keys in GKE clusters. Misconfigurations in the Workload Identity binding (for example, binding to allUsers or using overly broad namespace selectors) can allow workloads running in shared clusters to assume the identity of privileged GCP service accounts they have no legitimate need to access.

Escalation Path Comparison Across Cloud Providers

How Lorikeet Tests Cloud Environments

When Lorikeet Security conducts a cloud penetration test, the engagement begins with a realistic attacker starting point — typically either a set of low-privilege IAM credentials (simulating compromised developer credentials or a leaked service account key) or a black-box assessment starting from the public attack surface. The test maps the exact permission chains available from that starting point, not just individual misconfigured permissions.

This matters because automated cloud security posture management (CSPM) tools check for known bad configurations in isolation — an overly permissive role, an unencrypted S3 bucket, a public security group. They do not model how an attacker chains three medium-severity issues together into a critical impact path. A manual cloud penetration test examines the combinatorial attack surface: which permissions can be combined, which roles can be assumed from which others, and which services expose IAM credentials via metadata services or environment variables.

Our cloud security assessments cover IAM permission analysis, trust relationship enumeration, metadata service exposure, secrets sprawl in environment variables and SSM Parameter Store, logging gaps, and data plane access controls — producing a prioritized finding report that maps each escalation path to its business impact and the specific policy changes required to close it.

Remediation: Closing the Escalation Paths

IAM Permissions Boundaries (AWS)

Permissions Boundaries are IAM policies attached to a principal that define the maximum permissions it can ever have, regardless of what identity-based policies grant. They are the most effective control for constraining developer and automation roles — even if a principal has iam:CreatePolicyVersion, a Permissions Boundary can prevent any policy it creates from granting permissions outside a defined safe set. Organizations deploying at scale should enforce Permissions Boundaries via Service Control Policies at the AWS Organizations level.

IAM Access Analyzer

AWS IAM Access Analyzer identifies resource policies that grant access to external principals and can flag overly permissive trust relationships. It does not catch all privilege escalation paths but is an effective baseline control for catching externally accessible resources and cross-account trust misconfiguration. Enable Access Analyzer in every region and review findings on a regular cadence.

Deny Policies for Known Escalation Actions

Service Control Policies (AWS) and Organization Policy constraints (GCP) can enforce deny rules for the highest-risk escalation permissions — for example, denying iam:CreatePolicyVersion, iam:AttachUserPolicy, and iam:PutRolePolicy for all principals except a break-glass administrator role. This defense-in-depth layer prevents escalation even if an individual account's IAM policies are misconfigured.

IMDSv2 Enforcement

Requiring IMDSv2 on all EC2 instances closes the SSRF-to-metadata escalation path. IMDSv2 requires a session-oriented PUT request to obtain a token before making metadata queries — a simple SSRF that sends GET requests cannot retrieve credentials. Enforce IMDSv2 via a Service Control Policy denying ec2:RunInstances when ec2:MetadataHttpTokens is not set to required. This is a straightforward control with high impact on SSRF risk reduction.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.