Hunting for IAM privilege escalation in AWS

Cloud Security Posture Management (CSPM) tools have largely solved the problem of finding individual IAM misconfigurations. Wildcards on resources, iam:PassRole granted to dev users, S3 bucket policies that allow public read — all flagged by Prowler, ScoutSuite, AWS Access Analyzer, and every commercial CSPM in the market.

The interesting bugs are the chains.

What a chain looks like

A “chain” in this context is a sequence of two or three policies that, individually, look reasonable. Combined, they let a low-privilege principal climb to administrator.

A typical example I see in audits:

1. A developer role has lambda:UpdateFunctionCode on a specific function.
2. That function’s execution role has iam:AttachRolePolicy.
3. The developer can update the Lambda to call iam:AttachRolePolicy to attach AdministratorAccess to themselves.

Each individual permission looks like it was granted for a defensible reason. The chain is the bug.

The tool I actually use

PMapper from NCC Group remains the best open-source IAM graph analyser. Run it weekly against your account, watch for new edges. Most CSPM products do not model these graph traversals — they evaluate policies one at a time.

Beyond graph traversal

The chains that graph tools miss tend to involve services that are not modelled in the AWS authorisation logic — STS session tags, SSO permission sets, federated identities. Those still need manual review.

A clean engagement covers both: graph traversal across the documented services, plus manual analysis of the federation layer.