[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion

rules/integrations/aws/credential_access_iam_user_addition_to_group.toml

@@ -2,66 +2,75 @@
 creation_date = "2020/06/04"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2024/05/21"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
-description = "Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM)."
+description = """
+Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a
+group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin
+privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or
+privilege escalation.
+"""
 false_positives = [
     """
-    Adding users to a specified group may be done by a system or network administrator. Verify whether the user
-    identity, user agent, and/or hostname should be making changes in your environment. User additions from unfamiliar
-    users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
-    rule.
+    Legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event.
+    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. User
+    additions from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it
+    can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM User Addition to Group"
 note = """## Triage and analysis
 
-### Investigating AWS IAM User Addition to Group
+> **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.
 
-AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
+### Investigating AWS IAM User Addition to Group
 
-This rule looks for the addition of users to a specified user group.
+This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies).
 
 #### Possible investigation steps
 
-- Identify the user account that performed the action and whether it should perform this kind of action.
-- Investigate other alerts associated with the user account during the past 48 hours.
-- Contact the account and resource owners and confirm whether they are aware of this activity.
-- Check if this operation was approved and performed according to the organization's change management policy.
-- 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.
+- **Identify the actor and target**  
+  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
+  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
+  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.
+
+- **Examine the group’s privileges**  
+  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
+  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.
+
+- **Correlate with surrounding activity**  
+  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
+  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).
+
 
 ### False positive analysis
 
-- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions — to reduce noise from onboarding processes and administrator activities.
+- Onboarding or role transitions may legitimately add users to groups.  
+- Automated Identity-Management pipelines may add many users to service groups; validate know
 
 ### Response and remediation
 
-- Initiate the incident response process based on the outcome of the triage.
-- Disable or limit the account during the investigation and response.
-- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
-    - Identify the account role in the cloud environment.
-    - Assess the criticality of affected services and servers.
-    - Work with your IT team to identify and minimize the impact on users.
-    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
-    - Identify any regulatory or legal ramifications related to this activity.
-- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
-- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
-- Consider enabling multi-factor authentication for users.
-- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
-- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
-- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
-- 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).
-
-## Setup
-
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+- **Containment**:
+  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
+  - Temporarily restrict group policy changes while assessing blast radius.
+- **Investigation and scoping**:
+  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
+  - Confirm whether other users were added to the same group within the same window. 
+- **Recovery and hardening**: 
+  - Enforce least privilege by redesigning large-group membership. 
+  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
+  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.
+
+### Additional information
+[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
 references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html"]
 risk_score = 21
 rule_id = "333de828-8190-4cf5-8d7c-7575846f6fe0"
@@ -79,7 +88,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:AddUserToGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: AddUserToGroup and 
+    event.outcome: success
 '''
 
 
@@ -103,3 +115,20 @@ id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "user.target.name",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+

rules/integrations/aws/impact_iam_group_deletion.toml

@@ -2,24 +2,25 @@
 creation_date = "2020/05/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/10/30"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies the deletion of a specified AWS Identity and Access Management (IAM) resource group. Deleting a resource
-group does not delete resources that are members of the group; it only deletes the group structure.
+Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious
+attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group
+briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle.
 """
 false_positives = [
     """
-    A resource group may be deleted by a system administrator. Verify whether the user identity, user agent, and/or
-    hostname should be making changes in your environment. Resource group deletions by unfamiliar users or hosts should
-    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    Legitimate group deletion during decommissioning of projects, clean-up of service accounts, or identity lifecycle
+    changes may trigger this alert. Verify whether the user identity, user agent, and/or hostname should be making
+    changes in your environment. Resource group deletions by unfamiliar users or hosts should be investigated. If known
+    behavior is causing false positives, it can be exempted from the rule.
     """,
 ]
-from = "now-60m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
-interval = "10m"
 language = "kuery"
 license = "Elastic License v2"
 name = "AWS IAM Group Deletion"
@@ -30,37 +31,37 @@ note = """## Triage and analysis
 
 ### Investigating AWS IAM Group Deletion
 
-AWS IAM groups facilitate user management by organizing users with similar permissions. Adversaries might exploit group deletion to disrupt access controls, potentially leading to unauthorized access or service disruption. The detection rule monitors successful group deletions via AWS CloudTrail, flagging potential misuse by correlating specific IAM actions and outcomes, thus aiding in timely threat identification.
+Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified.
 
 ### Possible investigation steps
 
-- Review the AWS CloudTrail logs to identify the user or role that performed the DeleteGroup action by examining the userIdentity field.
-- Check the event time to determine when the group deletion occurred and correlate it with any other suspicious activities around the same timeframe.
-- Investigate the specific IAM group that was deleted to understand its purpose and the permissions it granted by reviewing historical IAM policies and group membership.
-- Assess the impact of the group deletion by identifying any users or services that might have been affected due to the loss of group-based permissions.
-- Verify if the group deletion was authorized by cross-referencing with change management records or contacting the responsible team or individual.
-- Look for any patterns or repeated occurrences of similar actions in the logs to identify potential malicious behavior or misconfigurations.
+- **Identify the actor and environment**  
+  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`.  
+  - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity.
+
+- **Determine what was lost**
+  - From `aws.cloudtrail.request_parameters`, capture `groupName`.  
+  - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`).  
+  - Determine if the group contained privileged roles/policies that could have been weaponized.
+
+- **Correlate with related activity**
+  - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows.  
+  - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles.
 
 ### False positive analysis
 
-- Routine administrative tasks may trigger alerts when IAM groups are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known maintenance periods or specific administrative accounts.
-- Automated scripts or tools that manage IAM resources might delete groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers.
-- Temporary groups created for short-term projects or testing purposes might be deleted frequently. Document these groups and exclude their deletion from monitoring by using naming conventions or tags.
-- Changes in organizational structure or policy might necessitate the deletion of certain groups. Coordinate with relevant teams to anticipate these changes and adjust monitoring rules accordingly.
+- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control.  
+- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood.
 
 ### Response and remediation
 
-- Immediately revoke any active sessions and access keys for users who were part of the deleted IAM group to prevent unauthorized access.
-- Restore the deleted IAM group from a backup or recreate it with the same permissions to ensure continuity of access for legitimate users.
-- Conduct a review of recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded the group deletion.
-- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
-- Implement additional monitoring on IAM activities, especially focusing on group management actions, to detect similar threats in the future.
-- Review and tighten IAM policies and permissions to ensure that only authorized personnel can delete IAM groups.
-- If malicious intent is suspected, escalate the incident to the incident response team for a comprehensive investigation and potential legal action.
-
-## Setup
+- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes.  
+- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption).  
+- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations.
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+### Additional information
+[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
+"""
 references = [
     "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html",
     "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html",
@@ -80,7 +81,10 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:DeleteGroup and event.outcome:success
+event.dataset: aws.cloudtrail and 
+    event.provider: iam.amazonaws.com and 
+    event.action: DeleteGroup and 
+    event.outcome: success
 '''
 
 
@@ -97,3 +101,19 @@ id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
 
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "user.name",
+    "user_agent.original",
+    "source.ip",
+    "aws.cloudtrail.user_identity.arn",
+    "aws.cloudtrail.user_identity.type",
+    "aws.cloudtrail.user_identity.access_key_id",
+    "event.action",
+    "event.outcome",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.request_parameters",
+]
+