Role privilege escalation remediation

Using Console

Below is a practical, console-focused process to find and fix IAM role permissions that allow privilege escalation in AWS.

1. Understand What You’re Looking For

Privilege escalation usually happens when a principal (user/role) can:

Attach/Update IAM policies to themselves or to roles they can assume:
- iam:AttachUserPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutRolePolicy, iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, etc.
Assume or pass roles with more privileges:
- sts:AssumeRole
- iam:PassRole (combined with other actions)
Create or modify access keys / login profiles:
- iam:CreateAccessKey, iam:UpdateAccessKey, iam:CreateLoginProfile, iam:UpdateLoginProfile
Create/Update Lambda, EC2, or other services with privileged roles:
- lambda:UpdateFunctionCode, lambda:CreateFunction, ec2:RunInstances with a powerful instance profile, etc.

Your goal: Remove or tightly restrict these permissions to least privilege.

2. Inventory IAM Roles and Attached Policies

Sign in to the AWS Management Console with an admin account.
Go to IAM:
- Top right search bar → type “IAM” → IAM.
In the left navigation, check:
- Roles
- Users
- Policies

You’ll review permissions on:

Managed policies (AWS-managed & Customer-managed).
Inline policies on users/roles/groups.

3. Identify High-Risk Policies Using IAM Access Analyzer

In IAM console, left menu → Access Analyzer → Policy analyzer.
Use Policy analyzer to search for policies containing sensitive actions:
- In Actions filter, enter:
  - iam:*, sts:*, lambda:*, ec2:RunInstances, etc.
For each policy result, open it in a new tab and inspect:
- Look for statements with Effect: Allow and:
  - Action: "iam:*" or broad wildcards like "*" on Action.
  - Resource: "*".
Prioritize:
- Policies with Action = "*" and Resource = "*".
- Policies that allow specific escalation actions (list in section 1).

4. Analyze a Specific Role for Escalation Path

To deep dive into one role:

IAM console → Roles.
Click a role name to inspect it.
Tabs to check:
- Permissions:
  - Look at each Attached policy and any Inline policies.
  - Click policy name → JSON tab.
- Trust relationships:
  - Check which principals can assume this role (sts:AssumeRole).

For each attached/inline policy, look for:

Problematic Actions: Common privilege-escalation enablers:
- iam:AttachUserPolicy
- iam:AttachGroupPolicy
- iam:AttachRolePolicy
- iam:PutUserPolicy
- iam:PutGroupPolicy
- iam:PutRolePolicy
- iam:CreatePolicyVersion
- iam:SetDefaultPolicyVersion
- iam:PassRole
- sts:AssumeRole
- iam:CreateAccessKey
- iam:UpdateAccessKey
- iam:CreateLoginProfile
- iam:UpdateLoginProfile
Broad Resources:
- Resource: "*" on the above actions.
- Or resources that cover admin roles/policies.

If a role a user has can assume another highly privileged role (via sts:AssumeRole), that is a privilege escalation path.

5. Remediate Policies (Least-Privilege Hardening)

5.1 Remove or Restrict Dangerous IAM Actions

For each risky policy:

IAM → Policies → search for the policy name.
Open policy → Permissions tab → Edit.
In JSON or Visual editor, do the following: a) Remove unneeded IAM-write actions completely
For example, remove:
- iam:Attach*
- iam:Put*
- iam:CreatePolicyVersion
- iam:SetDefaultPolicyVersion
- iam:CreateAccessKey
- iam:UpdateAccessKey
- iam:CreateLoginProfile
- iam:UpdateLoginProfile
b) Where iam:PassRole is required:
- Restrict Resource to specific safe roles, not "*".
- Add conditions like:
  "Condition": { "StringEquals": { "iam:PassedToService": [ "ecs.amazonaws.com", "lambda.amazonaws.com" ] } }
c) Where sts:AssumeRole is required:
- Restrict to only the specific role ARNs needed.
- Do not allow "*" for resources.
Click Next, review, then Save changes.

If an AWS-managed policy is risky (you can’t edit it):

