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