What breaks when push-based MFA is used against AiTM phishing?

Why push MFA fails against AiTM phishing

Push-based MFA only helps if the attacker cannot see or relay the live sign-in. In an adversary-in-the-middle flow, the victim approves a real prompt on a real login, while the attacker forwards the session in real time and captures the authenticated result. The failure is not the approval itself, but the fact that the second factor is not bound to the phishing site.

That is why phishing-resistant sign-in matters more than approval friction. The problem is especially visible in live relay attacks, session token theft, and push fatigue campaigns, where the user sees a normal challenge but the attacker ends up with a valid session anyway. For a practical comparison of methods, see the MFA Guide and the Passwordless and Passkeys Guide.

In other words, push MFA can prove that someone responded, but it does not prove that the response happened on the right site or for the right transaction. When the attacker can proxy the session, the control loses its phishing resistance and becomes a weak barrier for high-value accounts.

What the attacker keeps and what the defender loses

aitm phishing usually preserves the legitimate authentication ceremony while stealing the post-authentication artefact. The attacker may never learn the password, but they can still receive the session cookie or token once the victim completes MFA. That is why downstream session protection, token handling, and sign-in monitoring matter as much as the MFA prompt itself.

For access paths such as email, remote access, identity providers, and admin consoles, the practical loss is trust in the prompt as a security decision point. If the session can be replayed or the token can be forwarded, the organisation has not stopped account takeover, it has only made it slightly harder to automate. This is why modern guidance treats push approval as a baseline control, not a sufficient control, for privileged or externally exposed access.

The strongest defensive pattern is to move authentication to a phishing-resistant factor that is bound to the origin or device, such as passkeys or security keys. NIST’s digital identity guidance explicitly covers phishing-resistant authenticators, and the NIST SP 800-63 Digital Identity Guidelines remain the clearest external reference for that shift.

Where this breaks in real environments

The weakness shows up first wherever a successful session has immediate value: remote access, SSO portals, cloud control planes, and privileged admin workflows. If the same prompt is used for everyday logins and for access to sensitive systems, attackers only need one successful relay to reach the whole trust chain. In practice, organisations often discover that the MFA method is not the only problem, the session lifetime, conditional access design, and help-desk recovery flow also determine how far the attacker can go.

Real-world breaches repeatedly show the same pattern: valid credentials, live approval, and then movement into valuable systems. NHIMG’s incident coverage on the CitrixBleed exploitation 2023 and the Twilio 0ktapus breach 2022 illustrates how session theft and relay-style phishing can bypass MFA assumptions. For identity-provider and SSO hardening, the Identity Provider and SSO Security Guide is the most relevant companion.

Once the attacker has a live session, the control failure is usually less about authentication and more about what the session can do next. That is where privileged access, token scope, and step-up requirements become the real containment boundary.

Risk and Threat Considerations

Push MFA is most fragile where attackers can proxy a sign-in in real time, because the user still sees a genuine-looking approval while the attacker receives a usable session. The result is account compromise without needing to defeat the factor directly, which makes high-value web portals, remote access gateways, and identity providers attractive targets.

Failure mechanism: The attacker relays the victim’s login to the legitimate service, captures the returned session artefact, and reuses it before the user notices the fraud.

Impact: The attacker can obtain authenticated access, bypass the intended value of push approval, and then pivot into email, cloud, VPN, or admin functions if the session is broadly trusted.

Practitioner Guidance

What to prioritise: Treat push MFA as a transitional control for lower-risk access, not as the final control for privileged, remote, or internet-facing sign-in paths. Replace or supplement it with phishing-resistant authentication for users who can reach sensitive systems.

What to verify: Check whether your sign-in flow binds the authenticator to the origin or device, whether sessions are short-lived enough to limit replay value, and whether step-up is enforced before sensitive actions rather than only at login.

Common mistake: Teams often assume that any MFA prompt blocks phishing, but the relevant question is whether the factor survives a live relay attack. If the attacker can forward the ceremony, the control does not meaningfully resist AiTM.

Practitioner takeaway: The security decision is not whether users approved a prompt, it is whether the approved session is phishing-resistant, replay-resistant, and narrow enough to limit blast radius if it is stolen.

Related resources from NHI Mgmt Group

• What is the difference between push-based MFA and phishing-resistant authentication?
• What breaks when push-based MFA is the main control for privileged access?
• Should organisations rely on MFA alone against AITM phishing?
• What breaks when push-based MFA is exposed to repeated notification attacks?