Detach it from users/roles and replace with a custom, scoped-down customer-managed policy:
1. Policies → Create policy.
2. Define least-privilege permissions.
3. Create policy, then Attach it to the target role/user.
4. Detach the AWS-managed policy from the entity.

5.2 Tighten Trust Policies (Who Can Assume the Role)

IAM → Roles → choose role → Trust relationships tab.
Click Edit trust policy.
Check for:
- "Principal": "*" or overly broad accounts.
- Conditions missing on sts:AssumeRole.
Adjust to only allow required principals and, ideally, require conditions. Example (only one account and specific role):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/AppRole" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Avoid letting low-privilege roles, wildcards, or external accounts assume highly privileged roles.

6. Use the IAM Policy Simulator to Validate

Go to IAM → Policy Simulator.
Choose User or Role you want to test.
Select services like IAM, STS, Lambda, EC2.
Test specific actions:
- iam:PassRole, iam:AttachRolePolicy, sts:AssumeRole, iam:CreateAccessKey, etc.
Confirm:
- Only the minimal, intended actions are allowed.
- Escalation-enabling combinations are not possible.

7. Add Guardrails: SCPs and Permissions Boundaries (If Using Organizations)

If you use AWS Organizations:

Service Control Policies (SCPs):

AWS Organizations console → Policies → Service control policies.
Create SCPs that deny dangerous actions for all non-admin accounts, e.g.:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:SetDefaultPolicyVersion",
        "iam:AttachRolePolicy",
        "iam:PassRole"
      ],
      "Resource": "*"
    }
  ]
}

Attach SCP to appropriate OUs/accounts.
Exclude a tightly-controlled admin account if necessary.

Permissions boundaries (optional, more advanced):
- Create a boundary policy that excludes privilege-escalation actions.
- Attach as permission boundary to roles developers can create.

8. Continuous Monitoring

IAM console → Access Analyzer → Analyzer:
- Enable analyzers to detect broad or external access.
IAM → Credential report:
- Periodically review user access keys, console access.
Enable CloudTrail and (optionally) CloudTrail Lake / GuardDuty:
- Monitor for suspicious IAM activity (e.g., new CreatePolicyVersion, SetDefaultPolicyVersion, AttachRolePolicy).

If you share a specific risky role/policy JSON, I can give exact edits line-by-line for remediation.

Using CLI

Below is a practical, CLI‑focused process to identify and fix IAM role permissions that allow privilege escalation in AWS.

1. Know the risky IAM permissions

These actions are commonly used for privilege escalation when overly broad:

iam:PassRole
iam:PutRolePolicy
iam:AttachRolePolicy
iam:PutUserPolicy
iam:CreatePolicyVersion
iam:SetDefaultPolicyVersion
iam:UpdateAssumeRolePolicy
iam:AddUserToGroup, iam:AttachGroupPolicy
sts:AssumeRole
sts:AssumeRoleWithWebIdentity

Your goal: find any role that can call these actions in a dangerous way (e.g., unscoped to specific resources, or to Admin policies/roles).

2. Enumerate IAM roles and their policies

# List all roles
aws iam list-roles --query 'Roles[*].RoleName' --output text

For each role (or for ones you suspect):

ROLE_NAME=YourRoleName

# Inline policies on the role
aws iam list-role-policies --role-name "$ROLE_NAME"

# Get contents of each inline policy
aws iam get-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-name YourInlinePolicyName

# Attached managed policies
aws iam list-attached-role-policies --role-name "$ROLE_NAME"

# For each attached policy, get its default policy document
POLICY_ARN=arn:aws:iam::aws:policy/YourPolicy
DEFAULT_VERSION=$(aws iam get-policy \
  --policy-arn "$POLICY_ARN" \
  --query 'Policy.DefaultVersionId' \
  --output text)

aws iam get-policy-version \
  --policy-arn "$POLICY_ARN" \
  --version-id "$DEFAULT_VERSION"

Look in the policy JSON for Action containing the risky IAM actions above.

3. Identify privilege‑escalation patterns

Flags to look for in the policy JSON:

