Andy's News RoundupOriginal article
Protect Against Russia-Ukraine Cyber Activity

IAM-Deescalate: An Open Source Tool to Help Users Reduce the Risk of Privilege Escalation


Category: Cloud

Tags: , , , ,

A conceptual image representing misconfigurations, such as the excessive permissions that IAM-Deescalate helps detect and remediate

This post is also available in: 日本語 (Japanese)

Executive Summary

In the recent Cloud Threat Report, Unit 42 researchers analyzed more than 680,000 identities across 18,000 cloud accounts from 200 different organizations and found that 99% of cloud users, roles and service accounts are overly permissive. Cloud users commonly grant more permissions to identities than they actually need. These excessive permissions unnecessarily open up a much larger attack surface and increase the risk of privilege escalation. If a security incident occurs, adversaries may exploit the excessive permissions to escalate to more privileged roles, such as Administrator.

In light of these concerns, we developed an open source tool to help mitigate the privilege escalation risks of overly permissive identities in AWS. Note that while the fine-grained control that AWS's identity and access management (IAM) service allows can be useful for increasing the security of cloud resources, if the permission policy is not correctly configured or excessive permissions are granted through it, this can instead open the door to increased risk. Our open source tool is designed to help users reduce risk and better utilize the security benefits of the IAM service.

Dubbed IAM-Deescalate, this tool first identifies the users and roles with privilege escalation risks using PMapper. For each risky principal, IAM-Deescalate calculates a minimal set of permissions granted to this principal that can be revoked to eliminate the risks. In particular, IAM-Deescalate inserts an inline policy to explicitly deny the risky permissions that could allow the principal to escalate to administrator privilege.

IAM-Deescalate can remediate all the privilege escalation risks that PMapper identifies. At the time of writing, it can successfully remediate 77% of the known privilege escalation techniques maintained in the IAM Vulnerable project. IAM-Deescalate is lightweight enough to run in any DevOps workflow to detect and prevent any high-risk identity from being deployed. In future releases, we plan to continue to improve the coverage of more privilege escalation techniques.

Table of Contents

How Does IAM-Deescalate Work?
Additional Resources

How Does IAM-Deescalate Work?

Because IAM-Deescalate needs to check and modify identity-based policies, it is intended to be used by authorized users with sufficient IAM permissions. This policy shows the necessary permissions.

Build a Graph of Users and Roles

PMapper models the principals (users and roles) in an AWS account as a directed graph. Each node represents a principal, and each edge represents a transition from one principal to another. If principal A can authenticate as principal B, there is an edge directed from principal A to principal B. One principal can authenticate as another only when certain conditions are met, as detailed in prior research such as AWS IAM Privilege Escalation, That Escalated Quickly and Understanding Privilege Escalation). Figure 1 shows an example graph with five nodes and four directed edges.

  • User A can assume role B, so there is an edge directed from user A to role B.
  • Role B can pass role D to an EC2 instance that role B controls, so role B can indirectly authenticate as role D via the EC2 instance.
  • Role B can update user C’s login profile, so role B can create a new password for user C and log in as user C.
  • Role B can create a new access key for user C, so role B can also authenticate as user C using the new access key.
  • User E is disconnected as it does not meet any conditions to authenticate as another principal, and no other principals can authenticate as user E either.
User A > (black line - AssumeRole) > role B. role B > (red line - CreateAccessKey) > User C. role B > (red line - UpdateLoginProfile) > User C. role B > (red line - PassRole to EC2) > role D. User E is shown on the left, not connected to any of the other users or roles.
Figure 1. An example graph representing the relationships between users and roles in an AWS account.

Once this graph is fully created, we can search for possible paths between any two principals. There can be zero or multiple paths between any two principals. IAM-Deescalate considers a principal risky for privilege escalation if it is NOT an administrator but has a path to an administrator principal.

Identify and Break the Privilege Escalation Edges

To search for risky principals, IAM-Deescalate divides the graph into two partitions: the non-administrator partition and the administrator partition. Any edges directed from the non-administrator partition to the administrator partition are referred to as privilege escalation edges. In Figure 1, red nodes are in the administrator partition, black nodes are in the non-administrator partition and red edges are the privilege escalation edges. In this example, Role B is the only risky principal and it has three possible privilege escalation edges.

IAM-Deescalate attempts to break all the privilege escalation edges. As aforementioned, an edge is created between two principals only when certain conditions are met. If any of these conditions can no longer hold, the edge is removed. To break a privilege escalation edge, IAM-Deescalate revokes one or multiple necessary conditions that allow the non-administrator principal to transition to the administrator principal. Using the example in Figure 1, IAM-Deescalate breaks the red edges by inserting a policy to role B to explicitly DENY these permissions:

  • perform iam:CreateAccessKey on user C.
  • perform iam:UpdateLoginProfile on user C.
  • perform iam:passrole on role D.

To minimize the potential impact on existing workloads, IAM-Deescalate only revokes the smallest number of permissions sufficient to break an edge. Users can review the proposed remediation plan and manually choose which permissions to revoke or keep. A “revert” option is also available to undo any remediation policies that IAM-Deescalate applied.


We used the IAM-Vulnerable project as a benchmark to evaluate IAM-Deescalate. At the time of writing, IAM-Vulnerable maintains 31 known privilege escalation techniques and can create 31 different users and roles, each with a unique privilege escalation risk. We then used three open-source projects – PMapper (v1.1.5), Cloudsplaining (v0.5.0) and Pacu (v1.0.3) – to check for privilege escalation risks before and after IAM-Deescalate applied the remediation policies to these 31 principals.

