How Cloud Privilege Escalation Paths Form

Cloud permissions can create privilege-escalation paths that are easy to miss when permissions are reviewed individually. For example, an identity with s3:GetObject on specific buckets, lambda:CreateFunction, and iam:PassRole may appear to have limited privileges. But analyzed together, those permissions could form an escalation path: create a Lambda function, assign it a role with AdministratorAccess, invoke the function, and execute with administrator privileges.

This path is possible because three individually operational permissions combine to provide unrestricted access, assuming trust policies, IAM conditions, permission boundaries, and service constraints do not prevent it. Detecting these risks requires analyzing relationships between permissions as graph traversals rather than simply reviewing permission inventories.

Direct grant analysis asks "what can this identity do?" Path analysis asks "what can this identity become, grant, or create?" The distinction determines whether escalation paths remain invisible or become detectable through systematic analysis. Critically, graph reachability identifies candidate paths; determining whether a path is actually exploitable requires validating it against the full policy evaluation context, including SCPs, resource-based policies, permission boundaries, and IAM conditions.

Permission Combination Vs Direct Grant

Permission inventory shows what an identity holds directly. Path analysis computes what an identity can accumulate through delegation, assumption, and resource control. The gap between these views creates escalation opportunities that permission review misses systematically.

Consider an identity with these effective permissions: iam:PassRole on role prod-admin, lambda:CreateFunction, and lambda:InvokeFunction. Permission review categorizes this as controlled access — the identity cannot directly read sensitive data or modify critical resources. Path analysis identifies a potential escalation route: the identity creates a Lambda function, assigns prod-admin role to the function, invokes it, and operates with whatever permissions prod-admin holds. Whether this path is exploitable depends on additional factors — whether the prod-admin role's trust policy permits Lambda to assume it, whether IAM conditions or permission boundaries constrain the delegating identity, and whether SCPs restrict the account.

The escalation pattern exists because cloud permission systems separate resource control from authority delegation. An identity that controls a compute resource (Lambda function, EC2 instance, container task) can assign any role it has PassRole permission for to that resource. If the assignable role has broader permissions than the controlling identity, and if no other policy layer blocks the path, the result is privilege escalation through legitimate API operations.

AWS IAM documentation on iam:PassRole identifies the permission as allowing a user to associate an IAM role with an AWS service or resource, and notes that iam:PassRole must be evaluated in combination with other permissions because it enables the passing identity to grant authority it does not directly hold — specifically that a user with iam:PassRole can assign an IAM role with broader permissions than the user's own to a service, function, or instance the user controls (Source: docs.aws.amazon.com). This design enables legitimate automation while creating escalation paths when permissions combine without adequate constraints.

The detection challenge: each permission in the escalation sequence appears operational in isolation. iam:PassRole by itself does not grant elevated access — escalation only occurs when it is paired with control over a resource that can execute using the delegated role, and when the broader policy context does not prevent it. lambda:CreateFunction supports application deployment. The escalation emerges from their intersection with high-privilege roles that can be passed and with trust and condition configurations that do not close the path.

Test question: Can your IAM analysis tooling identify when an identity has both resource control permissions (create/modify compute resources) and delegation permissions (PassRole, role assignment) that target roles with broader authority than the identity holds directly — and can it validate whether those paths are exploitable given trust policies, permission boundaries, and SCPs?

The PassRole Pattern

iam:PassRole creates privilege escalation risk by allowing identities to assign roles to resources they control, but the permission itself does not confer elevated access. The escalation occurs when PassRole is combined with control over a compute resource that can execute using the delegated role, and when the role's trust policy allows the relevant service to assume it. The pattern applies across AWS services: Lambda functions, EC2 instances, ECS tasks, and other compute resources can execute with assigned IAM roles.

The escalation sequence follows this pattern:

(1) identity has iam:PassRole on role admin-role;

(2) identity creates a Lambda function;

(3) identity configures Lambda to execute with admin-role — which requires that admin-role's trust policy allows lambda.amazonaws.com as a principal;

(4) identity invokes Lambda, now executing as admin-role.

No single step requires admin permissions. The combination, when not constrained by trust policy restrictions, permission boundaries, or SCPs, can produce admin execution authority.

Why permission review misses it: iam:PassRole appears as a single delegation permission in access reviews. The escalation potential depends on correlating PassRole permissions against the roles that can be passed, the trust policies governing those roles, and the compute resources the identity controls. Without this correlation and trust policy validation, PassRole looks like routine automation enablement.

