The IAM Policy That Looks Read-Only But Isn't

Industry research this year keeps surfacing the same pattern: IAM policies that allow privilege escalation show up in the large majority of cloud accounts studied, and the scary part isn't that someone attached AdministratorAccess by mistake — it's that a policy which looks properly scoped down can still hand out a path to admin. One recent documented incident went from a single exposed credential to full administrative privileges across 19 AWS principals in under ten minutes.

The actions that matter more than they look

A handful of IAM actions, granted individually and looking harmless on their own, combine into a privilege-escalation path. If a policy grants any of these to a principal that also has any way to run compute, treat it as equivalent to broad admin access until proven otherwise:

• iam:PassRole combined with the ability to launch a Lambda function, EC2 instance, or ECS task — pass a highly-privileged role to a resource you control, then use that resource to act as the role.
• iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion on any policy — rewrite what an existing, already-trusted policy grants without touching who it's attached to.
• iam:AttachUserPolicy, iam:AttachRolePolicy, or iam:AttachGroupPolicy scoped to “*” — attach AdministratorAccess to yourself or anything else, directly.
• sts:AssumeRole on a wildcard resource — assume any role in the account that trusts your principal, including ones created later.

Why this hides inside “safe-looking” policies

None of these four actions require broad resource wildcards to be dangerous — they're often granted narrowly, for a legitimate reason, years apart from each other, by different people, none of whom saw the combination. A deployment role gets PassRole for CI/CD. A separate automation role gets policy-version write access for a one-off migration. Neither grant looks like a finding in isolation. Together, on a principal an attacker can reach, they're an escalation path.

How to actually find this

IAM Access Analyzer's policy checks and the open-source privilege-escalation scanners built specifically for this pattern (checking for these action combinations across every principal, not just the ones an admin remembers to look at) both catch this faster than a manual read of every policy document — which, past a few dozen roles, stops being a realistic option anyway. This is exactly the kind of finding a Well-Architected Security Pillar review is built to surface, because it requires looking at IAM as a graph of what's reachable, not a list of policies read one at a time.