Table 1 details the evaluation result. The columns under “Before remediation” show the efficacy of the three privilege escalation scanners. PMapper achieves the highest detection rate (77%), followed by Pacu’s 68% and Cloudsplaining’s 61%. These results are consistent with the findings in the IAM-Vulnerable assessment blog.

The columns under “After remediation” show the efficacy of the three privilege escalation scanners after IAM-Deescalate has applied the remediation policies. All 24 risky principals PMapper identified were successfully remediated. As for Cloudsplaining and Pacu, they both still identified five principals with privilege risks after the remediation process. These are the risky principals that PMapper failed to identify and that IAM-Deescalate did not remediate. Overall, IAM-Deescalate successfully remediates 24 out of 31 (77%) privilege escalation techniques IAM-Vulnerable maintains.

One interesting finding is that Cloudsplaining continues to report privilege escalation risks in every principal even after the remediation. The reason is that Cloudsplaining evaluates each permission policy independently and does not calculate the effective permissions when multiple permission policies are attached to a principal. For example, a user may have three attached policies – two AWS-managed policies and one customer-managed policy. The effective permissions are the resulting permissions considering the conditions and permissions of all three policies. Without the effective permissions, Cloudsplaining cannot see that the inline policy IAM-Deescalate inserted already eliminates the privilege escalation risks in the customer-managed policy.


Privilege Escalation Techniques Before remediation After remediation
PMapper Cloudsplaining Pacu PMapper Cloudsplaining Pacu
IAM-CreateAccessKey TP TP TP TN FP TN
IAM-CreateLoginProfile TP TP TP TN FP TN
IAM-UpdateLoginProfile TP TP TP TN FP TN
CloudFormation-PassExistingRoleToCloudFormation TP TP TP TN FP TN
CodeBuild-CreateProjectPassRole TP FN FN TN TN* TN*
DataPipeline-PassExistingRoleToNewDataPipeline FN TP TP FN TP TP
EC2-CreateEC2WithExistingInstanceProfile TP TP TP TN FP TN
Glue-PassExistingRoleToNewGlueDevEndpoint FN TP TP FN TP TP
Lambda-PassExistingRoleToNewLambdaThenInvoke TP TP TP TN FP TN
Lambda-PassRoleToNewLambdaThenTrigger TP TP TP TN FP TN
SageMaker-CreateNotebookPassRole TP FN FN TN TN* TN*
SageMaker-CreateTrainingJobPassRole TP FN FN TN TN* TN*
SageMaker-CreateProcessingJobPassRole TP FN FN TN TN* TN*
IAM-AttachGroupPolicy TP TP TP TN FP TN
IAM-AttachRolePolicy TP FN TP TN TN* TN
IAM-AttachUserPolicy TP TP TP TN FP TN
IAM-CreateNewPolicyVersion TP TP TP TN FP TN
IAM-PutGroupPolicy TP TP TP TN FP TN
IAM-PutRolePolicy TP FN TP TN TN* TN
IAM-SetExistingDefaultPolicyVersion FN TP TP FN TP TP
EC2InstanceConnect-SendSSHPublicKey FN FN FN FN FN FN
CloudFormation-UpdateStack TP FN FN TN TN* TN*
Glue-UpdateExistingGlueDevEndpoint FN TP TP FN TP TP
Lambda-EditExistingLambdaFunctionWithRole TP TP TP TN FP TN
SageMaker-CreatePresignedNotebookURL FN FN FN FN FN FN
SSM-SendCommand TP FN FN TN TN* TN*
SSM-StartSession TP FN FN TN TN* TN*
STS-privesc-AssumeRole TP FN FN TN TN* TN*
IAM-UpdatingAssumeRolePolicy TP TP TP TN FP TN
Total TP 24 19 21 0 5 5
Total FP 0 14 0

Table 1. Testing the effectiveness of IAM-Deescalate using various open source tools.

  • True positive (TP): The tool reports positive on the vulnerable principal.
  • False negative (FN): The tool reports negative on the vulnerable principal.
  • True negative (TN): The tool reports negative on the remediated principal.
    • (TN*): The tool reports negative on a remediated principal because the tool can’t recognize the privilege escalation technique. The tool always reports negative whether the vulnerability exists or not.
  • False positive (FP): The tool reports positive on a remediated principal.


The concept of the principle of least privilege is nothing new, but the prevalence of problems related to overly permissive cloud users, roles and service accounts revealed in our Cloud Threat Report showed the large gap between reality and expectation. The situation could worsen if adversaries can exploit excessive permissions to escalate to administrator privilege. We developed and open sourced IAM-Deescalate to mitigate privilege escalation risks in AWS. IAM-Deescalate identifies risky principals and calculates the minimal set of permissions that can be revoked to break the attack paths. As new privilege escalation techniques will continue to be discovered, we welcome the open-source community to join us to continue improving the tool.

Additional Resources

IAM Access Analyzer: An AWS service that helps validate IAM policies and generate least-privilege policies based on the cloud trail logs.
AirIAM: An open source tool that scans IAM activities and creates a terraform template that can provision least-privilege permission policies.
Cloud Infrastructure Entitlement Management (CIEM): A service that provides a multi-cloud solution to monitor IAM permissions and continuously enforce least-privileged access.