AWS Sign-In Root Password Recovery Requested
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/07/02"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2025/10/13"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies a password recovery request for the AWS account root user.
11In 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.
12This 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.
13"""
14from = "now-6m"
15index = ["filebeat-*", "logs-aws.cloudtrail-*"]
16language = "kuery"
17license = "Elastic License v2"
18name = "AWS Sign-In Root Password Recovery Requested"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating AWS Sign-In Root Password Recovery Requested
25
26In 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.
27
28### Possible investigation steps
29
30- **Verify the event details.**
31 Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated.
32- **Confirm legitimacy.**
33 Contact the account owner or credential custodian to verify whether they initiated the password recovery.
34 AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this.
35- **Check CloudTrail for related events.**
36 Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request.
37- **Assess IP reputation and location.**
38 Validate whether the `source.ip` aligns with known admin networks or expected geographies.
39 Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents.
40- **Correlate with other alerts.**
41 Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe.
42
43### False positive analysis
44
45- **Expected maintenance activity.**
46 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.
47- **Testing or account verification.**
48 Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation.
49
50### Response and remediation
51
52**1. Immediate actions**
53- **If confirmed legitimate:**
54 - Ensure that MFA is enabled and operational for the root account.
55 - Encourage rotation of the root password if not recently updated.
56- **If unconfirmed or suspicious:**
57 - Immediately reset the root password using the legitimate AWS recovery email link.
58 - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA).
59 - Check for new successful root logins or unexpected IAM changes since the recovery attempt.
60
61**2. Evidence preservation**
62- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes).
63- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours.
64- Store this evidence in a restricted S3 bucket with Object Lock enabled.
65
66**3. Scoping and investigation**
67- Review all root-level activities within the past 24–48 hours.
68 Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`.
69- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications.
70
71**4. Recovery and hardening**
72- Confirm MFA is enforced on the root account.
73- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active).
74- Secure the associated email account (password reset notifications are sent there).
75- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions.
76- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process.
77
78### Additional information
79
80- **AWS Incident Response Playbooks:**
81 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.
82- **AWS Customer Playbook Framework:**
83 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.
84- **AWS Documentation:** [AWS account root user best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html).
85- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
86"""
87
88references = ["https://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"]
89risk_score = 73
90rule_id = "69c420e8-6c9e-4d28-86c0-8a2be2d1e78c"
91severity = "high"
92tags = [
93 "Domain: Cloud",
94 "Data Source: AWS",
95 "Data Source: Amazon Web Services",
96 "Data Source: AWS Sign-In",
97 "Use Case: Identity and Access Audit",
98 "Tactic: Initial Access",
99 "Resources: Investigation Guide",
100]
101timestamp_override = "event.ingested"
102type = "query"
103
104query = '''
105event.dataset:aws.cloudtrail and
106event.provider:signin.amazonaws.com and
107event.action:PasswordRecoveryRequested and
108event.outcome:success
109'''
110
111[rule.investigation_fields]
112field_names = [
113 "@timestamp",
114 "user_agent.original",
115 "source.ip",
116 "aws.cloudtrail.user_identity.arn",
117 "aws.cloudtrail.user_identity.type",
118 "event.action",
119 "event.outcome",
120 "cloud.account.id",
121 "cloud.region",
122 "aws.cloudtrail.response_elements"
123]
124
125[[rule.threat]]
126framework = "MITRE ATT&CK"
127[[rule.threat.technique]]
128id = "T1078"
129name = "Valid Accounts"
130reference = "https://attack.mitre.org/techniques/T1078/"
131
132
133[rule.threat.tactic]
134id = "TA0001"
135name = "Initial Access"
136reference = "https://attack.mitre.org/tactics/TA0001/"
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 Sign-In Root Password Recovery Requested
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
- 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 subsequentConsoleLoginevents for the root user, or IAM changes (for example,CreateAccessKey,CreateUser, orAttachUserPolicy) shortly after the recovery request. - Assess IP reputation and location.
Validate whether thesource.ipaligns 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
- 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
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
PasswordRecoveryRequestedevent from CloudTrail (±30 minutes). - Preserve all
signin.amazonaws.comand rootConsoleLoginevents 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 asCreateAccessKey,UpdateAccountPasswordPolicy, orDisableMFA. - 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:
andIRP-Credential-Compromise.mdfor procedures related to root account credential recovery and unauthorized access attempts. - AWS Customer Playbook Framework:
SeeCompromised_IAM_Credentials.mdfor guidance on containment, evidence collection, and recovery validation. - AWS Documentation: AWS account root user best practices.
- Security Best Practices: AWS Knowledge Center – Security Best Practices.
References
Related rules
- AWS Access Token Used from Multiple Addresses
- AWS IAM Login Profile Added for Root
- AWS EC2 Instance Connect SSH Public Key Uploaded
- AWS IAM Create User via Assumed Role on EC2 Instance
- AWS STS GetCallerIdentity API Called for the First Time