[Rule Tunings] AWS Root Access Rules

rules/integrations/aws/initial_access_password_recovery.toml

@@ -2,74 +2,98 @@
 creation_date = "2020/07/02"
 integration = ["aws"]
 maturity = "production"
-updated_date = "2025/01/15"
+updated_date = "2025/10/13"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies AWS IAM password recovery requests. An adversary may attempt to gain unauthorized AWS access by abusing
-password recovery mechanisms.
+Identifies a password recovery request for the AWS account root user.
+In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. 
+This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy.
 """
-false_positives = [
-    """
-    Verify whether the user identity, user agent, and/or hostname should be requesting changes in your environment.
-    Password reset attempts from unfamiliar users should be investigated. 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 IAM Password Recovery Requested"
+name = "AWS Sign-In Root Password Recovery Requested"
 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 IAM Password Recovery Requested
+### Investigating AWS Sign-In Root Password Recovery Requested
 
-AWS Identity and Access Management (IAM) facilitates secure access control to AWS resources. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors successful password recovery requests within AWS CloudTrail logs, focusing on initial access tactics, to identify potential misuse and unauthorized access attempts.
+In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access.
 
 ### Possible investigation steps
 
-- Review the AWS CloudTrail logs for the specific event.action:PasswordRecoveryRequested to identify the user account involved in the password recovery request.
-- Check the event.provider:signin.amazonaws.com logs to determine the source IP address and geolocation associated with the password recovery request to assess if it aligns with known user activity.
-- Investigate the event.outcome:success logs to confirm if the password recovery was completed and if there were any subsequent successful logins from the same or different IP addresses.
-- Analyze the user account's recent activity and permissions to identify any unusual or unauthorized actions that may indicate compromise.
-- Cross-reference the event with any other security alerts or incidents involving the same user account to identify potential patterns or coordinated attacks.
-- Contact the user associated with the password recovery request to verify if they initiated the request and to ensure their account security.
+- **Verify the event details.**  
+  Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated.
+- **Confirm legitimacy.**  
+  Contact the account owner or credential custodian to verify whether they initiated the password recovery.  
+  AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this.
+- **Check CloudTrail for related events.**  
+  Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request.
+- **Assess IP reputation and location.**  
+  Validate whether the `source.ip` aligns with known admin networks or expected geographies.  
+  Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents.
+- **Correlate with other alerts.**  
+  Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe.
 
 ### False positive analysis
 
-- Routine password recovery by legitimate users can trigger this rule. To manage this, identify users who frequently request password recovery and consider adding them to an exception list if their behavior is verified as non-threatening.
-- Automated password recovery processes used by internal IT support or helpdesk teams may also cause false positives. Coordinate with these teams to understand their workflows and exclude their activities from triggering alerts.
-- Users with known issues accessing their accounts due to technical problems might repeatedly request password recovery. Monitor these cases and exclude them once confirmed as non-malicious.
-- Scheduled security drills or training exercises that involve password recovery can generate alerts. Ensure these activities are documented and excluded from the rule to prevent unnecessary alerts.
+- **Expected maintenance activity.**  
+  If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed.  
+- **Testing or account verification.**  
+  Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation.
 
 ### Response and remediation
 
-- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request. Ensure they initiated the recovery process and are aware of the request.
-- Temporarily disable the affected IAM user account to prevent any unauthorized access until the situation is fully assessed and resolved.
-- Review AWS CloudTrail logs for any additional suspicious activities associated with the IAM user account, such as unusual login attempts or changes to permissions, to identify potential compromise.
-- If unauthorized access is confirmed, reset the IAM user's password and any associated access keys. Ensure the new credentials are communicated securely to the legitimate user.
-- Implement multi-factor authentication (MFA) for the affected IAM user account to enhance security and prevent future unauthorized access attempts.
-- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or resources have been compromised.
-- Update and enhance monitoring rules to detect similar unauthorized password recovery attempts in the future, ensuring timely alerts and responses.
-
-## Setup
+**1. Immediate actions**
+- **If confirmed legitimate:**  
+  - Ensure that MFA is enabled and operational for the root account.  
+  - Encourage rotation of the root password if not recently updated.  
+- **If unconfirmed or suspicious:**  
+  - Immediately reset the root password using the legitimate AWS recovery email link.  
+  - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA).  
+  - Check for new successful root logins or unexpected IAM changes since the recovery attempt.  
+
+**2. Evidence preservation**
+- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes).  
+- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours.  
+- Store this evidence in a restricted S3 bucket with Object Lock enabled.
+
+**3. Scoping and investigation**
+- Review all root-level activities within the past 24–48 hours.  
+  Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`.  
+- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications.
+
+**4. Recovery and hardening**
+- Confirm MFA is enforced on the root account.  
+- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active).  
+- Secure the associated email account (password reset notifications are sent there).  
+- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions.  
+- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process.
+
+### Additional information
+
+- **AWS Incident Response Playbooks:**    
+  and [`IRP-Credential-Compromise.md`](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md) for procedures related to root account credential recovery and unauthorized access attempts.  
+- **AWS Customer Playbook Framework:**  
+  See [`Compromised_IAM_Credentials.md`](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md) for guidance on containment, evidence collection, and recovery validation.  
+- **AWS Documentation:** [AWS account root user best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html).  
+- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  
+"""
 
-The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
-references = ["https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
-risk_score = 21
+references = ["https://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
+risk_score = 73
 rule_id = "69c420e8-6c9e-4d28-86c0-8a2be2d1e78c"
-severity = "low"
+severity = "high"
 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",
     "Tactic: Initial Access",
     "Resources: Investigation Guide",
@@ -78,9 +102,25 @@ timestamp_override = "event.ingested"
 type = "query"
 
 query = '''
-event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:PasswordRecoveryRequested and event.outcome:success
+event.dataset:aws.cloudtrail and 
+event.provider:signin.amazonaws.com and 
+event.action:PasswordRecoveryRequested 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",
+    "cloud.account.id",
+    "cloud.region",
+    "aws.cloudtrail.response_elements"
+]
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"