AWS Management Console Root Login

  1[metadata]
  2creation_date = "2020/06/11"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/10"
  6
  7[rule]
  8author = ["Elastic"]
  9description = "Identifies a successful login to the AWS Management Console by the Root user."
 10false_positives = [
 11    """
 12    It's strongly recommended that the root user is not used for everyday tasks, including the administrative ones.
 13    Verify whether the IP address, location, and/or hostname should be logging in as root in your environment.
 14    Unfamiliar root logins should be investigated immediately. If known behavior is causing false positives, it can be exempted from the rule.
 15    """,
 16]
 17from = "now-6m"
 18index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 19language = "kuery"
 20license = "Elastic License v2"
 21name = "AWS Management Console Root Login"
 22note = """## Triage and analysis
 23
 24> **Disclaimer**:
 25> 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.
 26
 27### Investigating AWS Management Console Root Login
 28
 29The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See [Tasks that require the root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).
 30
 31This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`).
 32
 33#### Possible investigation steps
 34
 35- **Confirm legitimacy.**  
 36  Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions.
 37- **Review contextual event details.**  
 38  Examine the CloudTrail fields in the alert:
 39  - `source.ip` – does it match known corporate IPs or expected admin VPNs?  
 40  - `user_agent.original` – browser or automation?  
 41  - `geo fields` – consistent with normal operations?  
 42  - `@timestamp` – within a planned maintenance window?
 43- **Check for prior or subsequent root activity.**  
 44  Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse.
 45- **Correlate follow-on actions.**  
 46  Look for risky API calls immediately after the login, such as:
 47  - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`.  
 48  These actions may indicate persistence or cover-up attempts.
 49- **Cross-account verification.**  
 50  If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere.
 51
 52### False positive analysis
 53
 54- **Planned administrative actions.**  
 55  Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign.
 56- **Third-party managed account scenarios.**  
 57  Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation.
 58
 59### Response and remediation
 60
 61> The AWS Incident Response Playbooks classify root logins as **Priority-1 events** due to full-environment control. Follow these steps whether or not you have a dedicated IR team.
 62
 63**1. Immediate verification and containment**
 64- If the login was not authorized or cannot be confirmed quickly:  
 65  - Reset the root password using the AWS Management Console.  
 66  - Rotate or remove any root access keys (root keys should normally not exist).  
 67  - Ensure MFA is enabled and enforced on the root account.  
 68  - Notify your security operations or cloud governance team.
 69
 70**2. Evidence preservation**
 71- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login.  
 72  Store them in a restricted, immutable S3 evidence bucket.  
 73- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period.
 74
 75**3. Scope and investigation**
 76- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions.  
 77- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms.  
 78- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes.
 79
 80**4. Recovery and hardening**
 81- Confirm MFA is working and only the authorized owner can access the root credentials.  
 82- Store root credentials in an offline vault under dual-custody control.  
 83- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions.  
 84- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time.  
 85- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices.
 86
 87### Additional information
 88
 89- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks):** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures.  
 90- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs):** Reference “Account Access Investigation” for evidence handling and credential rotation steps.  
 91- **AWS Documentation:** [Tasks that require the root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).  
 92- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
 93
 94"""
 95references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
 96risk_score = 47
 97rule_id = "e2a67480-3b79-403d-96e3-fdd2992c50ef"
 98severity = "medium"
 99tags = [
100    "Domain: Cloud",
101    "Data Source: AWS",
102    "Data Source: Amazon Web Services",
103    "Data Source: AWS Sign-In",
104    "Use Case: Identity and Access Audit",
105    "Resources: Investigation Guide",
106    "Tactic: Initial Access",
107    "Tactic: Privilege Escalation",
108]
109timestamp_override = "event.ingested"
110type = "query"
111
112query = '''
113event.dataset:aws.cloudtrail and 
114event.provider:signin.amazonaws.com and 
115event.action:ConsoleLogin and 
116aws.cloudtrail.user_identity.type:Root and 
117event.outcome:success
118'''
119
120[rule.investigation_fields]
121field_names = [
122    "@timestamp",
123    "user_agent.original",
124    "source.ip",
125    "aws.cloudtrail.user_identity.arn",
126    "aws.cloudtrail.user_identity.type",
127    "event.action",
128    "event.outcome",
129    "aws.cloudtrail.console_login.additional_eventdata.mfa_used",
130    "cloud.account.id",
131    "cloud.region",
132    "aws.cloudtrail.response_elements"
133]
134
135[[rule.threat]]
136framework = "MITRE ATT&CK"
137[[rule.threat.technique]]
138id = "T1078"
139name = "Valid Accounts"
140reference = "https://attack.mitre.org/techniques/T1078/"
141[[rule.threat.technique.subtechnique]]
142id = "T1078.004"
143name = "Cloud Accounts"
144reference = "https://attack.mitre.org/techniques/T1078/004/"
145
146[rule.threat.tactic]
147id = "TA0001"
148name = "Initial Access"
149reference = "https://attack.mitre.org/tactics/TA0001/"
150[[rule.threat]]
151framework = "MITRE ATT&CK"
152[[rule.threat.technique]]
153id = "T1078"
154name = "Valid Accounts"
155reference = "https://attack.mitre.org/techniques/T1078/"
156[[rule.threat.technique.subtechnique]]
157id = "T1078.004"
158name = "Cloud Accounts"
159reference = "https://attack.mitre.org/techniques/T1078/004/"
160
161[rule.threat.tactic]
162id = "TA0004"
163name = "Privilege Escalation"
164reference = "https://attack.mitre.org/tactics/TA0004/"