DEV Community: Rohaan

Your AWS account has more admins than the IAM console shows

Rohaan — Sat, 10 Oct 2026 20:18:18 +0000

Open IAM, filter by the AdministratorAccess policy, and you get a list. Three
users, maybe a role or two. That is the list that gets reviewed in access
reviews, pasted into compliance evidence, and shown to auditors.

It is almost always wrong, and not by a little.

Admin is not a policy you have. It is a state you can reach. Plenty of
principals that are nowhere near that filtered list can reach it in one API
call.

Permissions that grant permissions

Most policy review looks for wide permissions: s3:*, ec2:*, a Resource of
*. Those are worth finding. But there is a second category that gets almost no
attention, and it is the one that matters more: permissions that let you change
permissions.

Here are the ones I keep running into.

iam:CreatePolicyVersion. If you can create a new version of a policy and
set it as the default, you can rewrite any policy you are attached to. Your
tightly scoped policy becomes * on * in a single call. The policy document
that was reviewed last quarter is not the policy document in effect.

iam:AttachUserPolicy, iam:AttachRolePolicy, iam:AttachGroupPolicy.
The direct version. If you can attach a policy, you can attach
AdministratorAccess. To yourself.

iam:PutUserPolicy and iam:PutRolePolicy. The same thing with inline
policies, and these are worse because inline policies do not show up where
people look for attached managed policies.

iam:PassRole combined with a compute service. This one is the most common
and the least understood. PassRole on its own does nothing. Combined with
lambda:CreateFunction and lambda:InvokeFunction, or with
ec2:RunInstances, it means you can start something that runs as a role more
privileged than you, and then use it. The permission you needed was not admin.
It was the ability to hand a role to a service.

iam:UpdateAssumeRolePolicy. You cannot assume that role today. You can
edit its trust policy to say that you can, and then you can.

iam:CreateAccessKey on another user. Mint a key for someone more
privileged and use it. No exploit, no escalation, just an API call that is
working as designed.

iam:CreateLoginProfile and iam:UpdateLoginProfile. Set a console
password on a user who does not have one, or change one that does.

None of these say admin. Every one of them is a path to it.

Why linters miss this

Policy linters are built to answer "is this permission too broad". They flag
wildcards, they flag Resource: *, they score things against least privilege.

iam:CreatePolicyVersion on one specific policy ARN is not broad. It is narrow,
specific, and looks like exactly what a well-scoped policy should look like. It
will pass every check you run and it is a full escalation to whatever that
policy can be rewritten to grant.

The question a linter asks is about the shape of a permission. The question that
matters is about what the permission leads to. Those are different questions and
the second one is a graph problem.

Going and looking

Start by listing what actually exists rather than what you remember granting:

# every inline policy on every role, where the escalation paths usually hide
aws iam list-roles --query 'Roles[].RoleName' --output text \
  | tr '\t' '\n' \
  | while read -r r; do
      aws iam list-role-policies --role-name "$r" \
        --query "PolicyNames[] | [?length(@)>\`0\`]" --output text \
        | grep -q . && echo "$r"
    done

Then search your policy documents for the specific actions above. Not for
wildcards. For iam:PassRole, iam:CreatePolicyVersion, iam:AttachRolePolicy
and the rest, by name. Anything that holds one of them is effectively an admin
with extra steps, and should be reviewed as an admin.

Two things that make this harder than it sounds. Inline policies are invisible
in most tooling and most dashboards, so they are where this accumulates.
And iam:PassRole is so routine in CI setups that it is usually granted without
anyone asking which roles can be passed, which is the only part that matters.

The number that is actually useful

Stop counting principals with AdministratorAccess. Start counting principals
that can become an administrator, in any number of steps, using only calls they
are already allowed to make.

That number is bigger. On every account I have looked at, it has been bigger.
And unlike the first number, it is the one that describes your actual blast
radius.

If you want to see the trust half of the same picture, who can get into the
account from outside rather than what they can become once in, I maintain a
read-only CLI for it called frontdoor.
It is Apache 2.0, needs no account, and covers AWS, GCP and Azure.

If you review IAM differently, particularly if you have found a clean way to
handle PassRole scoping in CI, I would like to hear it.

