How do attackers use multi-factor authentication interception?

How MFA interception works in practice

Attackers usually do not “break” multi-factor authentication at the cryptographic layer. They intercept the factor exchange itself, for example by stealing a one-time code in real time, relaying a push prompt to the victim, or capturing a session token after sign-in so they can reuse the authenticated session without needing the password again.

The most common pattern is adversary-in-the-middle phishing, where the victim is tricked into entering credentials and the second factor into a live proxy site. Another pattern is MFA fatigue, where repeated prompts are used to wear down the user until one is approved. In both cases, the attacker is exploiting trust in the login flow, not guessing the factor.

Attackers also target weaker enrollment and recovery paths. If they can alter a phone number, add a new authenticator, or hijack a help desk reset, they may bypass the intended factor entirely. That is why the real control question is not “was MFA enabled?” but “was the factor resistant to relay, replay, and unauthorized re-enrolment?”

Why interception defeats weaker factors

Interception works best against factors that are easy to relay or redirect, such as SMS one-time codes, push approvals without strong verification, or recovery flows that rely on knowledge-based checks. The attacker only needs a brief window to capture the code or approval and bind it to their own session before the legitimate user notices.

Phishing-resistant methods reduce this risk by tying the authentication event to the real origin, device, or private key. A passkey or security key is far harder to relay than a manually typed code, and number matching or device binding makes it harder for an attacker to trick a user into approving the wrong request. For a practical comparison of factor types and rollout implications, see the MFA Guide and the Passwordless and Passkeys Guide.

Some interception succeeds only because the environment still allows legacy or fallback paths. If a user can be downgraded from a strong factor to a weaker one, or if session tokens remain valid long enough after a prompt is approved, the attacker may not need to repeat the interception. That is why session lifetime, device binding, and recovery design matter as much as the factor itself.

What defenders should watch when interception is likely

Useful warning signs include repeated prompts that the user did not expect, successful logins from unusual geographies or devices shortly after a prompt, sudden enrolment of a new factor, and changes to account recovery information immediately before or after sign-in. Those signals often indicate prompt bombing, relayed approval, or takeover of the recovery path rather than a simple password attack.

For a broader attacker tradecraft view, the MFA Fatigue and Bypass Guide shows how push bombing, relay, downgrade abuse, and enrolment hijack fit together. Session theft is equally important: if an attacker captures a valid token after sign-in, they may continue operating even after the victim changes a password or stops approving prompts.

Interception also changes the incident response question. You are not only checking whether the account is compromised, but whether the attacker also added a new factor, enrolled a device, or obtained a token with long enough validity to persist. The deeper the attacker gets into the recovery and session layer, the more likely credential rotation alone will be insufficient.

Risk and Threat Considerations

MFA interception is dangerous because it turns a control that should stop account takeover into a short-lived relay problem. Once an attacker can capture a code, approval, or token, they may gain access fast enough to create persistence, change recovery settings, or harvest additional secrets before the victim or SOC reacts.

Failure mechanism: The attacker abuses a real-time trust relationship in the login flow, usually by relaying the factor, exhausting the user with prompts, or abusing recovery and enrolment paths that sit outside the strongest authentication step.

Impact: The result can be full session takeover, unauthorized enrolment of a new factor, lateral movement into connected systems, and a longer compromise window than teams expect from “MFA-protected” accounts.

Practitioner Guidance

What to prioritise: Treat phishing-resistant MFA as the default for high-value users, admins, and remote access. If your current deployment still depends on SMS, push-only approval, or weak recovery checks, the attacker’s easiest route is usually the one already allowed by policy.

What to verify: Confirm whether your IdP, VPN, and critical SaaS apps enforce number matching or device binding, whether factor changes trigger strong re-verification, and whether session tokens are short-lived enough to limit post-authentication abuse. Also verify that help desk and self-service recovery cannot silently override stronger sign-in controls.

Practitioner takeaway: The practical defense is to make interception unprofitable, not just inconvenient, by reducing relayable factors, tightening recovery paths, and treating post-authentication session theft as part of the same attack.

Related resources from NHI Mgmt Group

• Why do attackers use WhatsApp or other chat redirects to bypass multi-factor authentication on social accounts?
• How do attackers use multi-factor authentication request generation?
• How should security teams use fingerprint verification in multi-factor authentication without creating weak fallback paths?
• How should security teams use one-time passwords as part of multi-factor authentication without creating avoidable friction?