---
title: AWS IAM Permissions Boundary Modified or Removed
description: Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/aws/privilege_escalation_iam_permissions_boundary_modified
products:
  - Elastic Security
---

# AWS IAM Permissions Boundary Modified or Removed
Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary
caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can
delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more
permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the
identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed
by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant
review.
**Rule type**: query
**Rule indices**:
- logs-aws.cloudtrail-*

**Rule Severity**: medium
**Risk Score**: 47
**Runs every**: 
**Searches indices from**: `now-6m`
**Maximum alerts per execution**: 100
**References**:
- [[https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
- [[https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/](https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/)](https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/)

**Tags**:
- Domain: Cloud
- Domain: Identity
- Data Source: AWS
- Data Source: Amazon Web Services
- Data Source: AWS IAM
- Use Case: Threat Detection
- Tactic: Privilege Escalation
- Resources: Investigation Guide
- Noise: Unknown
- Performance: Fast
- Rule Type: Custom Query (KQL)
- Platform: AWS
- Data Source: AWS CloudTrail
- Service: AWS IAM

**Version**: 2
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Investigation guide


## Triage and analysis


### Investigating AWS IAM Permissions Boundary Modified or Removed

An IAM permissions boundary is the maximum set of permissions an identity can ever have — even if its identity policies grant more, the effective permissions are the intersection of the two. Removing a boundary (`DeleteUserPermissionsBoundary` / `DeleteRolePermissionsBoundary`) or replacing it with a broader one (`PutUserPermissionsBoundary` / `PutRolePermissionsBoundary`) lifts that cap, so any permissions already present in the identity's attached policies immediately take effect. This is a recognized privilege-escalation path: an adversary who can edit a boundary can unlock latent permissions without attaching any new policy.

#### Possible investigation steps

- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original` to determine how the change was made (console, CLI, SDK, automation).
- Inspect `aws.cloudtrail.request_parameters` for the targeted `userName`/`roleName` and, for `Put*` operations, the `permissionsBoundary` policy ARN that was applied.
- Determine the identity's attached identity policies to assess what permissions are now unlocked by the boundary change (the effective blast radius).
- Confirm whether the change aligns with an approved governance change, onboarding, or deployment.
- Correlate with recent activity by the same principal, such as policy attachment, access key creation, or role assumption that may indicate an escalation chain.


### False positive analysis

- Identity/platform teams and infrastructure-as-code routinely set and update boundaries. Confirm the change is approved and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation.


### Response and remediation

- If the change is unauthorized, restore the intended permissions boundary on the affected identity and review what the identity could access while the boundary was relaxed or absent.
- Rotate or restrict credentials for the principal that made the change if compromise is suspected, and constrain `iam:PutUserPermissionsBoundary`, `iam:PutRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, and `iam:DeleteRolePermissionsBoundary` to a small set of trusted administrators.


## Rule Query

```kuery
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: (
        "PutUserPermissionsBoundary" or
        "PutRolePermissionsBoundary" or
        "DeleteUserPermissionsBoundary" or
        "DeleteRolePermissionsBoundary"
    )
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and not user_agent.original: (*terraform* or *pulumi* or *ansible*)
    and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*)
    and not source.as.organization.name: (Amazon* or AMAZON* or Google*)
    and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com")
```

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Privilege Escalation
  - Id: TA0004
  - Reference URL: [[https://attack.mitre.org/tactics/TA0004/](https://attack.mitre.org/tactics/TA0004/)](https://attack.mitre.org/tactics/TA0004/)
- Technique:
  - Name: Account Manipulation
  - Id: T1098
  - Reference URL: [[https://attack.mitre.org/techniques/T1098/](https://attack.mitre.org/techniques/T1098/)](https://attack.mitre.org/techniques/T1098/)