The pattern extends beyond Lambda. EC2 instance profiles, ECS task roles, and CodeBuild project service roles follow the same delegation model. An identity with instance creation permissions and PassRole on high-privilege roles may be able to launch EC2 instances that execute with escalated authority — again subject to whether role trust policies and other constraints permit it. The compute resource becomes a vehicle for accessing permissions the launching identity cannot use directly.

Mitigation starts with PassRole scoping. Instead of granting iam:PassRole on *, constrain it to specific roles that match the identity's operational requirements. For Lambda deployment automation, grant PassRole only on roles designed for Lambda execution, not on broad administrative roles. Restricting role trust policies to specific services and using IAM conditions — such as iam:PassedToService — further limits which roles can be delegated and to which service contexts. The constraint limits which roles can be delegated without blocking legitimate automation.

Control question: Do your PassRole permissions specify target roles explicitly, or do they grant delegation authority over roles with broader permissions than the delegating identity should access?

Role Chaining And AssumeRole

Multi-hop role assumption can create privilege escalation through chains that no single AssumeRole operation reveals. An identity assumes Role A; Role A can assume Role B; Role B has admin permissions. Each assumption step may appear constrained, but if the chain is fully traversable given the trust policies and conditions at each hop, it can produce access to elevated authority.

The chaining works because sts:AssumeRole permissions are evaluated independently at each hop, and trust policies at each intermediate role must explicitly permit the preceding principal. Role A trusts the origin identity for specific operational purposes. Role B trusts Role A for different operational purposes. The trust relationships may be legitimate individually but create escalation when combined transitively — and when no SCPs, permission boundaries, or session policy constraints interrupt the chain.

Detection requires tracing multi-hop paths, not only direct role assumptions from origin identities. An identity review that shows "can assume Role A" misses that Role A can assume Role B, and Role B can assume admin roles. The effective privilege ceiling may be Role B's admin access, not Role A's limited permissions — but only if each hop in the chain is actually traversable under real policy conditions.

Role chaining often emerges from operational boundaries in cloud environments. Development roles can assume staging roles for deployment automation. Staging roles can assume production roles for release promotion. Each boundary crossing may serve legitimate operational purposes, but the chain can enable development identities to reach production admin authority through the staging intermediary if intermediate roles have broader assumption permissions than intended.

The path becomes a real escalation vector when intermediate roles in the chain have broader assumption permissions than intended and when no compensating controls interrupt traversal. A staging role designed to deploy specific applications that gains AssumeRole permission on production admin roles through incremental policy expansion becomes a privilege escalation vector for any identity that can assume it — provided the trust policies and conditions at each hop are not otherwise restricting.

Azure RBAC and GCP IAM implement parallel patterns through role assignments and service account impersonation. The structural condition — delegated authority that can be chained transitively — exists across cloud providers with provider-specific mechanisms and controls.

Policy Attachment Escalation

Identities with policy modification permissions can escalate privileges by creating roles and attaching high-privilege policies to them. The pattern: create a new role, attach an existing admin policy or create a custom policy with broad permissions, assume the new role. Each API operation may appear legitimate; the escalation emerges when the sequence completes — and when the new role's trust policy permits the creating identity to assume it, and when permission boundaries or SCPs do not constrain the resulting access.

MITRE ATT&CK technique T1098.003 (Account Manipulation: Additional Cloud Roles) identifies the adversary behavior of creating or attaching additional cloud roles to existing cloud identities as a persistence and privilege escalation mechanism — noting that cloud identity manipulation allows attackers to establish persistence through role assignments and escalate access within cloud provider permission systems (Source: attack.mitre.org).

The escalation requires permissions that often exist independently: iam:CreateRole, iam:AttachRolePolicy (or iam:PutRolePolicy), and the ability to assume self-created roles. Identities with automation responsibilities commonly have role creation and policy attachment permissions for deploying application infrastructure. The escalation exploits these operational permissions for privilege expansion when those permissions are not adequately scoped and when permission boundaries do not cap the maximum authority of newly created roles.

Why detection is challenging: each API call is legitimate infrastructure automation. Creating roles, attaching policies, and assuming roles are normal operations in cloud environments. The escalation pattern becomes visible when these operations are correlated as a sequence targeting privilege expansion rather than infrastructure deployment, and when the resulting role's effective access is evaluated against what the creating identity should be permitted to reach.

The pattern varies by cloud provider but maintains structural consistency. AWS uses iam:CreateRole and iam:AttachRolePolicy. Azure uses role assignment operations to create custom roles and assign permissions. GCP uses iam.roles.create and iam.serviceAccounts.setIamPolicy. The detection challenge — correlating legitimate operations used for escalation — applies across platforms, as do the compensating controls such as permission boundaries and organization-level policy constraints.

