The 8 Known IAM Privilege Escalation Paths and How to Prevent Them

IAM privilege escalation occurs when non-privileged principals obtain permissions to modify IAM policies or attach existing high-privilege policies, allowing attackers to grant themselves administrative access to AWS resources.

AWS Identity and Access Management (IAM) serves as the cornerstone of access control for all AWS services. According to the aws/agent-toolkit-for-aws repository, specifically documented in skills/core-skills/aws-iam/SKILL.md, eight specific IAM actions enable direct privilege escalation when granted to non-administrative principals, while iam:PassRole with wildcard resources presents a critical indirect vector.

The Eight IAM Privilege Escalation Actions

The Agent Toolkit for AWS identifies eight exact IAM actions that permit escalation from limited permissions to full administrative rights. Each action allows modification of permission boundaries or attachment of high-privilege policies.

iam:PutGroupPolicy

The iam:PutGroupPolicy action allows a principal to attach an inline policy to any IAM group. This enables an attacker to grant AdministratorAccess or other high-privilege actions to all group members.

Prevention strategies:

• Never allow iam:PutGroupPolicy on groups you do not own.
• Restrict the Resource ARN to the specific group(s) a principal must manage.
• Audit group policies with IAM Access Analyzer.

iam:PutRolePolicy

The iam:PutRolePolicy action permits adding an inline policy to a role. If the role is trusted by a compute service such as EC2 or Lambda, an attacker can grant themselves the role’s permissions by modifying the role's trust policy or assuming the role through the service.

Prevention strategies:

• Limit iam:PutRolePolicy to roles you purpose-manage.
• Scope the Resource to role ARNs with a predictable naming pattern, such as arn:aws:iam::*:role/TeamX-*.
• Enable policy-only guardrails that deny inline-policy changes.

iam:PutUserPolicy

The iam:PutUserPolicy action enables adding an inline policy directly to a user, which can include iam:*, sts:*, or cloudformation:* actions, effectively granting the user broad administrative powers.

Prevention strategies:

• Only grant iam:PutUserPolicy to admin-level operators.
• Pair with a condition that checks aws:PrincipalTag/IsAdmin = true.
• Use Service Control Policies (SCPs) to block policy-write actions for regular accounts.

iam:CreatePolicy

The iam:CreatePolicy action allows a principal to create a managed policy that can later be attached to any principal, establishing a weaponized policy ready for attachment.

Prevention strategies:

• Restrict iam:CreatePolicy to a dedicated "policy-creator" role.
• Require iam:CreatePolicyVersion in the same policy to enforce version limits.
• Audit newly created policies for full-access actions.

iam:CreatePolicyVersion

The iam:CreatePolicyVersion action permits adding a new version to an existing managed policy. By creating a version that includes privileged actions and setting it as default, an attacker can silently elevate privileges without creating new policy objects.

Prevention strategies:

• Permit iam:CreatePolicyVersion only on policies you own.
• Combine with a condition that aws:RequestTag/ManagedBy = admin.
• Enable "prevent-default-version-change" guardrails using custom IAM condition keys.

iam:AttachGroupPolicy

The iam:AttachGroupPolicy action grants the ability to attach an existing managed policy to a group. Attaching AdministratorAccess or a custom high-privilege policy instantly elevates all members of that group.

Prevention strategies:

• Scope Resource to the specific policy ARNs you intend to attach.
• Use SCPs or permission boundaries to block attachment of *FullAccess policies.

iam:AttachRolePolicy

Similar to AttachGroupPolicy, the iam:AttachRolePolicy action targets roles used by services. Attaching a privileged policy can give a compute service such as Lambda elevated rights that the attacker can then leverage.

Prevention strategies:

• Limit attachments to roles with a known, minimal set of actions.
• Enforce a condition such as iam:PassedToService = lambda.amazonaws.com when attaching to Lambda roles.
• Audit role-policy attachments daily.

iam:AttachUserPolicy

The iam:AttachUserPolicy action allows attaching a managed policy to a user. Adding a policy with iam:* or sts:* instantly grants the user broad powers to manipulate the AWS environment.

Prevention strategies:

• Restrict Resource to a whitelist of safe policies.
• Employ a deny-list SCP that blocks attachment of any policy containing *FullAccess or *Administrator.

The Indirect Vector: iam:PassRole with Wildcard Resources

Even if an attacker cannot directly modify policies, the iam:PassRole action with a wildcard resource ("*") allows them to pass any role to a service such as EC2, Lambda, or CloudFormation. When combined with the eight actions above, this enables the attacker to assume any role, including an Administrator role.

Prevention strategies:

• Never use "Resource": "*" for iam:PassRole.
• Specify exact role ARNs the principal may pass.
• Add condition keys like iam:PassedToService and iam:AssociatedResourceArn to tightly bound the operation.

Mitigation Strategies

Beyond restricting individual actions, implement defense-in-depth strategies to prevent IAM privilege escalation across your AWS organization.