Wildcard actions:
- "Action": "iam:*" or "*" on IAM / STS
Unrestricted PassRole:
- "Action": "iam:PassRole" with "Resource": "*"
Policy modification on high‑privilege policies:
- iam:AttachRolePolicy, iam:PutRolePolicy, iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion with "Resource": "*"
Trust policies that are too broad:
- sts:AssumeRole allowed from Principal: "*", or from untrusted accounts/services.

To view a role’s trust policy:

aws iam get-role --role-name "$ROLE_NAME" \
  --query 'Role.AssumeRolePolicyDocument' \
  --output json

4. Remove or scope dangerous permissions (inline policies)

4.1. Download and edit the inline policy locally

ROLE_NAME=YourRoleName
POLICY_NAME=YourInlinePolicyName

aws iam get-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-name "$POLICY_NAME" \
  --query 'PolicyDocument' \
  --output json > policy.json

Edit policy.json:

Remove unneeded risky actions (e.g., iam:*, iam:PassRole, etc.).
Or narrow them:
- Restrict Resource to only specific ARNs (e.g., just one role that truly needs to be passed).
- Add Condition (e.g., limit iam:PassRole to certain services).

Example: scope iam:PassRole to a single role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPassSpecificRoleToEC2",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/EC2LimitedRole",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "ec2.amazonaws.com"
        }
      }
    }
  ]
}

Re‑apply the edited inline policy:

aws iam put-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-name "$POLICY_NAME" \
  --policy-document file://policy.json

5. Replace or detach risky managed policies

If a role has broad AWS‑managed or customer‑managed policies (e.g., AdministratorAccess, custom *:* policies):

ROLE_NAME=YourRoleName
POLICY_ARN=arn:aws:iam::aws:policy/AdministratorAccess

# Detach the overly permissive policy
aws iam detach-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-arn "$POLICY_ARN"

Create a least‑privilege customer‑managed policy:

cat > least-priv-role-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AppNeedsOnlyTheseActions",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}
EOF

aws iam create-policy \
  --policy-name MyLeastPrivPolicy \
  --policy-document file://least-priv-role-policy.json

NEW_POLICY_ARN=$(aws iam list-policies \
  --scope Local \
  --query "Policies[?PolicyName=='MyLeastPrivPolicy'].Arn" \
  --output text)

aws iam attach-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-arn "$NEW_POLICY_ARN"

6. Lock down trust policies (AssumeRole)

For any role that can lead to higher privilege (e.g., admin roles):

Restrict who can assume it.
Avoid Principal: "*".
Limit to specific AWS accounts, roles, or services.

Get and edit trust policy:

ROLE_NAME=PrivilegedRole

aws iam get-role --role-name "$ROLE_NAME" \
  --query 'Role.AssumeRolePolicyDocument' \
  --output json > trust.json

Example safer trust policy (from a specific account/role only):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/ApprovedCallerRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Apply:

aws iam update-assume-role-policy \
  --role-name "$ROLE_NAME" \
  --policy-document file://trust.json

7. Fix dangerous policy versioning rights

If a role can call iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion on sensitive policies, an attacker can swap in an admin version.For customer‑managed policies:

List who can modify them.
Remove those actions, or scope them with conditions (e.g., only to non‑privileged policies, or only a CI/CD role).

To reduce rights, edit the responsible role’s policy as in step 4 and remove:

iam:CreatePolicyVersion
iam:SetDefaultPolicyVersion
iam:DeletePolicyVersion

Then re‑apply with put-role-policy.

8. Validate with the Policy Simulator

Before and after changes, you can check what a role can do:

ROLE_ARN=arn:aws:iam::123456789012:role/YourRole

aws iam simulate-principal-policy \
  --policy-source-arn "$ROLE_ARN" \
  --action-names iam:PassRole iam:CreatePolicyVersion iam:AttachRolePolicy sts:AssumeRole \
  --output json

Verify that high‑risk actions are explicitDeny or not allowed.

9. Optional: enforce org‑wide via SCPs (if using AWS Organizations)

At the org/root or OU level, create SCPs that deny dangerous privilege‑escalation patterns except for tightly controlled admin roles:Example SCP snippet:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPassRoleToAnyRoleExceptAdminControllers",
      "Effect": "Deny",
      "Action": "iam:PassRole",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/OrgAdminRole"
          ]
        }
      }
    }
  ]
}

