Privilege Escalation Risk Calculator

Score privilege-escalation exposure from PassRole wildcards, policy-write holders and role-chaining depth.

Inputs

Identities in the account or tenantidentities

Identities holding a known escalation permissionidentities

Principals with PassRole on a wildcard resourceprincipals

Principals that can write IAM policyprincipals

Deepest role-assumption chainhops

MFA enforced on every privileged action

Escalation Risk Score

55/ 100

Severity

Medium

Identities on an Escalation Path

1.50%

Reachable Privilege Positions

Estimated Remediation Effort

15.0hours

Step by step

Values used
Identities in the account or tenant = 400 identities; Identities holding a known escalation permission = 6 identities; Principals with PassRole on a wildcard resource = 3 principals; Principals that can write IAM policy = 5 principals; Deepest role-assumption chain = 3 hops; MFA enforced on every privileged action = Yes
Privilege Escalation Risk
risk = 1.2 × exposure rate + 8 per wildcard PassRole holder + 6 per policy-write holder + 7 per extra chain hop, minus 15 when MFA gates privileged actions.
Reach of a single compromised identity
blast radius = escalation paths × 2^(chain depth − 1).
Escalation Risk Score
= 55 / 100
Severity
= Medium
Identities on an Escalation Path
= 1.50
Reachable Privilege Positions
= 24
Estimated Remediation Effort
= 15.0 hours

How it works

Escalation is rarely one permission; it is a permission plus something to point it at. iam:PassRole on a wildcard lets a principal hand any role to a service it can start, policy-write permissions let it rewrite its own boundary, and each extra AssumeRole hop multiplies what a single stolen credential can reach. An identity with no admin permissions and one escalation path is functionally an administrator, so counting escalation paths tells you the real number of privileged accounts rather than the one on the org chart.

Formulas

Privilege Escalation Risk

risk = 1.2 × exposure rate + 8 per wildcard PassRole holder + 6 per policy-write holder + 7 per extra chain hop, minus 15 when MFA gates privileged actions.

exposure rate: Identities holding an escalation permission ÷ all identities
chain hop: One sts:AssumeRole step from one role into the next

Reach of a single compromised identity

blast radius = escalation paths × 2^(chain depth − 1).

2^(chain depth − 1): Roughly how the reachable set branches at each assumption hop

Frequently Asked Questions

How is Privilege Escalation Risk calculated?

risk = 1.2 × exposure rate + 8 per wildcard PassRole holder + 6 per policy-write holder + 7 per extra chain hop, minus 15 when MFA gates privileged actions. Escalation is rarely one permission; it is a permission plus something to point it at. iam:PassRole on a wildcard lets a principal hand any role to a service it can start, policy-write permissions let it rewrite its own boundary, and each extra AssumeRole hop multiplies what a single stolen credential can reach.

Why does Privilege Escalation Risk matter?

An identity with no admin permissions and one escalation path is functionally an administrator, so counting escalation paths tells you the real number of privileged accounts rather than the one on the org chart.

What values do I need to enter?

This calculator takes 6 inputs: Identities in the account or tenant, Identities holding a known escalation permission, Principals with PassRole on a wildcard resource, Principals that can write IAM policy, Deepest role-assumption chain, MFA enforced on every privileged action. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Which permissions are the classic escalation vectors?

In AWS the recurring set is iam:PassRole combined with a compute service such as lambda:CreateFunction or ec2:RunInstances, iam:CreatePolicyVersion or AttachUserPolicy on yourself, iam:UpdateAssumeRolePolicy on a privileged role, and sts:AssumeRole into a role whose trust policy is too broad.

How do I shrink the blast radius?

Constrain PassRole to specific role ARNs, add iam:PassedToService conditions, put every human and workload principal under a permissions boundary, keep assumption chains one hop deep, and require MFA or session tags in the trust policy of any role that can write IAM.

You might also need

Least Privilege Calculator AWS IAM Policy Calculator Identity Risk Calculator