Why do phishing kits with reverse-proxy flows still bypass MFA?

Why This Matters for Security Teams

Reverse-proxy phishing kits are dangerous because they do not need to crack MFA. They sit between the user and the real login page, forwarding credentials and one-time prompts in real time, then replaying the authenticated session to the attacker. That means the control failed is often not MFA itself, but session handling, token binding, device trust, and detection of impossible authentication paths. Guidance from the NIST Cybersecurity Framework 2.0 emphasizes resilient access control, but phishing-resistant authentication must also be paired with session protection.

This is why token theft and adversary-in-the-middle kits keep showing up in incident reports, including campaigns like the Microsoft Midnight Blizzard breach analysis. The practical lesson is that “MFA enabled” does not mean “sign-in is safe” if the session can be hijacked after authentication. In practice, many security teams encounter session replay after users complete an apparently legitimate login, rather than through intentional compromise of the password itself.

How It Works in Practice

A reverse-proxy phishing kit creates a live man-in-the-middle between the victim and the identity provider. The user enters credentials into a lookalike page, the kit relays them to the real site, and when MFA is triggered, the attacker relays that challenge too. Once the identity provider issues a session cookie or token, the proxy captures it and the attacker uses it directly. At that point, the attacker is no longer “logging in” in the normal sense. They are replaying a valid authenticated session.

That is why current guidance increasingly focuses on phishing-resistant authentication, session binding, and continuous verification rather than MFA alone. The issue is not just credential entry, but whether the session is cryptographically tied to the original device, origin, and user interaction. NIST AI and identity guidance is not the core reference here; instead, operational controls such as token lifetime, refresh token protection, device posture checks, and conditional access matter more. The broader NHI lesson from NHIMG research on the Microsoft Midnight Blizzard breach is that stolen sessions behave like privileged credentials once issued.

• Use phishing-resistant methods such as FIDO2/WebAuthn where feasible, because they reduce replay opportunities.
• Bind sessions to device signals, IP reputation, or token protection features where the platform supports it.
• Shorten session and refresh-token lifetimes for high-risk roles and sensitive applications.
• Monitor for impossible travel, new device enrollment, unusual consent events, and atypical token use.

These controls tend to break down in legacy web apps and federation stacks that cannot bind tokens to device state because the session remains portable after issuance.

Common Variations and Edge Cases

Tighter session controls often increase user friction, so organisations must balance phishing resistance against business continuity and support overhead. There is no universal standard for this yet, especially across mixed estates with older SAML integrations, third-party SaaS, and browser-based access that lacks modern token binding.

Some environments reduce risk with step-up authentication for sensitive actions rather than forcing every login through the same control set. Best practice is evolving toward layered defenses: phishing-resistant MFA, conditional access, session revocation, and detection of adversary-in-the-middle behavior. The NIST Cybersecurity Framework 2.0 supports this kind of layered access governance, but implementation still depends on what the identity provider and application can enforce. Organisations that rely on static password plus OTP flows should assume reverse-proxy kits can still inherit the authenticated session if downstream controls do not detect replay.

Related resources from NHI Mgmt Group

• Why do AiTM attacks still matter if organisations already use MFA?
• Why do still-valid secrets matter after public disclosure?
• Why do phishing-resistant MFA controls still fail against social engineering?
• What should teams do when phishing-resistant MFA is in place but fraud still occurs?