Apply with:

aws organizations create-policy \
  --content file://scp.json \
  --name RestrictPassRole \
  --type SERVICE_CONTROL_POLICY
# then attach to OU or root

If you want, you can paste one specific role’s current policy JSON, and I can show you exactly how to rewrite it to remove the privilege‑escalation paths and give you the exact aws cli commands to apply the fix.

Using Python

Below is a practical, step‑by‑step remediation approach for AWS IAM privilege‑escalation risks, with Python (boto3) examples.

1. Understand the Common IAM Privilege Escalation Paths

Typical dangerous permissions (especially if a user/principal can call them on themselves or roles they assume):

iam:CreatePolicyVersion (with SetAsDefault=true)
iam:PutRolePolicy, iam:PutUserPolicy, iam:AttachRolePolicy, iam:AttachUserPolicy, iam:AttachGroupPolicy
iam:PassRole (especially combined with EC2, Lambda, Step Functions, etc.)
sts:AssumeRole
Permissions on Lambda, EC2, Glue, Step Functions, etc., that allow attaching or modifying roles/policies:
- lambda:UpdateFunctionConfiguration (to change execution role)
- ec2:RunInstances with instance profile you can control
- glue:CreateDevEndpoint with role you can pass
Wildcards like "Action": "*", "Resource": "*" (especially in combination).

Remediation = remove or restrict these where they are not explicitly needed, and add guardrails (permission boundaries, SCPs, condition keys).

2. Enumerate IAM Roles and Policies (Python/boto3)

import boto3
import json

iam = boto3.client('iam')

def list_all_roles():
    roles = []
    paginator = iam.get_paginator('list_roles')
    for page in paginator.paginate():
        roles.extend(page['Roles'])
    return roles

def list_attached_policies_for_role(role_name):
    attached = []
    paginator = iam.get_paginator('list_attached_role_policies')
    for page in paginator.paginate(RoleName=role_name):
        attached.extend(page['AttachedPolicies'])
    return attached

def list_inline_policies_for_role(role_name):
    policies = []
    paginator = iam.get_paginator('list_role_policies')
    for page in paginator.paginate(RoleName=role_name):
        policies.extend(page['PolicyNames'])
    return policies

3. Identify High‑Risk Permissions in Policies

Define a set of “risky” actions and scan all attached + inline policies.

RISKY_ACTIONS = {
    "iam:CreatePolicyVersion",
    "iam:PutRolePolicy",
    "iam:PutUserPolicy",
    "iam:AttachRolePolicy",
    "iam:AttachUserPolicy",
    "iam:AttachGroupPolicy",
    "iam:PassRole",
    "iam:PutRolePermissionsBoundary",
    "iam:PutUserPermissionsBoundary",
    "sts:AssumeRole",
    "*",  # catch-all, will treat carefully
}

def get_policy_document_arn(policy_arn, version_id=None):
    if not version_id:
        policy = iam.get_policy(PolicyArn=policy_arn)
        version_id = policy['Policy']['DefaultVersionId']
    version = iam.get_policy_version(PolicyArn=policy_arn, VersionId=version_id)
    return version['PolicyVersion']['Document']

def get_inline_policy_document(role_name, policy_name):
    resp = iam.get_role_policy(RoleName=role_name, PolicyName=policy_name)
    return resp['PolicyDocument']

def statement_contains_risky_actions(statement):
    actions = statement.get("Action", [])
    if isinstance(actions, str):
        actions = [actions]
    actions = [a.lower() for a in actions]
    risky = []
    for a in actions:
        if a == "*" or a in {x.lower() for x in RISKY_ACTIONS}:
            risky.append(a)
    return risky

def find_risky_perms_in_policy(document):
    risky_statements = []
    statements = document.get("Statement", [])
    if isinstance(statements, dict):
        statements = [statements]
    for stmt in statements:
        risky = statement_contains_risky_actions(stmt)
        if risky:
            risky_statements.append((stmt, risky))
    return risky_statements

Usage: loop through roles and attached policies:

