How should organisations respond when a user submits credentials to a phishing page?

Why the response has to target the session, not just the email

Once a user submits credentials into a phishing page, the security problem is no longer only the message. The attacker may already have a live authenticated session, mailbox access, or a token that outlives the password change. That is why the response has to treat the event as an identity compromise and OWASP Non-Human Identity Top 10 helps frame the credential and token side of the exposure.

The practical objective is to cut off whatever the attacker can use next. If the compromise reached SSO, a mail client, a browser session, or delegated application access, simply deleting the phishing email does not stop follow-on abuse. The right response sequence is to invalidate the session, remove access paths that survive password reset, and confirm whether the attacker touched any linked applications or OAuth grants.

Phishing response should also distinguish between the lure and the payload. A message removal action helps limit further clicks, but the material risk is that the attacker may already have what they need to act as the user. For that reason, responders should assume the message was only the delivery mechanism and investigate the resulting trust relationship, not just the inbox artifact.

What to check after credential submission

Mailbox review is often the fastest way to see whether the attacker is trying to persist. Review forwarding rules, inbox rules, delegated access, and any unusual changes to recovery settings or alternate contact methods. If the account has access to cloud apps, check for newly granted OAuth consent, suspicious app registrations, or token abuse that can bypass a password reset. CoPhish OAuth phishing via Copilot Studio is a useful example of why token theft and consent abuse must be investigated alongside the original phishing click.

Resetting the password alone is not enough if existing sessions remain valid. Revoke active sessions, invalidate refresh tokens where the platform supports it, and remove any remembered-device or persistent login state that would let the attacker resume access. If the account used API keys, application passwords, or device-bound credentials, those should be rotated or revoked as part of the same incident, not deferred to a later cleanup step. API Key Management Guide is relevant where the same compromised user also controlled bearer-style credentials.

When the account is high value, widen the search to related systems that could have inherited trust from it. That includes password managers, admin consoles, collaboration tools, and any business application that accepts the same identity provider session. The question is not only whether the password was stolen, but whether the attacker has already converted that theft into durable access.

How to contain the incident before it spreads

Containment should focus on the smallest set of controls that remove attacker leverage quickly. Disable or step up verification for the affected account if compromise is confirmed, cut active sessions, rotate exposed secrets, and notify downstream owners if the account had privilege over shared resources. Guide to the Secret Sprawl Challenge is relevant when the user account may have exposed stored credentials, keys, or tokens beyond the mailbox itself.

Check whether the phished credentials were reused anywhere else. If the same password was used outside the primary system, assume those other accounts are also at risk and rotate them as well. If the account had access to shared inboxes, admin portals, CI/CD systems, or sensitive data stores, verify whether the attacker could have moved laterally before the response began. In practice, the blast radius is defined by what the compromised identity could reach, not by the original phishing page.

If the organisation uses single sign-on, make sure the identity provider and connected applications are both addressed. A user password reset at one layer can leave downstream sessions or application tokens intact. RFC 6749: The OAuth 2.0 Authorization Framework is useful background when the incident involves delegated access and client credentials rather than only an interactive login.

Risk and Threat Considerations

The main risk is that a phished credential often buys more than one login. Attackers commonly use the captured session to bypass MFA friction, hide inside legitimate mailbox activity, or mint new trust through OAuth grants and application tokens. The longer that access remains valid, the more likely the attacker is to establish persistence or harvest additional credentials.

Failure mechanism: A password change without session and token revocation leaves the attacker with still-valid access paths, especially where browser sessions, refresh tokens, mailbox rules, or delegated app access survive the reset.

Impact: The attacker can continue reading mail, resetting other accounts, approving malicious consent, or using the identity as a launch point for broader compromise, data theft, or business email abuse.

Practitioner Guidance

What to prioritise: Treat the account as compromised until proven otherwise. Revoke active sessions first, then rotate the credential, then inspect mailbox rules, token grants, and connected applications. That order matters because it removes the attacker’s ability to keep working while you investigate.

What to verify: Confirm whether the user’s browser, mail client, or SSO session remained active after the lure was submitted. If the user had privileged or delegated access, verify that the compromise did not extend into shared inboxes, admin tools, or approved third-party apps.

Common mistake: Teams often close the ticket after a password reset and an email purge. That is too narrow for a credential phishing event, because the durable risk usually sits in the session, the token, or the mailbox rule set rather than the message itself.

Practitioner takeaway: The right response is to remove attacker authority, not just attacker visibility. If you do not revoke the active trust the phish created, the incident is still open.

Related resources from NHI Mgmt Group

• Guide: Phishing Guide
• What happens when a user enters credentials into a phishing page before the attack is blocked?
• What happens when a user enters credentials into a phishing page hidden behind a reverse proxy?
• How should organisations respond when an identity provider breach may expose support-user data to phishing and social engineering follow-up attacks?
• What happens after a user submits information on a geofenced credential phishing page?