Why do AiTM phishing kits still succeed against MFA?

Why This Matters for Security Teams

aitm phishing kits succeed because they bypass the assumption that MFA ends the risk at authentication. The attacker is not trying to defeat the second factor in the abstract; they are trying to steal the live session after the user has already satisfied it. That makes the problem a post-authentication control issue, not just an identity proofing issue. Guidance from the NIST Cybersecurity Framework 2.0 maps well to this reality because detection, continuous monitoring, and response matter as much as sign-in controls.

For security teams, the practical failure is often a gap between login security and session security. If conditional access, token binding, and replay detection are weak, a stolen cookie can outrun the user’s password reset and even a fresh MFA challenge. That is why the issue persists across both traditional enterprise environments and cloud-heavy stacks where browser sessions are the real credential. NHIMG has documented how quickly attackers operationalise stolen access in adjacent identity abuse cases, including the DeepSeek breach and the Microsoft Midnight Blizzard breach, where credential theft and session abuse were central to attacker success. In practice, many security teams encounter token replay only after the session has already been used to move laterally or exfiltrate data, rather than through intentional sign-in monitoring.

How It Works in Practice

AiTM kits sit between the user and the real sign-in page, proxying the entire authentication flow. The victim enters credentials, completes MFA, and receives a valid session. The kit then captures the session cookie, refresh token, or equivalent bearer artifact and forwards it to the attacker. Once that happens, the attacker no longer needs to know the password or satisfy MFA again because the browser session becomes the reusable credential.

Defending against this requires controls that treat the session as the asset:

• Prefer phishing-resistant MFA, especially FIDO2 and passkeys, because they reduce the value of adversary-in-the-middle relays.
• Use device binding, token binding where supported, and short session lifetimes so stolen artifacts expire faster.
• Monitor for impossible travel, new device fingerprints, unusual user agents, and abnormal token reuse after sign-in.
• Force step-up authentication for sensitive actions instead of assuming the initial MFA event is sufficient.
• Centralise logs so identity, endpoint, and SaaS telemetry can be correlated during replay detection.

This is also why post-authentication validation matters more than many teams expect. A cookie replay from a fresh IP may look “valid” to the application even when the session was harvested through an AiTM proxy. NIST guidance on continuous monitoring and response supports this posture, while NHIMG research on identity abuse shows how quickly exposed access gets operationalised in the wild. The same lesson appears in the DeepSeek breach: once credentials or session material are exposed, attackers move fast and do not wait for a second chance. These controls tend to break down in legacy applications that do not support token binding, short-lived sessions, or strong telemetry for replay analysis because the application treats every valid cookie as equally trustworthy.

Common Variations and Edge Cases

Tighter session controls often increase user friction and support overhead, so organisations have to balance usability against the risk of replayable access. That tradeoff is especially visible when remote work, unmanaged devices, or federated SaaS access are part of the normal operating model.

There is no universal standard for this yet, but current guidance suggests three important edge cases. First, SMS and push-based MFA remain highly relaysusceptible, so they should not be treated as phishing-resistant. Second, browser session theft can still succeed even when the account uses strong MFA, especially if the application allows long-lived refresh tokens or weak revocation. Third, some environments have one-time codes plus session cookies but no effective device posture checks, which means a stolen browser state is enough for attacker access.

Teams should also be careful not to overstate what “MFA protected” means. It may be true at sign-in and false immediately afterward if the session is not constrained. That is where the strongest compensating controls are usually identity-aware proxying, session invalidation on risk signals, and tighter lifetime policies for refresh tokens. The practical standard is not “did MFA happen?” but “can this session still be trusted right now?”

Related resources from NHI Mgmt Group

• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do phishing and social engineering still succeed against mature IAM programmes?
• Should organisations rely on MFA alone against AITM phishing?
• Why do phishing kits with reverse-proxy flows still bypass MFA?