The strongest defense is phishing resistant authentication, especially passkeys or hardware security keys, because the cryptographic challenge is bound to the real origin and cannot be replayed through a lookalike domain. Teams should also assume credentials and session cookies can be stolen from convincing reverse proxy kits, so monitoring, user awareness, and rapid takedown processes remain necessary.
Why Real-Time Relay Phishing Breaks Traditional MFA
Adversary-in-the-middle kits succeed because they sit between the user and the legitimate service, capturing the login exchange and immediately replaying what they collect before the session expires. That means the weak point is not just the password, it is any factor that can be proxied in real time, including SMS or app-based one-time codes. The defense must therefore shift from “did the user type a second factor?” to “can the factor be relayed?”
Phishing resistant methods change the equation because the authenticator proves possession against the real origin, not the lookalike site. Passkeys and hardware security keys are designed to bind the challenge to the legitimate domain, so the attacker cannot simply forward the exchange through a reverse proxy and reuse it elsewhere. That is why origin binding matters more here than generic MFA strength.
Teams should also treat session theft as part of the same problem. If a reverse proxy captures the session cookie after login, the attacker may not need the password or code again, which is why post-authentication protections matter alongside the login control itself.
Controls That Reduce the Success Window
Defense works best as a layered set of controls that shortens the attacker’s usable window and limits what a stolen session can do. A phishing resistant authenticator is the first line, but it should be paired with conditional access, device posture checks, token binding where available, short-lived sessions, and reauthentication for sensitive actions. The goal is to make the stolen login useful for less time and for fewer actions.
- Prefer passkeys or hardware security keys for high-value users and sensitive administrative access.
- Disable or sharply limit weaker fallback methods that can still be relayed, especially where business risk is high.
- Use risk-based session controls so anomalous location, device, or network changes trigger step-up checks or session invalidation.
- Limit the blast radius of a stolen cookie by tightening session lifetime, idle timeout, and privilege scope.
Monitoring should focus on the handoff between successful authentication and suspicious session behavior, because that is where relay attacks often become visible. Unusual geoimpossible travel, new device fingerprints, rapid privilege changes, and repeated authentication attempts from the same session are all signs that a proxy-based phish may have succeeded.
Risk and Threat Considerations
Real-time relay phishing is dangerous because it defeats controls that only verify user interaction, not origin integrity. Once the adversary captures a valid credential or session, they can often move quickly into mailbox abuse, account recovery abuse, internal app access, or further phishing from a trusted account.
Failure mechanism: The user authenticates to a convincing proxy page, the attacker forwards the challenge to the legitimate service, and the resulting session material is stolen or reused before expiry. Any fallback method that is relayable, reusable, or long-lived increases the chance of compromise.
Impact: A single successful login can become full account takeover, session hijack, or downstream fraud even when the user believes multi-factor authentication was in place. In higher-privilege accounts, the result can be rapid lateral movement and broader compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Phishing-Resistant Authentication | Origin-bound auth blocks real-time relay of credentials and one-time codes. |
| NHI-02 — Secret and Credential Lifecycle | Relay kits can steal reusable session material, making lifecycle controls material. | |
| NHI-03 — Visibility and Detection | Detection is needed to spot proxy-based login abuse and hijacked sessions. | |
| Recommendation — Deploy phishing-resistant authenticators for privileged and high-risk access. Shorten session lifetime and rotate or revoke exposed credentials quickly. Monitor for anomalous session behavior, rapid handoffs, and suspicious token use. | ||
| NIST SP 800-63 | AAL3 — Authenticator Assurance Level 3 | AAL3 aligns with phishing-resistant authentication for strong remote assurance. |
| Phishing-resistant authenticators — Phishing-resistant authenticators | The subject is specifically about defending against relayed login and OTP theft. | |
| Recommendation — Use AAL3-grade phishing-resistant authenticators for sensitive access. Prefer authenticators that bind the ceremony to the legitimate origin. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Continuous Verification | Stolen sessions require ongoing verification beyond the initial login event. |
| Recommendation — Continuously re-evaluate session trust before allowing sensitive actions. | ||
| CIS Controls v8 | 6.3 — Account Monitoring and Control | Monitoring accounts and sessions is central to detecting takeover after relay success. |
| Recommendation — Alert on anomalous account activity and invalidate compromised sessions fast. | ||
| MITRE ATT&CK | T1556 — Modify Authentication Process | Adversary-in-the-middle phishing abuses the authentication exchange itself. |
| Recommendation — Map relay-phishing activity to authentication-process abuse in detection content. | ||
Practitioner Guidance
What to prioritise: Move your highest-risk populations, privileged users, and sensitive workflows to phishing resistant authentication first. That is where the return on control is highest, because those accounts are the ones most likely to be targeted and the most costly to lose.
What to verify: Test whether your current MFA methods can be proxied in a live relay lab. If a control still works when a reverse proxy sits between the user and the service, it is not the control you want for exposed or privileged access.
Common mistake: Treating “MFA enabled” as equivalent to phishing resistance. For this attack pattern, the difference between replayable factors and origin-bound authenticators is the difference between a speed bump and an effective block.
Practitioner takeaway: Defend against this phishing style by combining origin-bound authentication with short session lifetimes and strong detection, because no single control fully removes the risk once an attacker can relay a legitimate login in real time.
Related resources from NHI Mgmt Group
- How should online banking teams defend against man-in-the-middle phishing that intercepts MFA codes and session tokens in real time?
- How should security teams defend against phishing panels that only reveal themselves to real victims?
- How should security teams defend against phishing kits that proxy real login pages?
- How should security teams defend against live phishing panels that intercept MFA codes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
