Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,171 @@
[[prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-group]]
=== 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.

*Rule type*: eql

*Rule indices*:

* filebeat-*
* logs-aws.cloudtrail-*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html
* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html
* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS IAM
* Use Case: Identity and Access Audit
* Tactic: Privilege Escalation
* Tactic: Persistence
* Resources: Investigation Guide

*Version*: 7

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



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

- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation..
- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance.
- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy].


==== Rule query


[source, js]
----------------------------------
iam where event.dataset == "aws.cloudtrail"
and event.provider == "iam.amazonaws.com"
and event.action == "AttachGroupPolicy"
and event.outcome == "success"
and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")

----------------------------------

*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/
* Sub-technique:
** Name: Additional Cloud Roles
** ID: T1098.003
** Reference URL: https://attack.mitre.org/techniques/T1098/003/
* Tactic:
** Name: Persistence
** ID: TA0003
** Reference URL: https://attack.mitre.org/tactics/TA0003/
* Technique:
** Name: Account Manipulation
** ID: T1098
** Reference URL: https://attack.mitre.org/techniques/T1098/
* Sub-technique:
** Name: Additional Cloud Roles
** ID: T1098.003
** Reference URL: https://attack.mitre.org/techniques/T1098/003/
Original file line number Diff line number Diff line change
@@ -0,0 +1,169 @@
[[prebuilt-rule-8-19-9-aws-iam-administratoraccess-policy-attached-to-role]]
=== 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.

*Rule type*: eql

*Rule indices*:

* logs-aws.cloudtrail-*

*Severity*: medium

*Risk score*: 47

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html
* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html
* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS IAM
* Use Case: Identity and Access Audit
* Tactic: Privilege Escalation
* Tactic: Persistence
* Resources: Investigation Guide

*Version*: 7

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*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.**
Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies.
Compare with historical operations by the same principal.

- **Correlate with adjacent IAM events.**
Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls.
These often accompany privilege escalation activity.

- **Inspect downstream activity.**
Query CloudTrail for recent `AssumeRole` calls 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 `AdministratorAccess` policy 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 `AttachRolePolicy` event 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 matching `aws.cloudtrail.eventName:AssumeRole` with 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:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope.
- Enable CloudTrail, GuardDuty, and Security Hub across all regions.
- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments.


*Additional information*

- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation..
- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance.
- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy].


==== Rule query


[source, js]
----------------------------------
iam where event.dataset == "aws.cloudtrail"
and event.provider == "iam.amazonaws.com"
and event.action == "AttachRolePolicy"
and event.outcome == "success"
and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")

----------------------------------

*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/
* Sub-technique:
** Name: Additional Cloud Roles
** ID: T1098.003
** Reference URL: https://attack.mitre.org/techniques/T1098/003/
* Tactic:
** Name: Persistence
** ID: TA0003
** Reference URL: https://attack.mitre.org/tactics/TA0003/
* Technique:
** Name: Account Manipulation
** ID: T1098
** Reference URL: https://attack.mitre.org/techniques/T1098/
* Sub-technique:
** Name: Additional Cloud Roles
** ID: T1098.003
** Reference URL: https://attack.mitre.org/techniques/T1098/003/
Loading