Use Permission Boundaries

Define permission boundaries that disallow the eight escalation actions for all non-admin roles. Permission boundaries act as a guardrail that limits the maximum permissions an IAM entity can have, even if its identity-based policies are compromised.

Leverage Service Control Policies

In an AWS Organization, apply an SCP that denies the eight escalation actions globally, then grant exceptions only to dedicated administrative organizational units (OUs). The rules/aws-agent-rules.md file in the Agent Toolkit provides example rule sets for blocking these privilege-escalation actions.

Enable IAM Access Analyzer

Continuously scan for policies that grant the listed actions and receive actionable findings. IAM Access Analyzer identifies resources shared with external entities and detects overly permissive policies.

Implement Tag-Based Conditions

Tag privileged principals with attributes such as Tag:Privilege=admin and require that tag in any policy-write request. This ensures that only explicitly marked administrative principals can modify IAM configurations.

Audit Inline vs. Managed Policies

Inline policies are harder to discover than managed policies. Prefer managed policies with version control and explicit approvals to maintain visibility into permission changes.

Automated Remediation

Use CloudWatch Events or EventBridge to trigger a Lambda function that revokes any newly created or attached privileged policy that is not on an allow-list.

Code Examples

Least-Privilege iam:PassRole

Restrict a build pipeline to pass only the CI role to CodeBuild:

# Allow a build pipeline to pass only the CI-role to CodeBuild

Version: "2012-10-17"
Statement:
  - Effect: Allow
    Action: iam:PassRole
    Resource: arn:aws:iam::123456789012:role/ci-role
    Condition:
      StringEquals:
        iam:PassedToService: codebuild.amazonaws.com

Deny Policy-Write Actions via SCP

Attach this SCP to all member accounts to block the eight escalation actions:

# SCP attached to all member accounts

Version: "2012-10-17"
Statement:
  - Effect: Deny
    Action:
      - iam:PutGroupPolicy
      - iam:PutRolePolicy
      - iam:PutUserPolicy
      - iam:CreatePolicy
      - iam:CreatePolicyVersion
      - iam:AttachGroupPolicy
      - iam:AttachRolePolicy
      - iam:AttachUserPolicy
    Resource: "*"

Summary

• IAM privilege escalation relies on eight specific actions: iam:PutGroupPolicy, iam:PutRolePolicy, iam:PutUserPolicy, iam:CreatePolicy, iam:CreatePolicyVersion, iam:AttachGroupPolicy, iam:AttachRolePolicy, and iam:AttachUserPolicy.
• The iam:PassRole action with wildcard resources serves as a critical indirect vector that enables attackers to assume any role when combined with other permissions.
• Prevention requires restricting resources to specific ARNs, using Service Control Policies to deny dangerous actions globally, and implementing permission boundaries.
• Monitoring via IAM Access Analyzer and automated remediation through EventBridge provides continuous protection against policy modifications.
• Reference the skills/core-skills/aws-iam/SKILL.md file in the aws/agent-toolkit-for-aws repository for the complete technical specification of these escalation paths.

Frequently Asked Questions

What is IAM privilege escalation?

IAM privilege escalation occurs when a principal with limited permissions exploits IAM actions to grant themselves broader administrative access. According to the Agent Toolkit for AWS source code in skills/core-skills/aws-iam/SKILL.md, this typically involves manipulating policies through eight specific write-level actions that modify permissions boundaries or attaching existing high-privilege managed policies to users, roles, or groups.

How does iam:PassRole enable privilege escalation?

The iam:PassRole action enables privilege escalation when combined with other permissions because it allows a principal to pass any role to an AWS service such as EC2 or Lambda. If the principal also has permissions to modify the service or the role's trust relationship, they can assume the passed role. When granted with a wildcard resource ("*"), it permits passing any role in the account, including Administrator roles, making it a powerful indirect escalation vector.

What is the difference between inline policy and managed policy escalation?

Inline policy escalation uses iam:PutUserPolicy, iam:PutRolePolicy, or iam:PutGroupPolicy to embed policies directly into an IAM entity, making them harder to audit and track. Managed policy escalation uses iam:CreatePolicy, iam:CreatePolicyVersion, and the various Attach actions to either create new reusable policies or attach existing ones such as AdministratorAccess. Managed policies are easier to monitor but allow attackers to weaponize policies and attach them to multiple entities.

How do Service Control Policies prevent privilege escalation?

Service Control Policies (SCPs) prevent privilege escalation by acting as guardrails that apply to all IAM entities within an AWS Organization, including the root user. By attaching an SCP that explicitly denies the eight escalation actions (Deny effect on iam:PutGroupPolicy, iam:PutRolePolicy, etc.), you ensure that no principal in member accounts can execute these actions, even if their identity-based policies inadvertently grant them. Exceptions can be carved out for specific organizational units housing administrative accounts.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}