Mitigation requires constraining policy attachment permissions based on the maximum privilege the identity should access, and using permission boundaries to cap the effective permissions of any roles the identity creates. Instead of granting AttachRolePolicy on all policies, limit it to policies that match the identity's operational scope. For application deployment automation, constrain policy attachment to application-specific policies, not administrative policies.

Control tradeoff: Restrictive policy attachment permissions reduce automation flexibility but prevent privilege escalation through role creation. The downstream implication is more granular permission management but constrained escalation vectors.

What Path Analysis Requires

Privilege escalation path detection requires computing transitive relationships between permissions, not enumerating direct grants. The analysis becomes a graph traversal problem: which permissions enable assumption, delegation, or modification of other principals, and what authority can be reached through multi-hop sequences.

Path analysis demands three capabilities that permission enumeration cannot provide: graph representation of permission relationships, transitive closure computation, and resource condition evaluation. Graph representation maps how permissions connect — which identities can assume which roles, which roles can be passed to which resources. Transitive closure computes what an identity can reach through multi-hop delegation chains. Resource condition evaluation determines whether paths are traversable based on trust policies, IAM conditions, permission boundaries, SCPs, and existing resources the identity can target.

An important distinction applies here: graph reachability identifies candidate escalation paths, but a reachable path is not necessarily an exploitable one. Validating exploitability requires evaluating the full AWS policy evaluation logic — including whether trust policies permit assumption at each hop, whether permission boundaries cap the resulting access, whether SCPs block specific operations, and whether resource-based policies impose additional constraints. Effective path analysis distinguishes theoretical reachability from validated, actionable escalation paths.

The operational constraint: path analysis at scale requires automated tooling. Manual review of permission combinations is not tractable for environments with hundreds of roles and thousands of policies. The combinatorial explosion of possible paths exceeds human analysis capacity in complex cloud environments.

Cloud Infrastructure Entitlement Management (CIEM) platforms address path analysis through different approaches, and many modern platforms already incorporate some degree of transitive relationship and attack-path analysis beyond simple permission enumeration. Some focus primarily on direct permission enumeration — showing what each identity can do directly. Others implement graph analysis to detect privilege escalation paths through permission combinations, with varying depth of trust policy validation and exploitability assessment. When evaluating tooling, the relevant question is not only whether the platform identifies candidate paths, but whether it validates them against real policy context to distinguish theoretical exposure from confirmed escalation risk.

The governance implication: effective privilege management requires detecting what identities can become, not only what they can do directly. Permission review that stops at direct grants misses escalation paths that emerge from legitimate permission combinations. The control gap becomes visible when incidents involve privilege escalation through paths that permission review did not detect.

Evaluation question: Does your privilege analysis detect escalation paths through permission combinations and validate their exploitability against trust policies, permission boundaries, and SCPs — or does it enumerate direct grants without computing transitive relationships?

| Cloud Privilege Escalation Paths |
|---|---|---|---|
| Path Type | Starting Permission(s) | What the Path Enables | Why Permission Review Misses It |
| iam:PassRole escalation | iam:PassRole on high-privilege role + compute resource control (lambda:CreateFunction, ec2:RunInstances) | Assigning admin roles to controlled resources and executing with escalated authority — when role trust policies permit the target service, and no permission boundaries or SCPs block it | iam:PassRole appears as a single automation permission; the escalation requires correlating it with controllable resources, passable roles, and trust policy configurations |
| Role chaining via AssumeRole | sts:AssumeRole on intermediate role + that role's broader AssumeRole permissions | Multi-hop privilege escalation through legitimate role assumption chains, when trust policies at each hop permit traversal | Each AssumeRole permission appears constrained; the escalation emerges from transitive trust relationships across the chain that are not interrupted by conditions or SCPs |
| CreateRole + AttachPolicy | iam:CreateRole + iam:AttachRolePolicy + ability to assume self-created roles | Creating new roles with admin policies and assuming them for unrestricted access — when permission boundaries do not cap resulting access | Each permission supports legitimate automation; the escalation is visible only when the three-step sequence is correlated as privilege expansion, and the resulting access is evaluated |
| Policy modification on existing roles | iam:PutRolePolicy or iam:AttachRolePolicy on assumable roles + sts:AssumeRole on those roles | Modifying role permissions and assuming the enhanced role | Policy modification appears as normal role maintenance; the escalation requires detecting modification followed by assumption of the enhanced role and evaluating the net access change |

Related Coverage

Sources