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, andaws.cloudtrail.user_identity.session_context.session_issuer.arn, and reviewsource.ip/user_agent.originalto determine how the change was made (console, CLI, SDK, automation). - Inspect
aws.cloudtrail.request_parametersfor the targeteduserName/roleNameand, forPut*operations, thepermissionsBoundarypolicy 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.arnafter 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, andiam:DeleteRolePermissionsBoundaryto a small set of trusted administrators.
References
Related rules
- AWS IAM Customer Managed Policy Version Created or Default Version Set
- AWS IAM Sensitive Operations via Lambda Execution Role
- AWS STS GetFederationToken with AdministratorAccess in Request
- AWS Account Discovery By Rare User
- AWS Sensitive IAM Operations Performed via CloudShell