def audit_roles_for_priv_esc():
    roles = list_all_roles()
    findings = []

    for role in roles:
        role_name = role['RoleName']

        # Managed policies
        attached = list_attached_policies_for_role(role_name)
        for ap in attached:
            doc = get_policy_document_arn(ap['PolicyArn'])
            risky_stmts = find_risky_perms_in_policy(doc)
            if risky_stmts:
                findings.append({
                    "PrincipalType": "Role",
                    "PrincipalName": role_name,
                    "PolicyType": "Managed",
                    "PolicyArn": ap['PolicyArn'],
                    "RiskyStatements": risky_stmts,
                })

        # Inline policies
        inline_names = list_inline_policies_for_role(role_name)
        for pname in inline_names:
            doc = get_inline_policy_document(role_name, pname)
            risky_stmts = find_risky_perms_in_policy(doc)
            if risky_stmts:
                findings.append({
                    "PrincipalType": "Role",
                    "PrincipalName": role_name,
                    "PolicyType": "Inline",
                    "PolicyName": pname,
                    "RiskyStatements": risky_stmts,
                })

    return findings

if __name__ == "__main__":
    findings = audit_roles_for_priv_esc()
    print(json.dumps(findings, default=str, indent=2))

This identifies where privilege‑escalation‑prone actions exist.

4. Decide on Remediation Strategy (Per Finding)

Per role/policy combination, you should:

Confirm business need for each risky action.
If not needed:
- Remove or narrow the statement.
If needed:
- Restrict resources.
- Add IAM conditions.
- Use permission boundaries and/or SCPs.
- Separate “break‑glass” roles from normal operators.

Below are concrete policy changes and how to apply them via Python.

5. Remediate Excessive `iam:PassRole`

5.1 Policy Before (too broad)

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

5.2 Policy After (restricted roles + conditions)

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": [
    "arn:aws:iam::123456789012:role/SpecificServiceRole"
  ],
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

5.3 Update Policy Version via Python

For managed policies:

def create_restricted_policy_version(policy_arn, new_document):
    resp = iam.create_policy_version(
        PolicyArn=policy_arn,
        PolicyDocument=json.dumps(new_document),
        SetAsDefault=True
    )
    return resp['PolicyVersion']['VersionId']

Typical flow:

Get existing document.
Manually or programmatically modify statements (e.g., change Resource: "*" to specific ARNs; add Condition).
Call create_policy_version with SetAsDefault=True.
Optionally delete old versions later (max 5).

6. Remove or Restrict Delegated Policy Management (`iam:Policy`)

If a role has permissions like iam:CreatePolicyVersion, iam:PutRolePolicy, etc., and it’s not a dedicated IAM admin role:

Create a new, least‑privilege IAM admin role for identity team only.
Remove those actions from operational roles.

Sample adjustment:Before:

{
  "Effect": "Allow",
  "Action": [
    "iam:CreatePolicyVersion",
    "iam:PutRolePolicy",
    "iam:AttachRolePolicy"
  ],
  "Resource": "*"
}

After (if minimal is needed):If the role only needs to attach a pre‑approved policy to a specific role:

{
  "Effect": "Allow",
  "Action": [
    "iam:AttachRolePolicy"
  ],
  "Resource": "arn:aws:iam::123456789012:role/SpecificRole",
  "Condition": {
    "StringEquals": {
      "iam:PolicyARN": "arn:aws:iam::123456789012:policy/PreApprovedPolicy"
    }
  }
}

Apply via same create_policy_version mechanism.For inline policies, update with put_role_policy:

def update_inline_policy(role_name, policy_name, new_document):
    iam.put_role_policy(
        RoleName=role_name,
        PolicyName=policy_name,
        PolicyDocument=json.dumps(new_document)
    )

7. Constrain `sts:AssumeRole` and Trust Policies

Even if role A doesn’t have broad iam:*, it can escalate by assuming a more‑privileged role B.

7.1 Inspect trust policies

def get_role_trust_policy(role_name):
    role = iam.get_role(RoleName=role_name)
    return role['Role']['AssumeRolePolicyDocument']

def update_role_trust_policy(role_name, new_trust_doc):
    iam.update_assume_role_policy(
        RoleName=role_name,
        PolicyDocument=json.dumps(new_trust_doc)
    )

