AWS IAM Login Profile Added for Root

  1[metadata]
  2creation_date = "2024/12/02"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/13"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner.
 11
 12"""
 13from = "now-6m"
 14index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 15language = "eql"
 16license = "Elastic License v2"
 17name = "AWS IAM Login Profile Added for Root"
 18note = """## Triage and analysis
 19
 20> **Disclaimer**:
 21> 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.
 22
 23This rule detects when a console login profile is created for the AWS root account.  
 24A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled.
 25
 26### Possible investigation steps
 27
 28**Assess the timing and context of the event**
 29- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred.  
 30  - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`.  
 31  - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation.
 32
 33**Investigate event origin and session details**
 34- Review `source.ip` and `user_agent.original`:
 35  - Determine if the request originated from an expected network range, VPN endpoint, or geolocation.
 36  - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client).
 37- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used.
 38- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts.
 39
 40**Analyze the login profile creation**
 41- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`:
 42  - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse.
 43- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior.
 44
 45**Correlate related identity and access behavior**
 46- Search for additional IAM management activity:
 47  - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions.
 48  - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session.
 49- Review GuardDuty findings or any other detections referencing this account or IP around the same time period.
 50- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition.
 51
 52**Validate with account owner or authorized personnel**
 53- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery).
 54- Review any internal change-management or service ticketing systems for an approved request matching this activity.
 55
 56### False positive analysis
 57
 58Although rare, legitimate scenarios include:
 59- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows.  
 60- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate.  
 61- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials.
 62
 63For any potential false positive, verify that:
 64- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools.  
 65- The change was recorded during a maintenance window or known security operation.
 66
 67### Response and remediation
 68
 69> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation.
 70
 71**1. Containment**
 72- Delete the newly created root login profile if it was not authorized.  
 73- Rotate the root account password using AWS’s official password-reset workflow.  
 74- Revoke any active sessions, temporary credentials, or tokens associated with this event.  
 75- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account.  
 76- Check that no root access keys exist — if present, remove them immediately.
 77
 78**2. Investigation and scoping**
 79- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions.  
 80- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity.  
 81- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts.  
 82- Review whether any new IAM roles, users, or policies were created in proximity to this event.
 83
 84**3. Recovery and hardening**
 85- Reset the root password and distribute the new credentials securely to authorized custodians only.  
 86- Ensure MFA is enforced for all administrative and root-level access.  
 87- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions.  
 88- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity.  
 89- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed.
 90
 91**4. Post-incident actions**
 92- Notify AWS account owners and your security operations center of the incident.  
 93- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA).  
 94- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR).
 95
 96### Additional information
 97
 98- **AWS Incident Response Playbooks**  
 99  - [IRP-CredCompromise](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md) – Containment and recovery for suspected credential abuse.  
100- **AWS Customer Playbook Framework**  
101  - [Compromised_IAM_Credentials.md](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md) – Steps to contain, investigate, and recover from credential compromise.  
102- **AWS Documentation**  
103  - [CreateLoginProfile API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)  
104  - [Root User Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html)
105"""
106risk_score = 73
107rule_id = "c04be7e0-b0fc-11ef-a826-f661ea17fbce"
108severity = "high"
109tags = [
110    "Domain: Cloud",
111    "Data Source: AWS",
112    "Data Source: Amazon Web Services",
113    "Data Source: AWS IAM",
114    "Use Case: Identity and Access Audit",
115    "Tactic: Persistence",
116    "Resources: Investigation Guide",
117]
118timestamp_override = "event.ingested"
119type = "eql"
120
121query = '''
122any where event.dataset == "aws.cloudtrail"
123   and event.provider == "iam.amazonaws.com"
124   and event.action == "CreateLoginProfile"
125   and aws.cloudtrail.user_identity.type == "Root"
126   and event.outcome == "success"
127   and not stringContains(aws.cloudtrail.request_parameters, "userName=")
128'''
129[rule.investigation_fields]
130field_names = [
131    "@timestamp",
132    "user_agent.original",
133    "source.ip",
134    "aws.cloudtrail.user_identity.arn",
135    "aws.cloudtrail.user_identity.type",
136    "aws.cloudtrail.user_identity.access_key_id",
137    "event.action",
138    "event.outcome",
139    "cloud.account.id",
140    "cloud.region",
141    "aws.cloudtrail.request_parameters",
142    "aws.cloudtrail.response_elements"
143]
144
145[[rule.threat]]
146framework = "MITRE ATT&CK"
147[[rule.threat.technique]]
148id = "T1078"
149name = "Valid Accounts"
150reference = "https://attack.mitre.org/techniques/T1078/"
151[[rule.threat.technique.subtechnique]]
152id = "T1078.004"
153name = "Cloud Accounts"
154reference = "https://attack.mitre.org/techniques/T1078/004/"
155
156
157[[rule.threat.technique]]
158id = "T1098"
159name = "Account Manipulation"
160reference = "https://attack.mitre.org/techniques/T1098/"
161
162
163[rule.threat.tactic]
164id = "TA0003"
165name = "Persistence"
166reference = "https://attack.mitre.org/tactics/TA0003/"