Tushar Verma maps AWS privilege paths
- Tushar Verma, a security engineer and Synack red teamer, published an AWS IAM privilege-path map that turns scattered misconfigurations into one attack tree. - The useful detail is the path logic itself — role chaining, permissive policy actions, and cross-account trust links combine into multi-hop escalation routes. - That matters because AWS account boundaries are only as strong as the roles crossing them.
AWS IAM failures are rarely one bad permission sitting alone. The real problem is the path — one harmless-looking role, one trust relationship, one policy action, then suddenly a low-privilege foothold can hop into something much stronger. That is the point of Tushar Verma’s new AWS privilege-path map: it turns cloud privilege escalation from a checklist into a route-planning problem. Verma is a security engineer and Synack red teamer, and the diagram lands because it mirrors how attackers actually move. ### What is he actually mapping? He is mapping privilege paths inside AWS Identity and Access Management — IAM. That means not just “who has admin,” but which combinations of users, roles, policies, and trust relationships can be chained into higher access. Older AWS escalation research already showed that seemingly narrow permissions like `iam:CreatePolicyVersion` can become full account takeover if attached in the wrong place. (github.com) Verma’s contribution is the visual framing — one misconfiguration is bad, but several ordinary ones connected together are worse. ### Why is “path” the right word? Because AWS access is graph-shaped, not list-shaped. A principal can assume a role, that role can touch another service, that service can expose credentials or let the principal modify something else, and the next hop opens more doors. In big environments, especially multi-account ones, that logic gets hard to hold in your head. That is exactly why tools like IAMGraph model AWS permissions as attack paths rather than static entitlements. (rhinosecuritylabs.com) ### Where do cross-account trusts fit in? This is the part a lot of teams underestimate. AWS treats an account as a security boundary, but cross-account roles deliberately poke holes through that boundary. A role in one account can trust a principal in another account, and if the identity-side permissions also allow `sts:AssumeRole`, the jump is valid. That is useful for real operations — vendors, shared services, CI/CD — but it also means one weaker account can become the stepping stone into a more sensitive one. (labs.withsecure.com) ### Why does role chaining keep coming up? Because role chaining is the cleanest way to turn “some access” into “better access.” AWS supports it — assume one role, then use those temporary credentials to assume another. But if the second role is broader, the chain becomes escalation. Detection teams care about it for the same reason attackers do: it can hide lateral movement and refresh sessions as the actor keeps hopping. (docs.aws.amazon.com) ### What kinds of permissions are the usual trapdoors? The classics are still the classics. Permissions that let a principal create or swap policy versions, attach policies, pass roles, or otherwise reshape identity controls are dangerous because they are meta-permissions — they do not just access a resource, they change who can access everything else. Rhino Security Labs documented 21 AWS IAM escalation routes years ago, and the lesson still holds: the risky part is often the combination, not the single API call in isolation. (detection.fyi) ### So what should defenders do with a map like this? Use it during architecture reviews, not after an incident. Ask which roles can assume which other roles. Ask which accounts trust whole external accounts instead of specific principals. Ask which permissions let a workload rewrite IAM state. Basically, stop auditing identities one by one and start tracing reachable privilege. That is also the logic behind graph-based analysis tools for large AWS estates. (rhinosecuritylabs.com) ### What is the bottom line? Verma’s map matters because it nudges teams toward the right mental model. AWS privilege escalation is usually not a single catastrophic mistake. It is a chain of reasonable-looking decisions that, together, form a route. If you can see the route, you can break it. (github.com) (docs.aws.amazon.com)
