AWS IAM Permissions Boundary Modified or Removed

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

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-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

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

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

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

edit

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^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/

« AWS IAM Inline Policy Added to a Group Azure AD Graph Access with Unusual User and ASN »