IAM misconfigurations

Why IAM misconfigurations are a category of their own

Earlier in this unit you saw the cloud identity model, least-privilege policy authoring, and how role assumption and federation work. This lesson is where those go wrong in production — not through exploitable code, but through grants that are individually defensible and collectively catastrophic.

That distinction is the whole game. A SQL injection is a bug: the code does something its author never intended. An IAM misconfiguration is a grant: the system does exactly what the policy says, and the policy says too much. Scanners that look for malformed input find nothing, because nothing is malformed. CloudTrail shows a clean 200 on every call, because every call was authorized. The damage is done entirely within the lines of the permission you wrote. This is why IAM review is read as reachability, not syntax: the question is never “is this policy valid?” — it’s “what is the transitive closure of everything this principal can reach?”

Two shapes dominate real incidents, and a senior learns to see both as paths, not statements: privilege escalation (a grant that lets a principal grant itself more) and the confused deputy (a trusted service that acts on attacker-supplied input with its own authority, not the attacker’s).

Privilege escalation: when a permission lets you grant yourself more

Privilege escalation is the misconfig where a principal holds a permission that, used as designed, lets it acquire permissions it was never given. The single most important one to recognize is iam:PassRole.

PassRole exists for a legitimate reason: when you create a Lambda function, an EC2 instance, or an ECS task, something has to attach an execution role so the workload can call AWS APIs. PassRole is the permission to hand a role to a service. The trap is the resource scope. A policy that reads iam:PassRole on Resource: "*" doesn’t mean “pass your own narrow role” — it means pass any role in the account, including the admin role. Pair that with any service that runs code (lambda:CreateFunction + lambda:InvokeFunction, or ec2:RunInstances), and you have a complete ladder:

PassRole is the headline, but the family is large, and the senior skill is recognizing the pattern rather than memorizing a list. Any of these is a one-step escalation when granted on a wildcard:

The defense isn’t “ban these actions” — they’re load-bearing. It’s resource scoping plus a permissions boundary. Scope PassRole to the exact role ARN the workload needs; never a wildcard. Then wrap any identity that can mint or attach permissions in a permissions boundary — a ceiling that the principal cannot exceed no matter what policy it grants itself. The boundary is what turns AttachUserPolicy from “attach admin” into “attach anything, capped at the boundary.”

The confused deputy: when a trusted service acts on attacker input

The second shape is subtler because the attacker never touches your account directly. A confused deputy is a privileged component tricked into misusing its own authority on behalf of a less-privileged caller. The classic cloud case: you grant a third-party SaaS (a monitoring tool, a backup vendor) permission to assume a role in your account so it can read your data. The vendor assumes one role to serve all its customers.

Here’s the trap. The vendor’s role-assumption call needs only the target account id and role name — both of which a malicious other customer of that same vendor can guess. Customer B asks the vendor to “monitor account 1234 / role MyAuditRole.” The vendor, as designed, assumes that role. Now the vendor — the deputy — is reading your account on Customer B’s behalf. The vendor wasn’t compromised; it did exactly its job. It was confused about whose request it was serving.

The fix is a shared secret bound into the trust relationship: an ExternalId. When you set up the vendor, you agree on a per-tenant secret and put "sts:ExternalId": "your-unique-value" as a condition in the role’s trust policy. Now the vendor must present your ExternalId to assume your role — and Customer B, who can guess your account id and role name, cannot guess a secret they were never given. The same principle generalizes: a confused deputy is defeated by binding the authorization decision to the original requester’s identity, not just to the deputy’s. In your own services, the equivalent is passing and checking the end-user’s identity through to the resource, never letting a privileged backend act on a raw, attacker-influenced target.

How a senior reviews an IAM change: think in blast radius

The unifying mental model is blast radius: if this exact principal’s long-lived credential leaked to an attacker tomorrow, what is the transitive closure of everything they could reach? Not “what is this role for” — what can it become. A deploy key that can pass any role has a blast radius of the entire account, even though its job is to push one service.

That reframing changes how you read policies. You stop scanning for syntax errors and start tracing reachability: does any grant let this principal acquire another identity (escalation)? Does any trust policy let an outside party borrow this account’s authority without proving they are the intended party (confused deputy)? The controls map cleanly onto those two questions — least-privilege resource scoping and permissions boundaries cap what a principal can become; ExternalId and per-request identity propagation cap whose behalf a deputy may act on. Default-deny is the floor under both: every grant starts at “no” and is widened only to a named resource for a named reason.