security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
* [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
This commit is contained in:
Isai
2025-10-15 14:16:02 -04:00
committed by GitHub
parent 83e36854f0
commit 00ed573623
3 changed files with 172 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/aws/credential_access_root_console_failure_brute_force.toml
+77 -24
View File
@@ -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
- **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.
- **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.
- **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.
- **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
- 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.
- **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
- 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.
> 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.
## Setup
**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.
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
**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"
rules/integrations/aws/initial_access_console_login_root.toml
+92 -34
View File
@@ -2,7 +2,7 @@
creation_date = "2020/06/11"
integration = ["aws"]
maturity = "production"
updated_date = "2024/05/21"
updated_date = "2025/10/10"
[rule]
author = ["Elastic"]
@@ -11,54 +11,87 @@ false_positives = [
"""
It's strongly recommended that the root user is not used for everyday tasks, including the administrative ones.
Verify whether the IP address, location, and/or hostname should be logging in as root in your environment.
Unfamiliar root logins should be investigated immediately. If known behavior is causing false positives, it can be
exempted from the rule.
Unfamiliar root logins should be investigated immediately. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-60m"
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "AWS Management Console Root Login"
note = """## 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 Root Login
The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. AWS provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).
The 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).
This rule looks for attempts to log in to the AWS Management Console as the root user.
This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`).
#### Possible investigation steps
- Investigate other alerts associated with the user account during the past 48 hours.
- Examine whether this activity is common in the environment by looking for past occurrences on your logs.
- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user?
- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours.
- Contact the account owner and confirm whether they are aware of this activity.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers,
services, and data accessed by the account in the last 24 hours.
- **Confirm legitimacy.**
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.
- **Review contextual event details.**
Examine the CloudTrail fields in the alert:
- `source.ip` – does it match known corporate IPs or expected admin VPNs?
- `user_agent.original` – browser or automation?
- `geo fields` – consistent with normal operations?
- `@timestamp` – within a planned maintenance window?
- **Check for prior or subsequent root activity.**
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.
- **Correlate follow-on actions.**
Look for risky API calls immediately after the login, such as:
- `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`.
These actions may indicate persistence or cover-up attempts.
- **Cross-account verification.**
If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere.
### False positive analysis
- The alert can be dismissed if this operation is done under change management and approved according to the organization's policy for performing a task that needs this privilege level.
- **Planned administrative actions.**
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.
- **Third-party managed account scenarios.**
Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
- Identify the account role in the cloud environment.
- Identify the services or servers involved criticality.
- Work with your IT team to identify and minimize the impact on users.
- Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
- Identify if there are any regulatory or legal ramifications related to this activity.
- Configure multi-factor authentication for the user.
- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
> 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.
## Setup
**1. Immediate verification and containment**
- If the login was not authorized or cannot be confirmed quickly:
- Reset the root password using the AWS Management Console.
- Rotate or remove any root access keys (root keys should normally not exist).
- Ensure MFA is enabled and enforced on the root account.
- Notify your security operations or cloud governance team.
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
**2. Evidence preservation**
- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login.
Store them in a restricted, immutable S3 evidence bucket.
- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period.
**3. Scope and investigation**
- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions.
- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms.
- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes.
**4. Recovery and hardening**
- Confirm MFA is working and only the authorized owner can access the root credentials.
- Store root credentials in an offline vault under dual-custody control.
- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions.
- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time.
- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices.
### Additional information
- **[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.
- **[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.
- **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 = 47
rule_id = "e2a67480-3b79-403d-96e3-fdd2992c50ef"
@@ -67,18 +100,37 @@ tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS Signin",
"Data Source: AWS Sign-In",
"Use Case: Identity and Access Audit",
"Resources: Investigation Guide",
"Tactic: Initial Access",
"Tactic: Privilege Escalation",
]
timestamp_override = "event.ingested"
type = "query"
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:success
event.dataset:aws.cloudtrail and
event.provider:signin.amazonaws.com and
event.action:ConsoleLogin and
aws.cloudtrail.user_identity.type:Root and
event.outcome:success
'''
[rule.investigation_fields]
field_names = [
"@timestamp",
"user_agent.original",
"source.ip",
"aws.cloudtrail.user_identity.arn",
"aws.cloudtrail.user_identity.type",
"event.action",
"event.outcome",
"aws.cloudtrail.console_login.additional_eventdata.mfa_used",
"cloud.account.id",
"cloud.region",
"aws.cloudtrail.response_elements"
]
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -86,7 +138,10 @@ framework = "MITRE ATT&CK"
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"
[rule.threat.tactic]
id = "TA0001"
@@ -98,10 +153,13 @@ framework = "MITRE ATT&CK"
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
rules/integrations/aws/privilege_escalation_root_login_without_mfa.toml
+3 -3
View File
@@ -2,7 +2,7 @@
creation_date = "2020/07/06"
integration = ["aws"]
maturity = "production"
updated_date = "2024/05/21"
updated_date = "2025/10/10"
[rule]
author = ["Elastic"]
@@ -21,10 +21,10 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "AWS Root Login Without MFA"
name = "Deprecated - AWS Root Login Without MFA"
note = """## Triage and analysis
### Investigating AWS Root Login Without MFA
### Investigating Deprecated - AWS Root Login Without MFA
Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password, as well as for an authentication code from their AWS MFA device. Taken together, these multiple factors provide increased security for your AWS account settings and resources.