AWS IAM User Addition to Group

  1[metadata]
  2creation_date = "2020/06/04"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a
 11group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin
 12privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or
 13privilege escalation.
 14"""
 15false_positives = [
 16    """
 17    Legitimate operations such as new user onboarding, role changes, or service account updates may trigger this event.
 18    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. User
 19    additions from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it
 20    can be exempted from the rule.
 21    """,
 22]
 23from = "now-6m"
 24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "AWS IAM User Addition to Group"
 28note = """## Triage and analysis
 29
 30> **Disclaimer**:
 31> 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.
 32
 33### Investigating AWS IAM User Addition to Group
 34
 35This 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).
 36
 37#### Possible investigation steps
 38
 39- **Identify the actor and target**  
 40  - Check `aws.cloudtrail.user_identity.arn` for who added the user.  
 41  - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group).  
 42  - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns.
 43
 44- **Examine the group’s privileges**  
 45  - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions.  
 46  - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user.
 47
 48- **Correlate with surrounding activity**  
 49  - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`.  
 50  - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity).
 51
 52
 53### False positive analysis
 54
 55- Onboarding or role transitions may legitimately add users to groups.  
 56- Automated Identity-Management pipelines may add many users to service groups; validate know
 57
 58### Response and remediation
 59
 60- **Containment**:
 61  - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys.
 62  - Temporarily restrict group policy changes while assessing blast radius.
 63- **Investigation and scoping**:
 64  - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole).
 65  - Confirm whether other users were added to the same group within the same window. 
 66- **Recovery and hardening**: 
 67  - Enforce least privilege by redesigning large-group membership. 
 68  - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. 
 69  - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns.
 70
 71### Additional information
 72[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
 73"""
 74references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html"]
 75risk_score = 21
 76rule_id = "333de828-8190-4cf5-8d7c-7575846f6fe0"
 77severity = "low"
 78tags = [
 79    "Domain: Cloud",
 80    "Data Source: AWS",
 81    "Data Source: Amazon Web Services",
 82    "Use Case: Identity and Access Audit",
 83    "Tactic: Credential Access",
 84    "Tactic: Persistence",
 85    "Resources: Investigation Guide",
 86]
 87timestamp_override = "event.ingested"
 88type = "query"
 89
 90query = '''
 91event.dataset: aws.cloudtrail and 
 92    event.provider: iam.amazonaws.com and 
 93    event.action: AddUserToGroup and 
 94    event.outcome: success
 95'''
 96
 97
 98[[rule.threat]]
 99framework = "MITRE ATT&CK"
100
101[rule.threat.tactic]
102id = "TA0006"
103name = "Credential Access"
104reference = "https://attack.mitre.org/tactics/TA0006/"
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1098"
109name = "Account Manipulation"
110reference = "https://attack.mitre.org/techniques/T1098/"
111
112
113[rule.threat.tactic]
114id = "TA0003"
115name = "Persistence"
116reference = "https://attack.mitre.org/tactics/TA0003/"
117
118[rule.investigation_fields]
119field_names = [
120    "@timestamp",
121    "user.name",
122    "user_agent.original",
123    "source.ip",
124    "aws.cloudtrail.user_identity.arn",
125    "aws.cloudtrail.user_identity.type",
126    "aws.cloudtrail.user_identity.access_key_id",
127    "user.target.name",
128    "event.action",
129    "event.outcome",
130    "cloud.account.id",
131    "cloud.region",
132    "aws.cloudtrail.request_parameters",
133]