AWS IAM privilege escalation testing: technical methodology

AWS IAM privilege escalation is not one vulnerability or a fixed list of dangerous API actions. It is an emergent path through identity policies, resource policies, role trust, permissions boundaries, organisation guardrails and the ability to pass a role to an AWS service. A rigorous IAM assessment therefore asks more than “which calls does this identity have?” It determines the highest-impact outcome the identity can reach through an allowed sequence and the control expected to stop that sequence.

The safest methodology combines permission-graph analysis, policy validation, a controlled proof in an isolated account and CloudTrail evidence. There is rarely a reason to create a persistent administrator or retrieve production data. A purpose-built test role, a harmless canary resource, a short session and a documented rollback can prove the same security conclusion with much less operational risk.

The concise answer: what creates an IAM escalation path?

Escalation exists when a lower-trust principal can expand its own effective permissions, influence a more privileged identity, or make an AWS service act under a role that the principal cannot assume directly. One broad policy can create the problem, but real environments more often expose a chain of individually plausible permissions.

Common path classes include:

• changing a managed policy version, inline policy, group membership or permissions boundary;
• editing a role trust policy or the conditions governing sts:AssumeRole;
• creating or replacing credentials for another identity;
• combining iam:PassRole with control over a service that runs code or a job under the passed role;
• modifying code, an image, bootstrap configuration or automation executed by a stronger role;
• using an S3, KMS, queue, function or other resource policy as a cross-account bridge;
• bypassing an intended restriction because a resource, Region, tag, organisation or source condition is absent or user-controlled.

The destination does not have to be AdministratorAccess. Moving from read-only access to production deployment, retrieving a high-value secret, changing a security pipeline or acting as a release role is meaningful privilege escalation.

How AWS calculates effective access

An assessment must reproduce the official IAM policy evaluation logic. AWS authenticates the principal, builds request context and evaluates relevant statements against the action, resource, principal and conditions. An explicit deny overrides an allow.

Within an account, identity and resource policies can contribute permissions, while a permissions boundary and a session policy constrain the result by intersection. AWS Organizations service control policies define the maximum available permission set for member accounts; an SCP does not grant a permission by itself. Resource control policies must also be considered where deployed. Conditions such as aws:PrincipalOrgID, aws:SourceArn, aws:SourceAccount, resource or principal tags, MFA state and requested Region can change the outcome materially.

This is why reviewing one JSON document is insufficient. An apparently broad identity policy may be constrained by a boundary and SCP. Conversely, a narrow-looking policy may open a path to a much stronger role. Every conclusion should retain the full context: principal, account, session, boundary, SCP, resource policy, trust policy and relevant condition values.

A technical graph model: principal, edge and outcome

A useful model has three layers. The first is the principal: IAM user, role, federated session, workload, AWS service or external-account principal. The second contains edges: assume a role, change a policy, pass a role, update executable code or retrieve a credential. The third represents the business outcome: reach data, alter infrastructure, influence CI/CD, take over an identity or reduce accountability.

Each edge requires explicit predicates:

Element	Question to answer
Action	Can the starting principal really invoke it?
Resource	Is the ARN bounded or wildcarded?
Trust	Does the destination role trust the intended principal and organisation?
Condition	Are the source ARN, external ID, tag or MFA conditions satisfiable?
Guardrail	Does a boundary, session policy, SCP or RCP remove the permission?
State	Can the tester create a missing resource or alter a prerequisite?
Proof	What reversible action proves the edge without harmful impact?

This graph exposes transitive reachability that a per-policy scanner can miss.

Why iam:PassRole needs a dedicated test

iam:PassRole is not a standalone API operation. AWS checks it when a principal supplies a role to a supported service while creating or updating a resource. Risk is therefore the combination of which role may be passed, which service receives it and which part of that service’s execution the principal controls.

PassRole without the ability to create or change a relevant resource may not form a usable path. On the other hand, permission to launch a function, container task, instance, automation document or job with an arbitrary role can expose that role’s capabilities indirectly. A strong policy constrains Resource to named roles, applies iam:PassedToService, separates runtime roles from administrative roles and prevents the same operator from modifying the role they may pass.

A safe proof does not require a shell or secret retrieval. The team can pass a laboratory role and demonstrate one harmless permission against a dedicated canary object. The evidence package should contain the configuration, CloudTrail events, time-limited session and confirmed cleanup.

Role trust and cross-account access

A trust policy answers who may assume a role; permission policies determine what the role may do after assumption. Both sides are required for an accurate conclusion. Risk patterns include trusting an entire account without sufficient conditions, over-broad principals, missing organisation constraints and an incorrect external-ID design for third-party integrations.

In a multi-account landing zone, analysis must follow paths through the identity account, tooling account, workload account and production. Include roles created by CloudFormation, Terraform, backup products, observability tooling and CI/CD platforms. A low-privilege identity in one account may control code or deployment state consumed by a privileged role in another.