7.2 Restrict trust policies

Use specific principals, not *.
Add conditions like aws:PrincipalTag, aws:SourceAccount, aws:SourceArn.

Before (too open):

{
  "Effect": "Allow",
  "Principal": { "AWS": "*" },
  "Action": "sts:AssumeRole"
}

After (restricted):

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:role/SpecificCallerRole" },
  "Action": "sts:AssumeRole"
}

Or with conditions:

{
  "Effect": "Allow",
  "Principal": { "AWS": "*" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "aws:PrincipalTag/RoleType": "Automation" }
  }
}

8. Guardrails: Permission Boundaries and SCPs (Org‑Level)

8.1 Permission Boundaries (per principal)

Create a boundary policy that forbids escalation actions (or limits them tightly), then attach it as a permission boundary to roles/users that you do not want to be able to escalate.Example permission boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:PutUserPolicy",
        "iam:PutRolePolicy",
        "iam:AttachUserPolicy",
        "iam:AttachRolePolicy",
        "iam:PassRole"
      ],
      "Resource": "*"
    }
  ]
}

Attach via Python:

def attach_permission_boundary_to_role(role_name, boundary_arn):
    iam.update_role(
        RoleName=role_name,
        PermissionsBoundary=boundary_arn
    )

8.2 Service Control Policies (SCPs) (Org‑wide)

In AWS Organizations, SCPs can deny dangerous actions account‑wide except for a specific IAM admin role.Example (pseudo; must be applied via Organizations API/console):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:PutRolePolicy",
        "iam:AttachRolePolicy",
        "iam:PassRole"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/CentralIAMAdmin"
        }
      }
    }
  ]
}

9. Special Case: Service‑Based Escalation (Lambda, EC2, etc.)

Even if iam:PassRole is restricted, some combos can still escalate; for each:

Lambda: lambda:UpdateFunctionConfiguration to change Role.
EC2: ec2:RunInstances with a modifiable instance profile.
Step Functions: states:CreateStateMachine with high‑priv role.

Remediation pattern:

Constrain Resource to specific functions, instances, state machines.
Combine with tight iam:PassRole (only low‑priv roles).
Use conditions like iam:PassedToService, ec2:InstanceProfile, or tags.

Example for Lambda:

{
  "Effect": "Allow",
  "Action": [
    "lambda:UpdateFunctionConfiguration"
  ],
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyApp-*",
  "Condition": {
    "StringEquals": {
      "lambda:Role": "arn:aws:iam::123456789012:role/MyAppExecutionRole"
    }
  }
}

10. Verification / Regression Checks

After changes:

Use IAM Access Analyzer (console or API) to detect potential privilege escalation.
Re‑run your Python audit script to ensure:
- No unexpected iam:*Policy* / iam:PassRole / sts:AssumeRole wildcards.
- No Action: "*" + Resource: "*" for non‑admin roles.
Test critical workflows to confirm business operations continue to function.

If you want, I can:

Help you adapt the audit script to automatically suggest a “patched” policy document, or
Focus on a specific privileged role’s policies and walk through concrete JSON diffs.

Using Terraform

# IAM policy with privilege‑escalation actions removed or tightly scoped
resource "aws_iam_policy" "restricted_role_management" {
  name        = "restricted-role-management"
  description = "Allows only tightly scoped role management actions without privilege escalation"

  # Replace with the ARN of the specific role this workload is allowed to pass
  # e.g. arn:aws:iam::123456789012:role/my-allowed-target-role
  # Substitute YOUR_ACCOUNT_ID and YOUR_ROLE_NAME as needed.
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      # Example: allow passing only a specific role, and only to a specific service
      {
        Sid    = "AllowPassSpecificRoleToSpecificService"
        Effect = "Allow"
        Action = [
          "iam:PassRole"
        ]
        Resource = "arn:aws:iam::YOUR_ACCOUNT_ID:role/YOUR_ALLOWED_TARGET_ROLE"
        Condition = {
          StringEquals = {
            "iam:PassedToService" = "ecs-tasks.amazonaws.com" # SUBSTITUTE TARGET SERVICE
          }
        }
      },

      # Example: allow listing/reading IAM metadata, which is not escalating
      {
        Sid    = "AllowIamReadOnly"
        Effect = "Allow"
        Action = [
          "iam:GetRole",
          "iam:ListRolePolicies",
          "iam:ListAttachedRolePolicies",
          "iam:ListRoles"
        ]
        Resource = "*"
      }

      # NOTE:
      #  - DO NOT include broad write actions like:
      #    iam:AttachRolePolicy
      #    iam:PutRolePolicy
      #    iam:CreatePolicy
      #    iam:CreatePolicyVersion
      #    iam:SetDefaultPolicyVersion
      #    iam:UpdateAssumeRolePolicy
      #    iam:AddUserToGroup
      #    iam:UpdateLoginProfile
      #    sts:AssumeRole on higher-privilege roles
      #  - If such actions are currently in the JSON, remove them or scope them
      #    to the exact roles/policies this workload must manage, with explicit ARNs.
    ]
  })
}

