What should organisations do after credentials and MFA codes are captured in a phishing attack?

What should teams do first after a phishing event captures credentials and MFA codes?

Once a phishing kit has captured both the password and the MFA code, the account should be treated as immediately usable by the attacker. The first job is containment, not investigation. That means terminating active access paths, rotating credentials, and checking whether the attacker already established a foothold through webmail, VPN, SSO, or delegated access.

Do not assume the MFA step saved the account. Captured one-time codes can be replayed in real time, and some phishing flows are designed specifically to harvest a session or token after the initial sign-in.

In practice, the response should start with the affected identity and then expand to anything that shares trust with it. That usually includes active sessions, refresh tokens, mailbox rules, recovery methods, and any connected SaaS or remote access services that accept the same identity.

How should organisations contain the account and stop further misuse?

Containment should focus on invalidating the attacker’s current access before looking for broader compromise. Revoke sessions, force password resets, invalidate tokens where the platform supports it, and review recent authentication events for unfamiliar geography, device, or user-agent patterns.

For accounts with email access, inspect mailbox forwarding, inbox rules, delegated access, and recovery settings because these are common persistence paths after phishing. For remote access or VPN identities, verify whether the attacker enrolled a new device, changed a second factor, or created a new trust relationship that will survive a password reset.

If the account had privileged or cross-system permissions, use the response to map blast radius. A single captured login can expose admin consoles, collaboration tools, cloud portals, and shared secrets stored in mailboxes or ticketing systems. That is why a narrow password reset is often insufficient on its own.

Why is identity-wide review needed after one account is phished?

A phishing success rarely stays isolated to one user. Once an attacker can sign in, they often test adjacent services, reuse access tokens, or pivot through inboxes and approved applications. That makes post-incident review an identity problem as much as an account problem.

Review should therefore look for related sign-ins, unusual consent grants, service access, and recent changes to recovery data or MFA methods. If the same phishing lure or login path was used against multiple people, the incident may indicate a broader campaign rather than a single-user compromise.

The best indicator of scope is not the phishing email itself, but what the attacker did after obtaining usable credentials. Look for persistence, privilege expansion, and reuse of the compromised identity in connected systems before declaring the event contained.

Risk and Threat Considerations

Captured credentials and MFA codes are high-risk because they can convert a social engineering event into active account access within minutes. The main exposure is not just login loss, but the downstream ability to read mail, impersonate the user, reset other accounts, or reach sensitive systems through trusted links.

Failure mechanism: The attacker uses the stolen password and code to complete an authenticated session, then relies on session tokens, mailbox rules, recovery channels, or connected applications to persist after the original MFA code expires.

Impact: Organisations can see account takeover, lateral movement, data exposure, fraudulent approvals, and expanded compromise across services that trust the same identity.

Practitioner Guidance

What to prioritise: Treat the event as a live compromise until active sessions, tokens, and recovery paths are explicitly cleared. If the account can still authenticate anywhere, containment is incomplete.

What to verify: Confirm that password reset alone actually revoked access in every connected system, because some platforms retain active sessions or tokens after the main password changes.

What changes at scale: When the same phishing method targets many users, response needs to move from single-account remediation to pattern analysis, especially for repeated sign-in anomalies, shared MFA fatigue, and common mailbox persistence techniques.

Practitioner takeaway: The right question after MFA capture is not whether the attacker “passed MFA,” but whether they have any remaining path to act as the user. If they do, the incident is not over.

Related resources from NHI Mgmt Group

• Why do organisations need stronger identity verification after phishing-resistant MFA becomes more common?
• What should organisations do after credentials are captured through a cloud login phish?
• What should organisations do after a phishing incident exposes credentials or account access?
• What are the risks of using static credentials in MCP servers?