AWS IAM AdministratorAccess Policy Attached to Role
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/05/31"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/10/13"
6
7[rule]
8author = ["Elastic"]
9description = """
10An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching
11additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to
12attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role.
13"""
14false_positives = [
15 """
16 While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
17 should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target
18 role.
19 """,
20]
21from = "now-6m"
22index = ["logs-aws.cloudtrail-*"]
23language = "eql"
24license = "Elastic License v2"
25name = "AWS IAM AdministratorAccess Policy Attached to Role"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> 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.
30
31### Investigating AWS IAM AdministratorAccess Policy Attached to Role
32
33The `AdministratorAccess` managed policy grants unrestricted privileges.
34When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services.
35This rule detects `AttachRolePolicy` events where the `policyName` is `AdministratorAccess`.
36
37#### Possible investigation steps
38
39- **Identify both identities.**
40 Determine the calling user or role (`aws.cloudtrail.user_identity.arn`) and the target role (`aws.cloudtrail.request_parameters.roleName`).
41 Validate whether this change aligns with intended administrative actions.
42
43- **Review the target role’s trust policy.**
44 Examine who can assume the role (`AssumeRolePolicyDocument`).
45 If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path.
46
47- **Review CloudTrail details.**
48 Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies.
49 Compare with historical operations by the same principal.
50
51- **Correlate with adjacent IAM events.**
52 Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls.
53 These often accompany privilege escalation activity.
54
55- **Inspect downstream activity.**
56 Query CloudTrail for recent `AssumeRole` calls for the target role — determine if the newly elevated permissions were used.
57
58### False positive analysis
59
60- **Delegated role management.**
61 Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs.
62- **Automation or service-linked roles.**
63 Some services attach policies automatically for setup; verify whether the target is a service-linked role.
64
65### Response and remediation
66
67**1. Immediate containment**
68- Detach the policy. Remove the `AdministratorAccess` policy from the target role.
69- Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed.
70- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it.
71- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges.
72
73**2. Evidence preservation**
74- Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert.
75- Preserve AWS Config snapshots and GuardDuty findings for traceability.
76
77**3. Scoping and investigation**
78- Identify if the elevated role was subsequently assumed.
79 Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN.
80- Search for other recent IAM policy attachments or modifications by the same actor or IP.
81
82**4. Recovery and hardening**
83- Apply least privilege policies; limit who can attach or modify administrative policies.
84- Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope.
85- Enable CloudTrail, GuardDuty, and Security Hub across all regions.
86- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments.
87
88### Additional information
89- **[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..
90- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): for containment, analysis, and recovery guidance.
91- **AWS Documentation:** [AdministratorAccess Policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator).
92"""
93references = [
94 "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html",
95 "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html",
96 "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
97]
98risk_score = 47
99rule_id = "dde13d58-bc39-4aa0-87fd-b4bdbf4591da"
100severity = "medium"
101tags = [
102 "Domain: Cloud",
103 "Data Source: AWS",
104 "Data Source: Amazon Web Services",
105 "Data Source: AWS IAM",
106 "Use Case: Identity and Access Audit",
107 "Tactic: Privilege Escalation",
108 "Tactic: Persistence",
109 "Resources: Investigation Guide",
110]
111timestamp_override = "event.ingested"
112type = "eql"
113
114query = '''
115iam where event.dataset == "aws.cloudtrail"
116 and event.provider == "iam.amazonaws.com"
117 and event.action == "AttachRolePolicy"
118 and event.outcome == "success"
119 and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")
120'''
121
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125[[rule.threat.technique]]
126id = "T1098"
127name = "Account Manipulation"
128reference = "https://attack.mitre.org/techniques/T1098/"
129[[rule.threat.technique.subtechnique]]
130id = "T1098.003"
131name = "Additional Cloud Roles"
132reference = "https://attack.mitre.org/techniques/T1098/003/"
133
134
135
136[rule.threat.tactic]
137id = "TA0004"
138name = "Privilege Escalation"
139reference = "https://attack.mitre.org/tactics/TA0004/"
140[[rule.threat]]
141framework = "MITRE ATT&CK"
142[[rule.threat.technique]]
143id = "T1098"
144name = "Account Manipulation"
145reference = "https://attack.mitre.org/techniques/T1098/"
146[[rule.threat.technique.subtechnique]]
147id = "T1098.003"
148name = "Additional Cloud Roles"
149reference = "https://attack.mitre.org/techniques/T1098/003/"
150
151
152
153[rule.threat.tactic]
154id = "TA0003"
155name = "Persistence"
156reference = "https://attack.mitre.org/tactics/TA0003/"
157
158[rule.investigation_fields]
159field_names = [
160 "@timestamp",
161 "user.name",
162 "user_agent.original",
163 "source.ip",
164 "aws.cloudtrail.user_identity.arn",
165 "aws.cloudtrail.user_identity.type",
166 "aws.cloudtrail.user_identity.access_key_id",
167 "event.action",
168 "event.outcome",
169 "cloud.account.id",
170 "cloud.region",
171 "aws.cloudtrail.request_parameters",
172]
Triage and analysis
Disclaimer: 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.
Investigating AWS IAM AdministratorAccess Policy Attached to Role
The AdministratorAccess managed policy grants unrestricted privileges.
When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services.
This rule detects AttachRolePolicy events where the policyName is AdministratorAccess.
Possible investigation steps
-
Identify both identities.
Determine the calling user or role (aws.cloudtrail.user_identity.arn) and the target role (aws.cloudtrail.request_parameters.roleName).
Validate whether this change aligns with intended administrative actions. -
Review the target role’s trust policy.
Examine who can assume the role (AssumeRolePolicyDocument).
If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path. -
Review CloudTrail details.
Checksource.ip,user_agent.original, andsource.geofields for anomalies.
Compare with historical operations by the same principal. -
Correlate with adjacent IAM events.
Look forUpdateAssumeRolePolicy,CreateAccessKey, orPassRolecalls.
These often accompany privilege escalation activity. -
Inspect downstream activity.
Query CloudTrail for recentAssumeRolecalls for the target role — determine if the newly elevated permissions were used.
False positive analysis
- Delegated role management.
Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs. - Automation or service-linked roles.
Some services attach policies automatically for setup; verify whether the target is a service-linked role.
Response and remediation
1. Immediate containment
- Detach the policy. Remove the
AdministratorAccesspolicy from the target role. - Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed.
- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it.
- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges.
2. Evidence preservation
- Export the triggering
AttachRolePolicyevent and related CloudTrail entries ±30 minutes from the alert. - Preserve AWS Config snapshots and GuardDuty findings for traceability.
3. Scoping and investigation
- Identify if the elevated role was subsequently assumed.
Correlate by matchingaws.cloudtrail.eventName:AssumeRolewith the target role ARN. - Search for other recent IAM policy attachments or modifications by the same actor or IP.
4. Recovery and hardening
- Apply least privilege policies; limit who can attach or modify administrative policies.
- Enforce IAM Conditions such as
aws:PrincipalArnoraws:ResourceTagto limit policy attachment scope. - Enable CloudTrail, GuardDuty, and Security Hub across all regions.
- Implement SCPs at the organization level to restrict direct
AdministratorAccessattachments.
Additional information
- **AWS IR Playbooks: response steps related to IAM policy modification and unauthorized privilege escalation..
- **AWS Customer Playbook Framework: for containment, analysis, and recovery guidance.
- AWS Documentation: AdministratorAccess Policy.
References
Related rules
- AWS IAM AdministratorAccess Policy Attached to Group
- AWS IAM AdministratorAccess Policy Attached to User
- AWS IAM Login Profile Added for Root
- AWS IAM Create User via Assumed Role on EC2 Instance
- AWS STS AssumeRole with New MFA Device