# Attach the remediated policy to the role that previously had an escalating policy
resource "aws_iam_role_policy_attachment" "role_restricted_attachment" {
  role       = aws_iam_role.TARGET_ROLE.name             # SUBSTITUTE EXISTING ROLE
  policy_arn = aws_iam_policy.restricted_role_management.arn
}

# Example role showing how it would be referenced (if not already defined)
resource "aws_iam_role" "TARGET_ROLE" {
  name = "YOUR_EXISTING_ROLE_NAME" # SUBSTITUTE; align with actual role name

  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
}

data "aws_iam_policy_document" "assume_role_policy" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ecs-tasks.amazonaws.com"] # SUBSTITUTE CALLER SERVICE
    }
  }
}

Changing an existing aws_iam_policy in Terraform (rather than editing inline JSON only) forces replacement of the policy resource; any existing attachments will be recreated by Terraform, which may briefly remove and reattach the policy during apply.For verification, terraform plan should show: removal of the old IAM policy resource (with privilege‑escalation actions), creation of the new restricted aws_iam_policy, and updates to aws_iam_role_policy_attachment resources so that the role is attached only to the remediated policy.

​Triage and Remediation

​Remediation

​1. Understand What You’re Looking For

​2. Inventory IAM Roles and Attached Policies

​3. Identify High-Risk Policies Using IAM Access Analyzer

​4. Analyze a Specific Role for Escalation Path

​5. Remediate Policies (Least-Privilege Hardening)

​5.1 Remove or Restrict Dangerous IAM Actions

​5.2 Tighten Trust Policies (Who Can Assume the Role)

​6. Use the IAM Policy Simulator to Validate

​7. Add Guardrails: SCPs and Permissions Boundaries (If Using Organizations)

​8. Continuous Monitoring

​1. Know the risky IAM permissions

​2. Enumerate IAM roles and their policies

​3. Identify privilege‑escalation patterns

​4. Remove or scope dangerous permissions (inline policies)

​4.1. Download and edit the inline policy locally

​5. Replace or detach risky managed policies

​6. Lock down trust policies (AssumeRole)

​7. Fix dangerous policy versioning rights

​8. Validate with the Policy Simulator

​9. Optional: enforce org‑wide via SCPs (if using AWS Organizations)

​1. Understand the Common IAM Privilege Escalation Paths

​2. Enumerate IAM Roles and Policies (Python/boto3)

​3. Identify High‑Risk Permissions in Policies

​4. Decide on Remediation Strategy (Per Finding)

​5. Remediate Excessive iam:PassRole

​5.1 Policy Before (too broad)

​5.2 Policy After (restricted roles + conditions)

​5.3 Update Policy Version via Python

​6. Remove or Restrict Delegated Policy Management (iam:*Policy*)

​7. Constrain sts:AssumeRole and Trust Policies

​7.1 Inspect trust policies

​7.2 Restrict trust policies

​8. Guardrails: Permission Boundaries and SCPs (Org‑Level)

​8.1 Permission Boundaries (per principal)

​8.2 Service Control Policies (SCPs) (Org‑wide)

​9. Special Case: Service‑Based Escalation (Lambda, EC2, etc.)

​10. Verification / Regression Checks

Triage and Remediation

Remediation