AWS IAM Create User via Assumed Role on EC2 Instance
Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles—particularly from within EC2 instances—may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/11/04"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2024/11/07"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2
11instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM
12users through these roles—particularly from within EC2 instances—may indicate a compromised instance. Adversaries might
13exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions.
14"""
15false_positives = [
16 """
17 Assumed roles may be used by legitimate automated systems to create IAM users for specific workflows. Verify if this
18 event aligns with known automation activities. If the action is routine for specific roles or user agents (e.g.,
19 `aws-cli`, `boto3`), consider adding those roles or user agents to a monitored exception list for streamlined
20 review.
21 """,
22]
23from = "now-9m"
24index = ["filebeat-*", "logs-aws.cloudtrail-*"]
25language = "kuery"
26license = "Elastic License v2"
27name = "AWS IAM Create User via Assumed Role on EC2 Instance"
28note = """## Triage and Analysis
29
30### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
31
32This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access.
33
34#### Possible Investigation Steps
35
36- **Identify the Assumed Role and Initiating Instance**:
37 - **Role and Instance**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the specific EC2 instance and role used for this action (e.g., `arn:aws:sts::[account-id]:assumed-role/[role-name]/[instance-id]`). Verify if this behavior aligns with expected usage or represents an anomaly.
38 - **Session Context**: Check the `session_issuer` fields in `aws.cloudtrail.user_identity.session_context` for details about the role assumed by the instance, along with `mfa_authenticated` to determine if Multi-Factor Authentication (MFA) was used.
39
40- **Analyze the Target IAM User**:
41 - **New User Details**: Inspect `aws.cloudtrail.flattened.request_parameters.userName` to see the username that was created. Look at `aws.cloudtrail.flattened.response_elements.user.userName` for confirmation of successful user creation, and validate if the user is expected or authorized.
42 - **Review Creation Time and Context**: Compare the creation time (`@timestamp`) of the user with other activities from the same instance and role to assess if this creation was part of a larger chain of actions.
43
44- **Check User Agent and Tooling**:
45 - **User Agent Analysis**: Review `user_agent.original` to see if AWS CLI, SDK, or other tooling was used for this request. Identifiers such as `aws-cli`, `boto3`, or similar SDK names can indicate the method used, which may differentiate automation from interactive actions.
46 - **Source IP and Location**: Use the `source.address` and `source.geo` fields to identify the IP address and geographic location of the event. Verify if this aligns with expected access patterns for your environment.
47
48- **Evaluate for Persistence Indicators**:
49 - **Role Permissions**: Check the permissions associated with the assumed role (`arn:aws:iam::[account-id]:role/[role-name]`) to determine if creating IAM users is a legitimate activity for this role.
50 - **Automated Role Patterns**: If the assumed role or instance typically creates IAM users for automation purposes, validate this action against historical records to confirm if the event is consistent with normal patterns.
51
52- **Review Related CloudTrail Events**:
53 - **Additional IAM Actions**: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially `CreateAccessKey` or `AttachUserPolicy` actions. These could signal further attempts to empower or utilize the newly created user.
54 - **Correlate with Other Suspicious Activities**: Determine if other roles or instances recently initiated similar unusual actions, such as privilege escalations or data access.
55
56### False Positive Analysis
57
58- **Expected Automation**: Assumed roles may be used by legitimate automated systems that create users for specific workflows. Confirm if this event aligns with known automation activities.
59- **User Agent and Role Exceptions**: If this action is routine for specific roles or user agents (e.g., `aws-cli`, `boto3`), consider adding those roles or user agents to a monitored exception list for streamlined review.
60
61### Response and Remediation
62
63- **Immediate Access Review**: If user creation was unauthorized, restrict the assumed role’s permissions to prevent further user creation.
64- **Delete Unauthorized Users**: Confirm and remove any unauthorized IAM users, adjusting IAM policies to reduce similar risks.
65- **Enhance Monitoring and Alerts**: Enable enhanced logging or real-time alerts for this role or instance to detect further unauthorized access attempts.
66- **Policy Update**: Consider updating IAM policies associated with roles on EC2 instances to limit sensitive actions like IAM user creation.
67
68### Additional Information
69
70For further guidance on managing IAM roles and permissions within AWS environments, refer to the [AWS IAM documentation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html) and AWS best practices for security.
71"""
72references = [
73 "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html",
74 "https://www.dionach.com/en-us/breaking-into-the-cloud-red-team-tactics-for-aws-compromise/",
75]
76risk_score = 47
77rule_id = "f7a1c536-9ac0-11ef-9911-f661ea17fbcd"
78severity = "medium"
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]
87timestamp_override = "event.ingested"
88type = "new_terms"
89
90query = '''
91event.dataset: "aws.cloudtrail"
92 and event.provider: "iam.amazonaws.com"
93 and event.action: "CreateUser"
94 and event.outcome: "success"
95 and aws.cloudtrail.user_identity.type: "AssumedRole"
96 and aws.cloudtrail.user_identity.arn: *i-*
97'''
98
99[rule.investigation_fields]
100field_names = [
101 "@timestamp",
102 "user.name",
103 "source.address",
104 "aws.cloudtrail.user_identity.arn",
105 "aws.cloudtrail.user_identity.type",
106 "user_agent.original",
107 "event.action",
108 "event.outcome",
109 "cloud.region",
110 "aws.cloudtrail.request_parameters",
111 "aws.cloudtrail.response_elements"
112]
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116[[rule.threat.technique]]
117id = "T1136"
118name = "Create Account"
119reference = "https://attack.mitre.org/techniques/T1136/"
120[[rule.threat.technique.subtechnique]]
121id = "T1136.003"
122name = "Cloud Account"
123reference = "https://attack.mitre.org/techniques/T1136/003/"
124
125
126
127[rule.threat.tactic]
128id = "TA0003"
129name = "Persistence"
130reference = "https://attack.mitre.org/tactics/TA0003/"
131
132[rule.new_terms]
133field = "new_terms_fields"
134value = ["aws.cloudtrail.user_identity.arn"]
135[[rule.new_terms.history_window_start]]
136field = "history_window_start"
137value = "now-14d"
Triage and Analysis
Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance
This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access.
Possible Investigation Steps
-
Identify the Assumed Role and Initiating Instance:
- Role and Instance: Examine the
aws.cloudtrail.user_identity.arn
field to determine the specific EC2 instance and role used for this action (e.g.,arn:aws:sts::[account-id]:assumed-role/[role-name]/[instance-id]
). Verify if this behavior aligns with expected usage or represents an anomaly. - Session Context: Check the
session_issuer
fields inaws.cloudtrail.user_identity.session_context
for details about the role assumed by the instance, along withmfa_authenticated
to determine if Multi-Factor Authentication (MFA) was used.
- Role and Instance: Examine the
-
Analyze the Target IAM User:
- New User Details: Inspect
aws.cloudtrail.flattened.request_parameters.userName
to see the username that was created. Look ataws.cloudtrail.flattened.response_elements.user.userName
for confirmation of successful user creation, and validate if the user is expected or authorized. - Review Creation Time and Context: Compare the creation time (
@timestamp
) of the user with other activities from the same instance and role to assess if this creation was part of a larger chain of actions.
- New User Details: Inspect
-
Check User Agent and Tooling:
- User Agent Analysis: Review
user_agent.original
to see if AWS CLI, SDK, or other tooling was used for this request. Identifiers such asaws-cli
,boto3
, or similar SDK names can indicate the method used, which may differentiate automation from interactive actions. - Source IP and Location: Use the
source.address
andsource.geo
fields to identify the IP address and geographic location of the event. Verify if this aligns with expected access patterns for your environment.
- User Agent Analysis: Review
-
Evaluate for Persistence Indicators:
- Role Permissions: Check the permissions associated with the assumed role (
arn:aws:iam::[account-id]:role/[role-name]
) to determine if creating IAM users is a legitimate activity for this role. - Automated Role Patterns: If the assumed role or instance typically creates IAM users for automation purposes, validate this action against historical records to confirm if the event is consistent with normal patterns.
- Role Permissions: Check the permissions associated with the assumed role (
-
Review Related CloudTrail Events:
- Additional IAM Actions: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially
CreateAccessKey
orAttachUserPolicy
actions. These could signal further attempts to empower or utilize the newly created user. - Correlate with Other Suspicious Activities: Determine if other roles or instances recently initiated similar unusual actions, such as privilege escalations or data access.
- Additional IAM Actions: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially
False Positive Analysis
- Expected Automation: Assumed roles may be used by legitimate automated systems that create users for specific workflows. Confirm if this event aligns with known automation activities.
- User Agent and Role Exceptions: If this action is routine for specific roles or user agents (e.g.,
aws-cli
,boto3
), consider adding those roles or user agents to a monitored exception list for streamlined review.
Response and Remediation
- Immediate Access Review: If user creation was unauthorized, restrict the assumed role’s permissions to prevent further user creation.
- Delete Unauthorized Users: Confirm and remove any unauthorized IAM users, adjusting IAM policies to reduce similar risks.
- Enhance Monitoring and Alerts: Enable enhanced logging or real-time alerts for this role or instance to detect further unauthorized access attempts.
- Policy Update: Consider updating IAM policies associated with roles on EC2 instances to limit sensitive actions like IAM user creation.
Additional Information
For further guidance on managing IAM roles and permissions within AWS environments, refer to the AWS IAM documentation and AWS best practices for security.
References
Related rules
- AWS IAM AdministratorAccess Policy Attached to User
- AWS IAM AdministratorAccess Policy Attached to Group
- AWS IAM AdministratorAccess Policy Attached to Role
- AWS IAM Roles Anywhere Profile Creation
- AWS IAM Roles Anywhere Trust Anchor Created with External CA