Hunting Iam Privilege Escalation Paths

Hunting IAM privilege-escalation paths: a reachable chain to admin is the bug

Cloud access is a graph. Principals hold policies, policies grant permissions, and some of those permissions let a principal change the graph itself: pass a role, rewrite a policy, assume another identity. Privilege escalation is a path through that graph from where an attacker starts to a principal that can read the data or run the workloads that matter. No single permission looks alarming. The bug is the reachable chain, and you only see it when you follow the edges.

When to use

• You are reviewing cloud IAM: roles, policies, groups, and trust relationships.
• A principal is meant to be low-privileged and you want to prove it cannot reach admin.
• You have the policy documents and want to know what they compose into, not just what each says.

Scope check

Audit identity configuration in accounts you own or are authorized to test, with credentials provisioned for the review. If you can't name the authorization, stop.

The loop

1. Build the identity graph. Inventory every principal, the policies attached to it, the permissions those policies grant, and the resources they touch. Represent it as edges: principal grants permission on resource. The whole method is reachability over this graph, so the graph is the first artifact.

2. Enumerate the escalation primitives. Mark every permission that lets a principal change the graph rather than just use it: passing a more privileged role to a compute or automation service, creating or rewriting a policy version, attaching a policy to yourself, updating a function or task that already runs as a privileged role, or minting credentials for another identity. These edges are how one node reaches another's privilege.

3. Map trust relationships and their conditions. For each assumable identity, read who is allowed to assume it and under what condition. A trust that names a broad set of principals, a wildcard, or a condition that an attacker can satisfy is an edge into that identity. A precise trust condition is not.

4. Search for a path from an untrusted start to a privileged target. Starting from a low-privileged or externally reachable principal, follow escalation and trust edges toward any principal that can read sensitive data or administer the account. Record the exact sequence of permissions the path uses.

5. Check the boundary controls. A path is only real if nothing stops it. Confirm whether an organization guardrail, a permission boundary, or a session policy denies a step on the chain. A boundary that caps the effective permission breaks the path; its absence leaves the path live.

6. Confirm and record. Confirm a path by walking it with the starting credentials in an authorized account and reaching the target privilege. Kill the lead if a boundary denies a step, the trust condition cannot be met, or no escalation edge connects the start to any privileged node. Record the full witness path: each principal, each permission used, and the target reached.

Where IAM privilege escalation hides

• The dangerous permissions are the ones that change identity. Passing a role, rewriting a policy, and assuming an identity matter far more than any single read.
• Trust conditions are edges. A loose trust relationship is a door into a more privileged identity, and it is easy to write one wider than intended.
• A chain of harmless steps is not harmless. Each permission on the path can be defensible alone; the composition is the escalation.
• Boundaries decide whether a path is real. The same permissions escalate in an account with no guardrail and dead-end in one with a boundary that caps them.

Worked example (a confirm and a kill)

Confirm. A build principal may pass any role to the automation service and may update the automation job definition. It passes a role that has administrative policies, points a job at it, and runs the job, which now executes as admin. Walking it from the build credentials reaches account administration. Confirmed role-pass to admin, critical, remediation = restrict which roles the principal may pass to the exact roles it needs, and separate job-definition rights from role-passing rights.

Kill. A principal can rewrite policy versions, which looks like an escalation primitive, but a permission boundary on that principal caps its effective permissions to a read-only set, and every privileged role's trust condition names a specific service under a condition the principal cannot satisfy. Walking every candidate path dead-ends at the boundary. Killed, kill_reason = "permission boundary caps effective permissions; privileged trust conditions unsatisfiable from this principal; no path reaches a privileged node."

Rationalizations to reject

• "Each permission is scoped and reviewed." → Escalation is the composition, not the single grant. Follow the edges the permissions create.
• "That role is only for the CI service." → Then the trust condition must pin it to that service under a condition an attacker cannot forge. Read the condition.
• "There is a guardrail on the account." → Confirm it denies a step on this specific path. A guardrail that does not cover the primitive does not stop it.
• "You would need several permissions to pull that off." → An attacker who lands on the starting principal has them. That is the path.

Executing this in practice

You need the full set of policy and trust documents, a way to compose them into a reachability graph rather than reading each in isolation, and authorized credentials to walk a candidate path to the target. A graph that treats principals as nodes and identity-changing permissions and trust conditions as edges is ideal, because the finding is a path and a path is a graph query; the walk from the starting credential is the confirmation.

Related

• auditing-cicd-oidc-trust - the pipeline identity that often is the untrusted starting principal for one of these paths.
• hunting-non-human-identity-and-secret-reachability - the leaked machine credential that lands an attacker on the starting node.
• auditing-declarative-authorization - the application-layer counterpart, where authorization is configuration rather than identity-graph edges.
• FINDING-SCHEMA.md - source = the low-privileged starting principal, sink = the administrative or data-access principal the path reaches.