“Role assumption helps follow the principle of least privilege… However, privilege escalation via role assumption is a scenario where a user with limited IAM permissions can gain elevated access to resources using a misconfigured IAM role.”
IAM is the real perimeter in AWS, and the part of it people get wrong is not the permissions policy — it is the trust policy. A role can be locked down to the narrowest set of actions imaginable, and still be assumable by a wildcard principal that lets a read-only user step into it. This guide takes that single, common, high-impact mistake — abusing sts:AssumeRole to escalate — and works it end to end.
Shifting Focus to Trust Policies
Architects spend their attention on the permissions policy (what a role can do) and skim the trust policy (who is allowed to become it). That asymmetry is the whole vulnerability. The guide shows how a loose trust policy — an overly broad Principal, or one missing a condition like sts:ExternalId — lets an IAM user who was only ever meant to have read access assume an administrative role and inherit everything it can do.
Building and Breaking the Environment
The book is hands-on rather than hypothetical. The first half is a lab build: you deliberately stand up the vulnerable setup — low-privilege users mapped against over-permissive roles — before attacking it. That ordering is the right call, because seeing the misconfiguration from the console side is what lets you recognise it later in an estate you did not build, where it will not be labelled “vulnerable”.
The Attack Methodology
With the lab live, it moves into enumeration and exploitation — from native AWS CLI calls to automation like the Python enumerate-iam script for mapping which principals can assume what. The exploitation itself is a clean demonstration: request temporary credentials from STS, assume the privileged role, and reach resources that were off-limits a moment earlier, such as restricted S3 buckets. Worth noting for anyone replaying it on a real assessment — every one of those AssumeRole calls lands in CloudTrail, so this is loud by nature, which is exactly what makes it detectable.
Who Is This Guide REALLY For?
- Cloud Penetration Testers: Essential.
AssumeRoleescalation is among the fastest routes to full account takeover. - AWS Administrators & DevSecOps Teams: Seeing how enumeration parses your IAM graph is the argument for tightening trust policies and adding conditions, not just trimming permissions.
- Security Analysts: It maps neatly onto detection — the STS spikes and anomalous
AssumeRolepatterns in CloudTrail that a SOC should be alerting on.
The Bottom Line
Not an overview — a strike manual on one vulnerability, taken seriously. By joining how the misconfiguration is created to how it is exploited, it teaches least privilege as something you verify on both sides of a role, permissions and trust, rather than assume.
