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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/18"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/06/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary
 11caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can
 12delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more
 13permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the
 14identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed
 15by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant
 16review.
 17"""
 18false_positives = [
 19    """
 20    Permissions boundaries are managed by identity/platform teams and infrastructure-as-code pipelines as part of normal
 21    governance. Verify the principal in `aws.cloudtrail.user_identity.arn`, the targeted user or role, and the boundary
 22    policy against approved change records. Known administration roles and deployment automation can be excluded after
 23    validation.
 24    """,
 25]
 26from = "now-6m"
 27index = ["logs-aws.cloudtrail-*"]
 28language = "kuery"
 29license = "Elastic License v2"
 30name = "AWS IAM Permissions Boundary Modified or Removed"
 31note = """## Triage and analysis
 32
 33### Investigating AWS IAM Permissions Boundary Modified or Removed
 34
 35An 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.
 36
 37#### Possible investigation steps
 38
 39- 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).
 40- Inspect `aws.cloudtrail.request_parameters` for the targeted `userName`/`roleName` and, for `Put*` operations, the `permissionsBoundary` policy ARN that was applied.
 41- Determine the identity's attached identity policies to assess what permissions are now unlocked by the boundary change (the effective blast radius).
 42- Confirm whether the change aligns with an approved governance change, onboarding, or deployment.
 43- Correlate with recent activity by the same principal, such as policy attachment, access key creation, or role assumption that may indicate an escalation chain.
 44
 45### False positive analysis
 46
 47- 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.
 48
 49### Response and remediation
 50
 51- 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.
 52- 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.
 53
 54"""
 55references = [
 56    "https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html",
 57    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
 58]
 59risk_score = 47
 60rule_id = "0f5d410c-a594-4cdb-8b48-f36a61838d67"
 61severity = "medium"
 62tags = [
 63    "Domain: Cloud",
 64    "Domain: Identity",
 65    "Data Source: AWS",
 66    "Data Source: Amazon Web Services",
 67    "Data Source: AWS IAM",
 68    "Use Case: Threat Detection",
 69    "Tactic: Privilege Escalation",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "query"
 74
 75query = '''
 76data_stream.dataset: "aws.cloudtrail"
 77    and event.provider: "iam.amazonaws.com"
 78    and event.action: (
 79        "PutUserPermissionsBoundary" or
 80        "PutRolePermissionsBoundary" or
 81        "DeleteUserPermissionsBoundary" or
 82        "DeleteRolePermissionsBoundary"
 83    )
 84    and event.outcome: "success"
 85    and not aws.cloudtrail.user_identity.type: "AWSService"
 86    and not user_agent.original: (*terraform* or *pulumi* or *ansible*)
 87    and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*)
 88    and not source.as.organization.name: (Amazon* or AMAZON* or Google*)
 89    and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com")
 90'''
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1098"
 97name = "Account Manipulation"
 98reference = "https://attack.mitre.org/techniques/T1098/"
 99
100
101[rule.threat.tactic]
102id = "TA0004"
103name = "Privilege Escalation"
104reference = "https://attack.mitre.org/tactics/TA0004/"
105
106[rule.investigation_fields]
107field_names = [
108    "@timestamp",
109    "user.name",
110    "user_agent.original",
111    "source.ip",
112    "aws.cloudtrail.user_identity.arn",
113    "aws.cloudtrail.user_identity.type",
114    "aws.cloudtrail.user_identity.access_key_id",
115    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
116    "aws.cloudtrail.request_parameters",
117    "aws.cloudtrail.response_elements",
118    "event.action",
119    "event.outcome",
120    "cloud.account.id",
121    "cloud.region",
122]

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.

References

Related rules

to-top