AWS Management Console Brute Force of Root User Identity
Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/07/21"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/10/10"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An
11adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services
12and resources for the AWS account.
13"""
14false_positives = [
15 """
16 Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
17 positives.
18 """,
19]
20from = "now-6m"
21index = ["filebeat-*", "logs-aws.cloudtrail-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "AWS Management Console Brute Force of Root User Identity"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating AWS Management Console Brute Force of Root User Identity
31
32The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user.
33
34This rule uses a threshold rule that detects a high number of failed `ConsoleLogin` events (`event.outcom: failure` with `userIdentity.type: Root`) within a short timeframe from the same IP address or user agent.
35Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert.
36
37#### Possible investigation steps
38
39- **Review in Timeline.**
40 Open the alert and *Investigate in timeline* to view the individual CloudTrail events contributing to the threshold alert. Review:
41 - `source.ip`, `user_agent.original`, `geo fields` and `@timestamp` for each failure.
42 - Look for patterns such as distributed sources or repeated retries at consistent intervals.
43 - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent.
44
45- **Assess IP reputation and geolocation.**
46 Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations.
47 - Correlate against `cloud.region` and `geo fields` and compare with expected login locations for your organization.
48
49- **Check for related activity.**
50 Review CloudTrail for other API calls from the same source IP (for example, `GetSessionToken`, `AssumeRole`, or `ListUsers`) that may indicate scripted credential testing or discovery.
51
52- **Correlate with GuardDuty findings.**
53 GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe.
54
55- **Determine business context.**
56 Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious.
57
58### False positive analysis
59
60- **Forgotten or mistyped credentials.**
61 Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after.
62- **Automation or scanners.**
63 Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule.
64- **Planned penetration testing.**
65 Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules.
66
67### Response and remediation
68
69> The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events.
70> Follow these steps whether or not your organization has a formal IR team.
71
72**1. Immediate containment**
73- **Check for success.**
74 After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`.
75 - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide.
76- **Rotate the root password.**
77 Use AWS’s password reset function to set a strong, unique password stored in an offline vault.
78- **Enable or verify Multi-Factor Authentication (MFA)** on the root account. If MFA was already configured, review the device registration for changes or suspicious resets.
79- **Block offending IPs or networks.**
80 Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts.
81- **Alert internal teams.**
82 Notify your security operations or cloud governance teams of the brute force pattern and actions taken.
83
84**2. Evidence preservation**
85- Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket.
86- Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis.
87
88**3. Scoping and investigation**
89- Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs.
90- Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts.
91- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern.
92
93**4. Recovery and hardening**
94- Confirm MFA is enabled and enforced on the root account.
95- Remove any root access keys (none should exist under normal security posture).
96- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions.
97- Set up real-time alerts for any future `ConsoleLogin` failures from the root user exceeding expected baselines.
98- Store root credentials offline with dual-custody and document controlled access procedures.
99
100### Additional information
101
102- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks):** See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance.
103- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs):** Reference runbooks for failed-login response, evidence preservation, and MFA enforcement.
104- **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).
105- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
106"""
107references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
108risk_score = 73
109rule_id = "4d50a94f-2844-43fa-8395-6afbd5e1c5ef"
110severity = "high"
111tags = [
112 "Domain: Cloud",
113 "Data Source: AWS",
114 "Data Source: Amazon Web Services",
115 "Data Source: AWS Sign-In",
116 "Use Case: Identity and Access Audit",
117 "Tactic: Credential Access",
118 "Resources: Investigation Guide",
119]
120timestamp_override = "event.ingested"
121type = "threshold"
122
123query = '''
124event.dataset:aws.cloudtrail and
125event.provider:signin.amazonaws.com and
126event.action:ConsoleLogin and
127aws.cloudtrail.user_identity.type:Root and
128event.outcome:failure
129'''
130
131[rule.investigation_fields]
132field_names = [
133 "cloud.account.id",
134]
135
136[[rule.threat]]
137framework = "MITRE ATT&CK"
138[[rule.threat.technique]]
139id = "T1110"
140name = "Brute Force"
141reference = "https://attack.mitre.org/techniques/T1110/"
142
143
144[rule.threat.tactic]
145id = "TA0006"
146name = "Credential Access"
147reference = "https://attack.mitre.org/tactics/TA0006/"
148
149[rule.threshold]
150field = ["cloud.account.id"]
151value = 10
Triage and analysis
Disclaimer: 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.
Investigating AWS Management Console Brute Force of Root User Identity
The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user.
This rule uses a threshold rule that detects a high number of failed ConsoleLogin events (event.outcom: failure with userIdentity.type: Root) within a short timeframe from the same IP address or user agent.
Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert.
Possible investigation steps
-
Review in Timeline.
Open the alert and Investigate in timeline to view the individual CloudTrail events contributing to the threshold alert. Review:source.ip,user_agent.original,geo fieldsand@timestampfor each failure.- Look for patterns such as distributed sources or repeated retries at consistent intervals.
- Look for any corresponding successful
ConsoleLoginevents around the same timeframe from the same IP or agent.
-
Assess IP reputation and geolocation.
Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations.- Correlate against
cloud.regionandgeo fieldsand compare with expected login locations for your organization.
- Correlate against
-
Check for related activity.
Review CloudTrail for other API calls from the same source IP (for example,GetSessionToken,AssumeRole, orListUsers) that may indicate scripted credential testing or discovery. -
Correlate with GuardDuty findings.
GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe. -
Determine business context.
Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious.
False positive analysis
- Forgotten or mistyped credentials.
Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after. - Automation or scanners.
Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule. - Planned penetration testing.
Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules.
Response and remediation
The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events.
Follow these steps whether or not your organization has a formal IR team.
1. Immediate containment
- Check for success.
After pivoting to Timeline, confirm whether anyConsoleLoginevents from the same IP or user agent showevent.oucome: success.- If a successful login occurred, immediately follow the AWS Management Console Root Login rule investigation guide.
- Rotate the root password.
Use AWS’s password reset function to set a strong, unique password stored in an offline vault. - Enable or verify Multi-Factor Authentication (MFA) on the root account. If MFA was already configured, review the device registration for changes or suspicious resets.
- Block offending IPs or networks.
Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts. - Alert internal teams.
Notify your security operations or cloud governance teams of the brute force pattern and actions taken.
2. Evidence preservation
- Export all failed
ConsoleLoginevents visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. - Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis.
3. Scoping and investigation
- Query CloudTrail across other AWS accounts and regions for additional failed or successful
ConsoleLoginevents from the same IPs. - Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts.
- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern.
4. Recovery and hardening
- Confirm MFA is enabled and enforced on the root account.
- Remove any root access keys (none should exist under normal security posture).
- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions.
- Set up real-time alerts for any future
ConsoleLoginfailures from the root user exceeding expected baselines. - Store root credentials offline with dual-custody and document controlled access procedures.
Additional information
- AWS IR Playbooks: See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance.
- AWS Customer Playbook Framework: Reference runbooks for failed-login response, evidence preservation, and MFA enforcement.
- AWS Documentation: Tasks that require the root user.
- Security Best Practices: AWS Knowledge Center – Security Best Practices.
References
Related rules
- AWS Management Console Root Login
- AWS Sign-In Root Password Recovery Requested
- AWS EC2 Unauthorized Admin Credential Fetch via Assumed Role
- AWS IAM Brute Force of Assume Role Policy
- Deprecated - AWS Root Login Without MFA