Reset the password, revoke active sessions and tokens, review mailbox rules and OAuth app grants, and confirm whether any secondary access was created. Fast containment matters because a relay attack can make the login seem valid even when the credentials were captured by an attacker.
What to do immediately after a suspicious sign-in page capture
The first job is containment, not diagnosis. If a user entered credentials into a page that looked like a real login, assume the password and any existing session material may now be usable by an attacker. Reset the password, invalidate active sessions and tokens, and check whether the attacker created persistence through mailbox rules, OAuth grants, or delegated access.
Fast action matters because a relay or reverse-proxy phishing flow can make the sign-in appear legitimate while the attacker captures reusable credentials and session state. Even if the original login later fails, the compromise path may already have produced mailbox access, app consent, or another foothold that survives a simple password change.
What else needs to be checked beyond the password reset
Credential theft is only the starting point. Teams should verify whether the account was used to alter email forwarding, create inbox rules, add recovery methods, consent to new OAuth applications, or mint tokens and API-based access that bypass normal interactive sign-in. Those secondary changes often matter more than the original password itself because they preserve access after the user changes it.
This is also the point to review sign-in history, unusual device registration, and any privilege changes tied to the account. If the account could approve apps, access mail, or administer downstream systems, confirm whether the attacker used that authority to expand reach. If the account is a service identity or automation account rather than a human user, rotate the related secret material and confirm every dependent integration still works after revocation.
How to prove the account is no longer exposed
Containment is complete only when the team has both invalidated the known access path and confirmed there is no surviving one. That means checking whether sessions, refresh tokens, federation artifacts, mailbox rules, app consents, and recovery settings were all cleaned up, not just the password. It also means verifying that the user can re-authenticate through the approved path without reintroducing the old device, browser, or mail client state.
When there is any sign of follow-on activity, teams should treat the event as a potential account compromise, not a one-off phishing click. Review whether the account was used to access shared files, internal tools, or upstream identity systems, and whether any conditional access exception or trusted device setting now needs to be removed. If the account had access to sensitive systems, broaden the review to include adjacent accounts that could have been targeted through the compromised mailbox or identity provider session.
Risk and Threat Considerations
A suspicious sign-in page can lead to more than password theft. The real risk is that the attacker may obtain reusable session material, create durable mailbox persistence, or pivot into downstream services through OAuth consent, forwarding rules, or trusted-device state.
Failure mechanism: The victim submits credentials to a lookalike page, the attacker relays or reuses them, and then establishes a second access path such as tokens, rules, or delegated app access that survives a password change.
Impact: The account can remain exposed after the initial alert, enabling mailbox compromise, fraud, data theft, or lateral movement into connected systems that trust the compromised identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Captured credentials and tokens can be leaked through phishing and reused for access. |
| NHI-04 — Insecure Authentication | Suspicious sign-in pages abuse authentication flows and can capture reusable credentials. | |
| NHI-07 — Long-Lived Secrets | Stolen passwords, tokens, and app grants may remain valid long enough to enable persistence. | |
| Recommendation — Treat exposed secrets as compromised and revoke or rotate them immediately. Harden sign-in flows and verify users against phishing-resistant authentication. Reduce token and secret lifetime so stolen access expires quickly. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Phished credentials and token reuse are authentication failures that enable unauthorized access. |
| Recommendation — Validate authentication paths and revoke compromised credentials and sessions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password resets and token revocation are authenticator lifecycle actions after compromise. |
| AC-2 — Account Management | Suspicious sign-in follow-up includes disabling or constraining accounts and related access paths. | |
| AC-12 — Session Termination | Active sessions must be terminated so captured credentials cannot continue working. | |
| Recommendation — Rotate compromised authenticators and invalidate associated tokens. Review account status and remove unnecessary access paths after compromise. Terminate active sessions and revoke tokens after suspicious sign-in activity. | ||
Practitioner Guidance
What to prioritise: Revoke the access that can still work after the password reset. If you only change the password, you may leave active sessions, refresh tokens, and app grants in place, which is where post-phishing persistence usually lives.
What to verify: Confirm that mailbox rules, recovery methods, delegated access, and OAuth consent have all been reviewed on the affected account. If the user had privileged or business-critical access, validate the downstream systems that accepted that identity before closing the incident.
Practitioner takeaway: The safe response is to remove every surviving authentication path, not just the one the user typed into the fake page.
Related resources from NHI Mgmt Group
- What do teams get wrong about investigating suspicious CRM activity after resetting credentials?
- How should security teams respond when credentials may have been entered into a fake login page?
- How can organizations secure their MCP server credentials?
- How should security teams authenticate AI agents in enterprise environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org