In the cloud, lateral movement is an API call, not an exploit

Rohaan — Wed, 07 Oct 2026 23:35:02 +0000

Most of us learned attack paths on a network. Someone lands on a box, escalates
locally, then pivots sideways to the next box. Exploit, escalate, pivot, repeat.
It is a good model and it shaped a generation of tooling.

In a cloud account it is mostly the wrong model, and the tooling that inherited
it keeps looking in the wrong place.

The pivot in cloud is usually not an exploit. It is an API call that the
attacker is allowed to make.

A chain that uses exactly one vulnerability

Here is the shape of it, with the only memorable CVE at the very start:

An app has an SSRF bug. Not even a good one. It fetches a URL you give it.
You point it at the instance metadata service and read the credentials of the role attached to the instance.
Those credentials let you call sts:AssumeRole on a role in the production account, because somebody wired up cross account access a year ago and the trust policy was never narrowed.
That production role can read the bucket holding database backups.

Count the exploits. One, at step one, and it is a web bug rather than anything
exotic. Steps two, three and four are the platform working exactly as
configured. There is nothing to patch at steps two, three or four, which is why
a vulnerability scanner has nothing to say about them.

Now sort your findings by CVSS and see where that SSRF lands. It is a medium.
Above it are a dozen criticals on hosts nothing can reach.

The edge that matters is the trust policy

An IAM role has two halves and people pay attention to the wrong one.

The permission policy says what the role can do. This is the half everyone
reviews, the half that linters check, the half that shows up in least privilege
talks.

The trust policy says who is allowed to become the role. This is the half
that creates the edge in the graph. A permission policy with s3:* on a role
nobody can assume is a non event. A tightly scoped permission policy on a role
that anything in the account can assume is a path.

So when you go looking, read trust policies first:

aws iam list-roles \
  --query 'Roles[].{name:RoleName,trust:AssumeRolePolicyDocument}'

Things worth stopping on:

A principal that is a whole account. "AWS": "arn:aws:iam::111122223333:root"
does not mean the root user. It means every principal in that account that also
has permission to assume it. If 111122223333 is a sandbox where a lot of people
have sts:*, you have handed the sandbox a key to here.

A missing external ID on a third party role. If you gave a SaaS vendor a role
and the trust policy names their account without an sts:ExternalId condition,
then any other customer of that vendor can potentially ask the vendor's platform
to assume into your account. This is the confused deputy problem and it is still
everywhere.

Federated trust with loose conditions. OIDC and SAML trust is where this gets
genuinely hard to eyeball. A GitHub Actions OIDC trust with sub left as a
wildcard means any repository in your organisation, or in some misconfigurations
any repository anywhere, can mint credentials for that role.

Chains. Role A can assume role B, role B can assume role C. Each hop looks
reasonable in isolation. Nobody drew the whole thing.

This is a graph problem and it needs graph tools

You cannot find chains by reading policies one at a time. Three hops is already
beyond what anyone holds in their head, and real accounts have more.

What you want is every principal as a node, every trust relationship as an edge,
and then a walk from anything externally reachable to anything you would be sad
to lose. The complication is that the edges have preconditions: you only take the
IAM edge if you first got code execution on the thing holding the role, which is
why this is not a plain shortest path.

I ended up writing a tool for the trust half of it, because reading
AssumeRolePolicyDocument by hand across three providers got old. It is called
frontdoor, it is Apache 2.0, it maps
federated and cross account trust into AWS, GCP and Azure, and it is read only
and needs no account. One binary. Point it at your credentials and it prints who
can walk in from outside.

That covers the trust graph. Joining it to reachability and to your
vulnerability data is the harder half, and that is the product I work on rather
than the free tool, so take that part as disclosure rather than advice: build it
yourself if you have the time, because you will understand your own account
better than any tool will explain it to you.

The thing I would tell my earlier self

Stop asking "what is the highest severity finding". Start asking "what can an
attacker reach, and what can they do once they are there".

The second question has a much shorter answer, and it is the one you can actually
finish.

If you handle federated trust differently, particularly OIDC conditions across
multiple clouds, I would like to hear it. That is the part I am least confident
about.

Your cloud security tool is sorting by the wrong number

