What breaks when legacy MFA is paired with proxy-based phishing attacks?

The authentication event can still succeed even though the site is malicious, because the proxy relays the legitimate challenge and captures the resulting session material. That means the user appears compliant at login time while the attacker inherits the session. Control testing must therefore include token replay and session hijack scenarios.

Why Legacy MFA Fails Against Proxy-Based Phishing

Legacy MFA is designed to prove that a user completed a challenge, not that the login happened at the right destination. A reverse proxy can relay the real sign-in flow, capture the resulting session cookie or token, and let the attacker ride the authenticated session. That is why proxy phishing defeats many “MFA enabled” assumptions, especially where access policy still treats a completed prompt as sufficient proof of trust.

This is a recurring pattern in real-world identity abuse, not an edge case. NHIMG’s 52 NHI Breaches Analysis and its Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same operational lesson: once an attacker can reuse authenticated material, the control boundary has already moved downstream. For broader identity guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping session, authentication, and monitoring requirements, but it does not by itself solve phishing-resistant login design.

In practice, many security teams discover the failure only after a valid MFA login has already been converted into unauthorized inbox access, SaaS takeover, or lateral movement through trusted application sessions.

What Changes in Practice When the Proxy Owns the Session

The key break is that the attacker does not need to defeat MFA in the abstract. They only need to terminate the trust chain after the legitimate user authenticates. In a proxy phishing flow, the victim enters credentials and completes the MFA prompt on a malicious site that transparently forwards everything to the real identity provider. The proxy receives the finished session artifact, then uses it against the target service.

That means defenders need to test for token replay, cookie theft, and session hijack, not just failed login attempts. Current guidance suggests prioritising phishing-resistant methods such as FIDO2/WebAuthn, device-bound credentials, and contextual step-up decisions rather than relying on one-time codes or push approval alone. The stronger the assurance that the cryptographic ceremony is bound to the original origin and device, the harder it is for a proxy to relay the result. For attacker behaviour and campaign patterns, CISA cyber threat advisories provide useful context, while MITRE ATT&CK Enterprise Matrix helps map post-authentication abuse such as valid accounts, token theft, and session persistence.

• Use phishing-resistant MFA where the authenticator is origin-bound and resistant to relay attacks.
• Shorten session lifetimes and bind tokens to device or client signals where feasible.
• Instrument detection for impossible travel, new device posture, token replay, and unusual session reuse.
• Require step-up checks for high-risk actions, not just for initial login.

NHIMG’s OWASP NHI Top 10 also highlights why authentication alone is never the full control story when an actor can continue operating after the first trusted event. These controls tend to break down when legacy SSO sessions remain valid for long periods, because the attacker can wait out MFA and operate entirely inside an already-issued session.

Where the Standard Advice Breaks Down

Tighter phishing resistance often increases deployment friction, requiring organisations to balance user convenience against session assurance and recovery complexity. That tradeoff becomes especially visible in mixed environments where some apps support modern token binding and others still rely on browser cookies, older SAML flows, or long-lived refresh tokens.

There is no universal standard for this yet, but current best practice is to treat MFA as one signal in a broader access decision, not as a permanent trust stamp. That means layering conditional access, step-up verification for sensitive transactions, and stronger telemetry around token use. It also means accepting that some controls only reduce blast radius rather than fully preventing compromise.

Proxy phishing is hardest to contain in environments with unmanaged endpoints, BYOD access, third-party SaaS sprawl, or help desk flows that reset MFA without strong identity proofing. NHIMG’s Microsoft Midnight Blizzard breach and CoPhish OAuth Token Theft via Copilot Studio show how quickly an attacker can move from initial access to session abuse when identity assurance is weak. In other words, the practical failure is not just MFA bypass, but the organisation’s inability to distinguish a legitimate authentication event from a weaponised one after the fact.

Related resources from NHI Mgmt Group

• What breaks when push-based MFA is exposed to repeated notification attacks?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• When does regex-based secret detection become too unreliable for production use?
• Why do MFA controls fail against token-based SaaS attacks?