AWS IAM Group Creation
Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/06/05"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/01/16"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple
11users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain
12credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach
13admin-level policies to the group and quietly add users or roles to inherit those privileges.
14"""
15false_positives = [
16 """
17 A group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or
18 hostname should be making changes in your environment. Group creations by unfamiliar users or hosts should be
19 investigated. If known behavior is causing false positives, it can be exempted from the rule.
20 """,
21]
22from = "now-6m"
23index = ["filebeat-*", "logs-aws.cloudtrail-*"]
24language = "kuery"
25license = "Elastic License v2"
26name = "AWS IAM Group Creation"
27note = """## Triage and analysis
28
29### Investigating AWS IAM Group Creation
30
31AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.
32
33#### Possible investigation steps
34
35- **Identify the actor and context**
36 - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation.
37 - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.
38
39- **Examine the group details**
40 - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).
41 - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
42 - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).
43 - AddUserToGroup (who was added and when?).
44 - Use GetGroup to enumerate current group membership and attached policies during triage.
45
46- **Correlate with broader activity**
47 - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role.
48 - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes)
49
50### False positive analysis
51
52- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.
53- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.
54
55### Response and remediation:
56
57- **Containment**:
58 - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
59 - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).
60
61- **Investigation and scoping**:
62 - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges.
63 - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h.
64
65- **Recovery and hardening**:
66 - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
67 - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege).
68
69### Additional information
70[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
71"""
72references = [
73 "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html",
74 "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html",
75]
76risk_score = 21
77rule_id = "169f3a93-efc7-4df2-94d6-0d9438c310d1"
78severity = "low"
79tags = [
80 "Domain: Cloud",
81 "Data Source: AWS",
82 "Data Source: Amazon Web Services",
83 "Data Source: AWS IAM",
84 "Use Case: Identity and Access Audit",
85 "Tactic: Persistence",
86 "Resources: Investigation Guide",
87]
88timestamp_override = "event.ingested"
89type = "query"
90
91query = '''
92event.dataset: aws.cloudtrail and
93 event.provider: iam.amazonaws.com and
94 event.action: CreateGroup and
95 event.outcome: success
96'''
97
98
99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1136"
103name = "Create Account"
104reference = "https://attack.mitre.org/techniques/T1136/"
105[[rule.threat.technique.subtechnique]]
106id = "T1136.003"
107name = "Cloud Account"
108reference = "https://attack.mitre.org/techniques/T1136/003/"
109
110
111
112[rule.threat.tactic]
113id = "TA0003"
114name = "Persistence"
115reference = "https://attack.mitre.org/tactics/TA0003/"
116
117[rule.investigation_fields]
118field_names = [
119 "@timestamp",
120 "user.name",
121 "user_agent.original",
122 "source.ip",
123 "aws.cloudtrail.user_identity.arn",
124 "aws.cloudtrail.user_identity.type",
125 "aws.cloudtrail.user_identity.access_key_id",
126 "event.action",
127 "event.outcome",
128 "cloud.account.id",
129 "cloud.region",
130 "aws.cloudtrail.request_parameters",
131 "aws.cloudtrail.response_elements",
132]
Triage and analysis
Investigating AWS IAM Group Creation
AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on CreateGroup. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.
Possible investigation steps
-
Identify the actor and context
- Check
aws.cloudtrail.user_identity.arn,aws.cloudtrail.user_identity.access_key_idto determine who performed the group creation. - Review
source.ip,user_agent.original,cloud.account.id,cloud.regionfor unusual network, client, or region usage.
- Check
-
Examine the group details
- From
aws.cloudtrail.response_elements, extractgroupNameandpath(e.g., /service/, /dev/). - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
- AttachGroupPolicy (especially AdministratorAccess or broad s3:, iam:).
- AddUserToGroup (who was added and when?).
- Use GetGroup to enumerate current group membership and attached policies during triage.
- From
-
Correlate with broader activity
- Look for prior suspicious actions by the same user:
AssumeRole,CreateAccessKey, new IAM user/role. - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes)
- Look for prior suspicious actions by the same user:
False positive analysis
- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.
- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.
Response and remediation:
-
Containment:
- If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
- Place a change freeze on the newly created group (block
AttachGroupPolicy/AddUserToGroupvia SCP/permissions boundary until review completes).
-
Investigation and scoping:
- Use
GetGroup,ListAttachedGroupPolicies,ListUsersInGroupto enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. - Hunt for same-actor
AttachGroupPolicy/AddUserToGroupevents across the last 24–48h.
- Use
-
Recovery and hardening:
- Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
- Restrict who can call
iam:CreateGroup,iam:AttachGroupPolicy, andiam:AddUserToGroup(least privilege).
Additional information
References
Related rules
- AWS IAM AdministratorAccess Policy Attached to Group
- AWS IAM AdministratorAccess Policy Attached to Role
- AWS IAM AdministratorAccess Policy Attached to User
- AWS IAM Login Profile Added for Root
- AWS IAM Roles Anywhere Profile Creation