Rohaan — Mon, 05 Oct 2026 15:43:12 +0000

Every cloud security tool I have used opens on the same screen: a list of findings, sorted by severity, with the criticals at the top in red. It feels like a priority queue. It is not one.

Here is the problem with it, using two findings I had in front of me last month.

Finding A. A critical CVE, CVSS 9.8, remote code execution, on a container image. The image runs in a private subnet. No ingress, no public load balancer, no NAT gateway on the route table. The task role can read one S3 bucket of build artifacts. Nothing else in the account can reach it.

Finding B. A medium misconfiguration, CVSS 5.3. An EC2 instance with IMDSv1 still enabled. The instance sits behind an ALB that is open to the internet and runs an app with a path traversal bug nobody had got round to fixing. Its instance profile can assume a role in the production account, and that role can read the database credentials.

Sorted by severity, A is at the top and B is twelve screens down. Sorted by what an attacker can actually do, B is the only one that matters this week.

Severity is a property of the vulnerability, not of your environment

This is the whole issue in one line. CVSS scores a vulnerability in the
abstract. It has no idea whether the affected host is reachable, what the compromised identity can do next, or whether the blast radius is one build artifact or your customer database.

That is not a criticism of CVSS. It was never meant to be a work queue. The specification says so. We turned it into one because it was the only number every tool agreed on, and because sorting by it is easy to implement.

EPSS helps, because it estimates the probability a vulnerability gets exploited in the wild in the next thirty days. KEV helps more, because it is a list of things that definitely are being exploited right now. Both are still properties of the vulnerability. Neither one knows anything about your network.

What actually makes something urgent

Three things, and none of them are in the CVE record:

Reachability. Can anything an attacker controls get to this asset? That means route tables, security groups, NACLs, load balancers, peering, and whatever your service mesh is doing. In practice most critical findings in a well segmented account are not reachable from anywhere an attacker starts.

Identity. If this asset is compromised, what can the attacker do next? An instance profile that can call sts:AssumeRole into another account is worth more to an attacker than a dozen RCEs on isolated hosts. Over permissioned roles are the real lateral movement path in cloud, not kernel exploits.

Blast radius. What is on the other side of that movement? There is a
difference between reaching a staging bucket and reaching the production
database, and no severity score captures it.

Put those three together and findings stop being a list. They become a graph, and the question changes from "what is the highest score" to "which of these chain together into a route to something that matters".

Doing it yourself

You can get a surprising distance with the APIs you already have. Roughly:

Pull your inventory. ec2:DescribeInstances, ecs:ListTasks, rds:DescribeDBInstances, the equivalents on Azure and GCP.
Pull network configuration. Route tables, security groups, NACLs, load balancer listeners and target groups. Build the reachability edges from that rather than from tags, because tags lie.
Pull IAM. Roles, attached and inline policies, trust policies, instance profiles. The trust policy is the edge you care about, because it is what makes cross account movement possible.
Pull your vulnerability data from wherever it already lives, and join it onto the inventory by instance id or image digest.
Mark your crown jewels by hand. Nothing automatic gets this right, and it is a short list.
Walk the graph from every internet reachable node and see which crown jewels you can reach, and what you had to exploit on the way.

Step 6 is where it gets interesting and where it gets slow. The graph is not large by graph standards, but the path search is not a simple shortest path, because each edge has a precondition: you only traverse the IAM edge if you first got code execution on the node that holds the role.

I built this twice by hand before deciding it was a product. If you want to see what it looks like when it is finished, that is what we do at
Secorvia: a live graph across AWS, Azure, Google Cloud and DigitalOcean, with findings ranked by exploitability and blast radius instead of by CVSS. The scanning is read only, and the free tier does not expire. Build it yourself if you have the time, though. You will understand your own environment far better than any tool will explain it to you.

The thing I got wrong for a long time

I used to think the goal was to get the critical count to zero. It is not, and chasing it actively hurts, because you spend your week on unreachable criticals and the reachable mediums stay open.

A better target: zero findings that sit on a path from the internet to anything you would be sad to lose. That number is usually small enough to actually fix, which is the entire point.

If you do this differently, I would genuinely like to hear it, particularly how you handle reachability through service meshes. That is the part I am least happy with.