You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Rule Tunings] AWS IAM Administrator Access Policy Attached to Group/Role/User (#5215)
* [Rule Tunings] AWS IAM Administrator Access Policy Attached to Group/Role/User
All 3 rules triggering as expected, low telemetry volume. However, the same rule logic can be applied via EQL so I've changed the rule types for all 3 from ESQL to EQL. To provide better telemetry and alert context for users.
- changed rule type to EQL
- updated all IGs
- added highlighted fields
- added index
* removed double note key
removed double note key
* adding iam event.category
* removed file beat compatibility missing category for AttachRolePolicy
filebeat does not have category mapping for AttachRolePolicy event
* toml-lint
Copy file name to clipboardExpand all lines: rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml
+82-66Lines changed: 82 additions & 66 deletions
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,15 @@
2
2
creation_date = "2024/05/31"
3
3
integration = ["aws"]
4
4
maturity = "production"
5
-
updated_date = "2025/07/16"
5
+
updated_date = "2025/10/13"
6
6
7
7
[rule]
8
8
author = ["Elastic"]
9
9
description = """
10
10
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching
11
11
additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM
12
-
`AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an
13
-
existing IAM user group.
12
+
AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing
13
+
IAM user group.
14
14
"""
15
15
false_positives = [
16
16
"""
@@ -20,61 +20,77 @@ false_positives = [
20
20
""",
21
21
]
22
22
from = "now-6m"
23
-
language = "esql"
23
+
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
24
+
language = "eql"
24
25
license = "Elastic License v2"
25
26
name = "AWS IAM AdministratorAccess Policy Attached to Group"
26
27
note = """## Triage and analysis
27
28
28
-
### Investigating AWS IAM AdministratorAccess Policy Attached to Group
29
+
> **Disclaimer**:
30
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
29
31
30
-
The AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.
31
-
With access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach
32
-
this policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)
33
-
to look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.
32
+
### Investigating AWS IAM AdministratorAccess Policy Attached to Group
34
33
34
+
The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services.
35
+
When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise.
36
+
Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group.
35
37
36
38
#### Possible investigation steps
37
39
38
-
- Identify the account and its role in the environment.
39
-
- Review IAM permission policies for the user identity.
40
-
- Identify the applications or users that should use this account.
41
-
- Investigate other alerts associated with the account during the past 48 hours.
42
-
- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.
43
-
- Contact the account owner and confirm whether they are aware of this activity.
44
-
- Considering the source IP address and geolocation of the user who issued the command:
45
-
- Do they look normal for the calling user?
46
-
- If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
47
-
- If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
48
-
- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
49
-
- Determine what other API calls were made by the user.
50
-
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.
40
+
- **Identify the affected group and calling principal.**
41
+
Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group).
42
+
Validate whether this aligns with legitimate change management or automation workflows.
43
+
44
+
- **Review group membership.**
45
+
Enumerate current members using `aws iam get-group`.
46
+
Determine whether unauthorized users could have gained administrative access as a result.
47
+
48
+
- **Inspect CloudTrail details.**
49
+
Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies.
50
+
Compare with historical operations by the same principal.
51
+
52
+
- **Correlate related IAM activity.**
53
+
Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`.
54
+
These may indicate chained privilege escalation.
55
+
56
+
- **Assess propagation of privileges.**
57
+
If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user.
58
+
Document all affected identities for containment.
51
59
52
60
### False positive analysis
53
61
54
-
- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.
62
+
- **Intentional access updates.**
63
+
Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems.
64
+
- **Automation or compliance tasks.**
65
+
Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs.
55
66
56
67
### Response and remediation
57
68
58
-
- Initiate the incident response process based on the outcome of the triage.
59
-
- Disable or limit the account during the investigation and response.
60
-
- Rotate user credentials
61
-
- Remove the `AdministratorAccess` policy from the affected group(s)
62
-
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
63
-
- Identify the account role in the cloud environment.
64
-
- Assess the criticality of affected services and servers.
65
-
- Work with your IT team to identify and minimize the impact on users.
66
-
- Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
67
-
- Identify any regulatory or legal ramifications related to this activity.
68
-
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.
69
-
- Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.
70
-
- Work with your IT teams to minimize the impact on business operations during these actions.
71
-
- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
72
-
- Consider enabling multi-factor authentication for users.
73
-
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
74
-
- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
75
-
- Take the actions needed to return affected systems, data, or services to their normal operational levels.
76
-
- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
77
-
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
69
+
**1. Immediate containment**
70
+
- Detach the policy from the affected group (`aws iam detach-group-policy`).
71
+
- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts.
72
+
- Rotate credentials for users who inherited admin privileges from the attachment.
73
+
- Enable MFA on all impacted accounts.
74
+
75
+
**2. Evidence preservation**
76
+
- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert.
77
+
- Preserve AWS Config and GuardDuty records to support forensic analysis.
78
+
79
+
**3. Scoping and investigation**
80
+
- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`).
81
+
- Identify whether new groups or roles were created shortly before or after the event.
82
+
- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications).
83
+
84
+
**4. Recovery and hardening**
85
+
- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups.
86
+
- Use role-based access control with scoped permissions.
87
+
- Enable CloudTrail, GuardDuty, and Security Hub across all regions.
88
+
- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments.
89
+
90
+
### Additional information
91
+
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/): response steps related to IAM policy modification and unauthorized privilege escalation..
92
+
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): for containment, analysis, and recovery guidance.
0 commit comments