AWS IAM AdministratorAccess Policy Attached to Group

An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group.

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 user groups the compromised user account belongs to. This rule looks for use of the IAM
 12AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing
 13IAM user group.
 14"""
 15false_positives = [
 16    """
 17    While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
 18    should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user
 19    group.
 20    """,
 21]
 22from = "now-6m"
 23index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "AWS IAM AdministratorAccess Policy Attached to Group"
 27note = """## Triage and analysis
 28
 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.
 31
 32### Investigating AWS IAM AdministratorAccess Policy Attached to Group
 33
 34The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services.  
 35When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise.  
 36Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group.
 37
 38#### Possible investigation steps
 39
 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.  
 59
 60### False positive analysis
 61
 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.  
 66
 67### Response and remediation
 68
 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.
 93- **AWS Documentation:** [AdministratorAccess Policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator).
 94"""
 95references = [
 96    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html",
 97    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html",
 98    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
 99]
100risk_score = 47
101rule_id = "df919b5e-a0f6-4fd8-8598-e3ce79299e3b"
102severity = "medium"
103tags = [
104    "Domain: Cloud",
105    "Data Source: AWS",
106    "Data Source: Amazon Web Services",
107    "Data Source: AWS IAM",
108    "Use Case: Identity and Access Audit",
109    "Tactic: Privilege Escalation",
110    "Tactic: Persistence",
111    "Resources: Investigation Guide",
112]
113timestamp_override = "event.ingested"
114type = "eql"
115
116query = '''
117iam where event.dataset == "aws.cloudtrail"
118   and event.provider == "iam.amazonaws.com"
119   and event.action == "AttachGroupPolicy"
120   and event.outcome == "success"
121   and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")
122'''
123
124
125[[rule.threat]]
126framework = "MITRE ATT&CK"
127[[rule.threat.technique]]
128id = "T1098"
129name = "Account Manipulation"
130reference = "https://attack.mitre.org/techniques/T1098/"
131[[rule.threat.technique.subtechnique]]
132id = "T1098.003"
133name = "Additional Cloud Roles"
134reference = "https://attack.mitre.org/techniques/T1098/003/"
135
136
137
138[rule.threat.tactic]
139id = "TA0004"
140name = "Privilege Escalation"
141reference = "https://attack.mitre.org/tactics/TA0004/"
142[[rule.threat]]
143framework = "MITRE ATT&CK"
144[[rule.threat.technique]]
145id = "T1098"
146name = "Account Manipulation"
147reference = "https://attack.mitre.org/techniques/T1098/"
148[[rule.threat.technique.subtechnique]]
149id = "T1098.003"
150name = "Additional Cloud Roles"
151reference = "https://attack.mitre.org/techniques/T1098/003/"
152
153
154
155[rule.threat.tactic]
156id = "TA0003"
157name = "Persistence"
158reference = "https://attack.mitre.org/tactics/TA0003/"
159
160[rule.investigation_fields]
161field_names = [
162    "@timestamp",
163    "user.name",
164    "user_agent.original",
165    "source.ip",
166    "aws.cloudtrail.user_identity.arn",
167    "aws.cloudtrail.user_identity.type",
168    "aws.cloudtrail.user_identity.access_key_id",
169    "event.action",
170    "group.name",
171    "event.outcome",
172    "cloud.account.id",
173    "cloud.region",
174    "aws.cloudtrail.request_parameters",
175]

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 Group

The AWS-managed AdministratorAccess policy grants full administrative privileges across all AWS services.
When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise.
Adversaries can exploit iam:AttachGroupPolicy permissions to escalate privileges or establish persistence by attaching this policy to an existing user group.

Possible investigation steps

  • Identify the affected group and calling principal.
    Review aws.cloudtrail.user_identity.arn (caller) and aws.cloudtrail.request_parameters.groupName (target group).
    Validate whether this aligns with legitimate change management or automation workflows.

  • Review group membership.
    Enumerate current members using aws iam get-group.
    Determine whether unauthorized users could have gained administrative access as a result.

  • Inspect CloudTrail details.
    Check source.ip, user_agent.original, and source.geo fields for anomalies.
    Compare with historical operations by the same principal.

  • Correlate related IAM activity.
    Search for adjacent events such as AddUserToGroup, CreateUser, or AttachUserPolicy.
    These may indicate chained privilege escalation.

  • Assess propagation of privileges.
    If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user.
    Document all affected identities for containment.

False positive analysis

  • Intentional access updates.
    Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems.
  • Automation or compliance tasks.
    Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs.

Response and remediation

1. Immediate containment

  • Detach the policy from the affected group (aws iam detach-group-policy).
  • Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts.
  • Rotate credentials for users who inherited admin privileges from the attachment.
  • Enable MFA on all impacted accounts.

2. Evidence preservation

  • Export the triggering AttachGroupPolicy event and related CloudTrail entries ±30 minutes from the alert.
  • Preserve AWS Config and GuardDuty records to support forensic analysis.

3. Scoping and investigation

  • Review additional IAM operations from the same caller (CreateAccessKey, AttachRolePolicy, UpdateAssumeRolePolicy).
  • Identify whether new groups or roles were created shortly before or after the event.
  • Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications).

4. Recovery and hardening

  • Reinforce least privilege, avoid assigning AdministratorAccess to groups.
  • Use role-based access control with scoped permissions.
  • Enable CloudTrail, GuardDuty, and Security Hub across all regions.
  • Implement SCPs at the organization level to restrict direct AdministratorAccess attachments.

Additional information

References

Related rules

to-top