[Rule Tuning][Deprecation] AWS Root Console Login Rules (#5201)

* [Rule Tuning][Deprecation] AWS Root Console Login Rules

Deprecate - AWS Root Login Without MFA
- Starting deprecation process for this rule. While root login without MFA should certainly be investigated, this rule overlaps with the broader AWS Successful Root Console login rule. Between the 2, the broader rule should remain since all succesful Root console login events should be investigated. Part of the investigation can include determining if MFA was or was not enabled.

Tuning - AWS Management Console Root Login
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted fields
- added Mitre subtechnique

Tuning - AWS Management Console Brute Force of Root User Identity
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted field (the only one available for threshold rule is the threshold field)

* adding AWS Sign-In tag

adding AWS Sign-In tag

Author: imays11

rules/integrations/aws/credential_access_root_console_failure_brute_force.toml

@@ -2,7 +2,7 @@
 creation_date = "2020/07/21"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/10/10"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,7 @@ false_positives = [
     positives.
     """,
 ]
-from = "now-20m"
+from = "now-6m"
 index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 language = "kuery"
 license = "Elastic License v2"
@@ -29,37 +29,81 @@ note = """## Triage and analysis
 
 ### Investigating AWS Management Console Brute Force of Root User Identity
 
-The AWS Management Console is a web-based interface for accessing and managing AWS services. The root user identity has unrestricted access, making it a prime target for adversaries seeking unauthorized control. Attackers may attempt brute force attacks to guess the root password. The detection rule identifies such attempts by monitoring failed login events specifically for the root user, flagging potential credential access threats.
+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.
 
-### Possible investigation steps
+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.
 
-- Review the CloudTrail logs for the specific time frame of the failed login attempts to identify patterns or anomalies in the source IP addresses or user agents.
-- Check the geographical location of the IP addresses involved in the failed login attempts to determine if they are consistent with known or expected locations for legitimate access.
-- Investigate any successful login attempts from the same IP addresses or user agents to assess if the brute force attempt was successful at any point.
-- Analyze the frequency and timing of the failed login attempts to determine if they align with typical brute force attack patterns, such as rapid or sequential attempts.
-- Correlate the failed login events with other security events or alerts in the AWS environment to identify any concurrent suspicious activities that may indicate a broader attack campaign.
-- Review AWS CloudTrail logs for any changes in IAM policies or unusual activity following the failed login attempts to ensure no unauthorized access was gained.
+#### Possible investigation steps
 
-### False positive analysis
+- **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 fields` and `@timestamp` for each failure.  
+  - Look for patterns such as distributed sources or repeated retries at consistent intervals.  
+  - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent.
 
-- Legitimate users may forget their password and repeatedly attempt to log in, triggering the rule. To manage this, monitor for patterns of failed logins followed by successful ones and consider excluding these from alerts if they originate from known IP addresses.
-- Automated scripts or applications using outdated credentials can cause repeated failed login attempts. Identify and update these credentials or exclude the associated IP addresses from the rule.
-- Security testing or penetration testing activities might simulate brute force attacks. Coordinate with your security team to whitelist IP addresses or timeframes associated with these activities to prevent false positives.
-- Shared accounts or environments where multiple users attempt to access the root account can lead to multiple failed attempts. Implement stricter access controls and consider excluding known internal IP ranges from the rule.
+- **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.region` and `geo fields` and compare with expected login locations for your organization.
 
-### Response and remediation
+- **Check for related activity.**  
+  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.
+
+- **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.
 
-- Immediately disable the root user account to prevent further unauthorized access attempts. This can be done through the AWS Management Console by navigating to the IAM section and selecting the root user account.
-- Review the CloudTrail logs to identify the source IP addresses of the failed login attempts. Block these IP addresses using AWS security groups or network ACLs to prevent further access attempts from these locations.
-- Reset the root user password and ensure it is strong and unique. Use a password manager to generate and store the new password securely.
-- Enable multi-factor authentication (MFA) for the root user account to add an additional layer of security. This can be configured in the AWS Management Console under the IAM section.
-- Conduct a thorough audit of recent account activity to ensure no unauthorized changes have been made. Pay special attention to IAM roles, policies, and permissions.
-- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Provide them with details of the attempted breach and actions taken.
-- Implement additional monitoring and alerting for unusual login patterns or failed login attempts to the root account to enhance early detection of similar threats in the future.
+- **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
 
-## Setup
+- **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.
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+### 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 any `ConsoleLogin` events from the same IP or user agent show `event.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 `ConsoleLogin` events 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 `ConsoleLogin` events 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 `ConsoleLogin` failures from the root user exceeding expected baselines.  
+- Store root credentials offline with dual-custody and document controlled access procedures.
+
+### Additional information
+
+- **[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.  
+- **[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.  
+- **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).  
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
+"""
 references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
 risk_score = 73
 rule_id = "4d50a94f-2844-43fa-8395-6afbd5e1c5ef"
@@ -68,6 +112,7 @@ tags = [
     "Domain: Cloud",
     "Data Source: AWS",
     "Data Source: Amazon Web Services",
+    "Data Source: AWS Sign-In",
     "Use Case: Identity and Access Audit",
     "Tactic: Credential Access",
     "Resources: Investigation Guide",
@@ -76,9 +121,17 @@ timestamp_override = "event.ingested"
 type = "threshold"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:failure
+event.dataset:aws.cloudtrail and 
+event.provider:signin.amazonaws.com and 
+event.action:ConsoleLogin and 
+aws.cloudtrail.user_identity.type:Root and 
+event.outcome:failure
 '''
 
+[rule.investigation_fields]
+field_names = [
+    "cloud.account.id",
+]
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"