This identity analysis complements a broader AWS, Azure and GCP penetration test and the review of common cloud security misconfigurations.

A safe AWS IAM penetration-testing methodology

1. Define rules and acceptable proof

Scope should list accounts, organisation boundaries, Regions, excluded roles, testing windows and emergency session-revocation contacts. Agree whether testers may create tagged resources, assume test roles, alter test-only tags and generate detection events. Customer data, production secrets, destructive operations and uncontrolled spend should be expressly excluded.

2. Build a complete inventory

Collect users, roles, groups, managed and inline policies, boundaries, identity providers, instance profiles, service-linked roles, resource policies and Organizations structure. Identify long-lived access keys, unused permissions, unowned roles and identities whose purpose no longer matches their current access.

3. Perform static and graph analysis

IAM Access Analyzer can validate policies and identify external or unused access. Its findings should be combined with dependency-graph analysis and manual condition review. The IAM policy simulator is useful for selected decisions, but it cannot represent every service side effect or all relevant resource state. Simulation is evidence, not a substitute for system modelling.

4. Select the minimum dynamic proof

Define the smallest reversible action for each candidate path. Prefer a dedicated canary object, purpose-built role and short session. If policy analysis and a harmless assumption test prove the conclusion, do not modify a production policy merely to make the demonstration more dramatic.

5. Roll back and retest

Cleanup includes roles, policies, policy versions, keys, service resources, sessions and test artefacts. A remediation retest should prove that the graph edge disappeared and that the same destination is not reachable through an alternative principal or service.

CloudTrail detection and identity telemetry

AWS CloudTrail should cover every account and Region, send events to a protected central logging account and trigger alerts for sensitive identity changes. Monitor operations that create policy versions, alter trust, attach policies, create keys, modify boundaries and pass roles to newly created resources.

Effective detection correlates:

• the source identity and session lineage, including federation and chained role assumptions;
• unusual source addresses, Regions, user agents and times;
• an IAM change followed by access to Secrets Manager, KMS, S3 or deployment systems;
• creation of a service resource with a privileged role followed by calls from that role;
• repeated AccessDenied events before a successful permission change;
• trail disablement, logging-bucket policy changes or interference with alerting.

Protect the telemetry itself. A principal able to expand access and erase the evidence represents a much larger risk than one constrained by immutable organisation-level logging.

Hardening the path, not just one API action

AWS recommends temporary credentials, federation, MFA, least privilege and removal of unused access in its IAM security best practices. A durable programme should:

1. separate human, CI/CD, administrative and runtime roles;
2. constrain iam:PassRole by role ARN and destination service;
3. tightly protect policy versions, trust policies and boundaries;
4. use SCPs as guardrails for outcomes that must never occur in member accounts;
5. require review for privileged role and resource-policy changes;
6. use tag-based access only when the subject cannot freely change decisive tags;
7. remove static keys and shorten privileged sessions;
8. separate permission to deploy code from permission to select an execution role;
9. manage credentials through a tested Vault, KMS and secrets-rotation process;
10. govern emergency and administrative identities with privileged access management.

Assume that one valid session will eventually be compromised and contain its reach according to Zero Trust architecture.

AWS IAM escalation assessment checklist

• Every account and role has an owner, purpose and trust level.
• Analysis covers identity, resource, trust, boundary, session, SCP and RCP policies.
• iam:PassRole is constrained by both role and destination service.
• A user cannot modify the role, boundary or tag that defines their own ceiling.
• Cross-account trust uses precise principals and appropriate organisation or vendor conditions.
• A pipeline operator cannot both replace code and choose an arbitrary runtime role.
• Dynamic proofs use a dedicated resource, short session and reversible outcome.
• Organisation-level, multi-Region CloudTrail feeds a protected logging account.
• Detections connect an IAM change to later use of the newly acquired capability.
• Every test artefact is removed and absence is confirmed through inventory.
• Remediation removes the full graph path, and the retest checks alternative edges.

Reporting a result that engineers can remediate

Each finding should identify the starting principal, prerequisites, graph edges, destination identity or service, maximum outcome, CloudTrail evidence, testing limitations and remediation. Severity should reflect how the principal is reached, session lifetime, production context, data sensitivity and the ability to impair logging.

The most useful diagram is a compact “identity → permitted change → role or service → outcome” path. It directs the owner to the real root cause: an over-broad resource, weak trust, unrestricted PassRole or an unsafe combination of duties.

Primary sources

• AWS IAM — Policy evaluation logic
• AWS IAM — Security best practices
• AWS IAM Access Analyzer — Policy validation
• AWS IAM — Permissions boundaries
• AWS IAM — Granting permission to pass a role
• AWS CloudTrail User Guide