They intercept the session in real time rather than trying to defeat authentication mathematically. If the attacker can proxy the user and replay credentials or verification codes, MFA still authenticates the wrong session, so defenders must detect relay behaviour and automation, not only failed logins.
How relay phishing changes the problem MFA is trying to solve
MFA is strong when it is the thing deciding whether a login attempt should succeed. Relay attacks change that assumption. The victim still completes a legitimate challenge, but the attacker sits between the user and the real service, so the service sees an apparently valid sign-in. That is why the control can be bypassed without breaking the cryptography.
The practical issue is that MFA was built to raise the cost of impersonation, but relays convert the attack into real-time OTP relay or session capture. Once the user authenticates through the attacker’s proxy, the attacker is no longer guessing credentials, they are borrowing the user’s live trust relationship.
This is why phishing-resistant methods matter. Techniques such as passkeys and FIDO2 bind the authentication ceremony to the real origin and are much harder to relay than a code that can be copied and replayed. The control objective shifts from “did the user approve a prompt” to “did the user authenticate to the genuine relying party.”
Why bots make account fraud look like normal login traffic
Bots do not need to defeat MFA if they can industrialise the parts around it. They can spray credentials, test recovery flows, automate form submission, and replay verification data at scale until they find a path that works. That is why account fraud often shows up as volume, speed, and consistency rather than obvious failures.
A useful example is credential abuse paired with automated session use. In SonicWall SSL VPN account compromises 2025, valid credentials were enough to reach many accounts. In practice, bots help attackers keep that activity operational by trying many accounts, many paths, and many timing patterns until the fraud blends into ordinary access.
That is also why defenders should watch for behaviour, not only authentication outcome. A successful sign-in is not reassuring if the request path, device pattern, geography, user-agent mix, or timing profile looks automated. Fraud teams and identity teams need the same event stream because bots often occupy the boundary between login abuse and account takeover.
What defenders should detect when MFA is being relayed or automated
The key signal is not just a failed MFA challenge, it is a suspiciously successful one. Relay and bot activity often produces the same account succeeding from unusual context, repeated attempts followed by one clean success, or sign-ins that immediately transition into session theft, mailbox access, payout changes, or help-desk abuse.
That makes session-layer controls essential. A session token theft pattern can bypass the authentication step entirely after the fact, while a relay attack succeeds during the step itself. Both cases mean defenders must inspect authentication context, session reuse, and downstream actions, not just whether MFA was presented.
For many organisations, the practical threshold is simple: if the authentication method can be proxied in real time, it should not be treated as sufficient against phishing and account fraud on its own. The response needs to include origin binding, stronger session validation, rate and anomaly controls, and detection for automation that uses valid user paths instead of brute force.
Risk and Threat Considerations
Relay phishing and bot-driven fraud are dangerous because they exploit the trust that MFA creates, then reuse it against the service in real time. The result is not merely a compromised password, but a valid authenticated session that can be used for takeover, payments abuse, data access, or lateral movement.
Failure mechanism: The attacker proxies the victim’s sign-in or automates repeated attempts until a live session is obtained, so the service authenticates the attacker’s session as if it were the user’s.
Impact: Fraud can proceed with fewer obvious failures, weaker detection, and higher business impact because the compromise looks like legitimate access until downstream actions reveal it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and AAL guidance directly address relay-resistant sign-in. |
| Recommendation — Prefer phishing-resistant authenticators and binding that prevent real-time relay attacks. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User authentication strength and MFA effectiveness are central to account-fraud defenses. |
| IA-5 — Authenticator Management | Relay and bot abuse often exploit weak authenticator lifecycle and reuse patterns. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting relay and bot behavior depends on review of authentication and session anomalies. | |
| Recommendation — Require strong user authentication and step-up controls for sensitive access. Manage authenticators tightly, including issuance, renewal, rotation, and revocation. Correlate login, session, and anomaly logs to spot suspiciously successful access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The question concerns authentication being bypassed or replayed in real time. |
| API5 — Broken Function Level Authorization | Fraudsters often use a valid session to reach functions they should not be able to invoke. | |
| Recommendation — Harden authentication flows against replay, interception, and token misuse. Enforce function-level checks on every sensitive action, not just at sign-in. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Account fraud is reduced by limiting and monitoring access paths that can be abused after login. |
| Recommendation — Restrict and review access paths, then remove standing access that expands fraud blast radius. | ||
Practitioner Guidance
What to prioritise: Treat phishing-resistant authentication and session binding as the primary control path for any account that can move money, data, or privileges. If an access path can be relayed, assume MFA alone is not a sufficient fraud barrier.
What to verify: Check whether your detections distinguish failed authentication from suspiciously successful authentication. Good coverage should include relay-like timing, repeated attempts from automation, abnormal device or browser patterns, and rapid post-login actions such as profile changes or recovery enrollment.
Practitioner takeaway: The real control problem is not “did MFA happen”, it is “did the right user authenticate to the right service in a way that cannot be proxied or industrialised by an attacker.”
Related resources from NHI Mgmt Group
- Why do residential botnets make traditional rate limiting less effective against account takeover attempts?
- Why do deepfake attacks make MFA less effective?
- Why do synthetic identities make traditional fraud controls less effective?
- Why do GenAI-powered scams make traditional fraud controls less effective?