MAN IN THE MIDDLE (MitM) PROTECTION
Predict and combat advanced ATO attacks, with MitM countermeasures
Fortify your ATO defenses and drive down the cost of attacks that use real-time phishing proxies and network redirection techniques.
Introduction
MFA is enabled. HTTPS is enforced. VPNs are deployed. Account takeover keeps happening anyway. That gap isn’t a configuration problem. It’s a structural one.
A Man-in-the-Middle attack doesn’t break your authentication controls. It works through them, relaying credentials and session tokens in real time before your stack can flag anything. The result looks like a legitimate login to every layer of your security infrastructure.
This guide covers the full taxonomy of MitM attack variants, explains why reverse proxy phishing and OTP relay defeat controls most organizations trust, and outlines what a signal-based detection framework actually requires to catch what authentication alone misses.
Types of MitM and MitM-enabled attacks: a practitioner’s taxonomy
A Man-in-the-Middle attack isn’t a single technique. It’s a class of attack that operates inside authentication flows, not around them. The most dangerous variants produce no visible error for the user, the browser, or the security stack.
Organizations have invested heavily in MFA, HTTPS, VPNs, and passkeys. Account takeover rates keep climbing anyway. The FBI IC3 2024 Internet Crime Report recorded $16.6 billion in cybercrime losses, a 33% increase from 2023.
The MemcycoFM Show: Podcast Episode 21 – $37M Raised to Disrupt Digital Impersonation and Account Takeover Fraud identifies Adversary-in-the-Middle (AiTM) techniques as an active MFA bypass vector. This guide covers the full MitM taxonomy, explains where each defense breaks down, and frames what a real detection layer requires. Written for security leaders and fraud teams who need analysis, not definitions.
What is a Man-in-the-Middle attack?
A Man-in-the-Middle attack positions an attacker between a user and a legitimate service to intercept, relay, or manipulate communication in real time. The user sees nothing wrong: no broken padlock, no suspicious redirect, no error.
That’s what makes it dangerous.
- NIST SP 800-63B defines it precisely: “the attacker would be positioned between claimant and verifier” during authentication. The authentication flow completes. It just completes for the attacker.
- This is where MitM diverges from standard phishing. Traditional phishing relies on deception: a suspicious link, a typo, a mismatched URL. MitM-based attacks manipulate the authentication flow itself. The usual detection signals don’t apply.
- The Microsoft Security Blog (May 2025) identifies adversary-in-the-middle (AiTM) credential phishing as the dominant evolution of phishing as MFA adoption grows.
- The most impactful variants today, including reverse proxy phishing, OTP relay, and session hijacking, operate at the application and authentication layer. This isn’t a Wi-Fi problem. For financial services and enterprise environments, the exposure sits inside the authentication sequence itself.
Latest podcast episodes
The MemcycoFM Show: Ep 24 – Real-Time Remote Desktop Takeover Detection and Mitigation
The MemcycoFM Show: Ep 23 – Real-Time MitM Protection and ATO Prevention Strategy
Types of Man-in-the-Middle attacks: a practitioner's taxonomy
“MitM” gets treated as a single technique. It isn’t. Each variant operates at a different point in the authentication and session lifecycle, uses a different interception mechanism, and exposes a different detection surface. Here’s how the five main types break down.
Reverse proxy phishing
In a reverse proxy phishing attack, the attacker’s fake site sits silently between the user and the real service, relaying credentials, OTPs, and session tokens in real time. The user completes a login that looks entirely normal. Nothing breaks.
This technique is now commoditized. Open-source tools like Evilginx2, and phishing-as-a-service kits like EvilProxy and Tycoon 2FA, put it within reach of low-skill attackers. Proofpoint documented an EvilProxy campaign that sent 120,000 phishing emails to 100+ organizations in a single three-month window. Tycoon 2FA, disrupted by Microsoft and Europol in March 2026, had already facilitated unauthorized access across nearly 100,000 organizations globally.
- What this enables:
Real-time credential capture with no delay between user entry and attacker access - Immediate account access before the session expires
- MFA bypass via relay, with the OTP relayed rather than cracked
- Evasion of link-based detection tools, since the fake site uses a freshly registered domain with a valid TLS certificate
OTP relay and MFA bypass
In an OTP relay attack, the attacker sits between the user and the real login page. The user enters their OTP on the fake site; the attacker forwards it instantly to the legitimate service. The OTP is used once, as designed, by the attacker.
MFA is still functioning. It’s just functioning for the wrong person. Microsoft’s Entra Blog (November 2024) confirmed attackers use this technique to obtain a valid token and act until expiry.
DNS poisoning leading to phishing
DNS poisoning redirects a user’s request for a legitimate domain to an attacker-controlled IP. The user types the correct URL, sees a valid HTTPS connection, and has no reason to suspect anything. The fake site presents a real TLS certificate for its own domain. No suspicious link. No social engineering. The user did nothing wrong.
Detection isn’t about catching the DNS manipulation itself. It’s about identifying interaction with the resulting impersonation site.
Evil twin Wi-Fi
An evil twin attack creates a rogue Wi-Fi network matching a trusted SSID. Devices connect automatically, routing all traffic through attacker infrastructure.
The real damage happens at the application layer: session tokens intercepted, credentials captured, users redirected to phishing interfaces. Detection means spotting the abnormal login behavior and session anomalies that follow.
What this enables:
- Transparent traffic interception
- Session token theft
- Redirection to phishing interfaces
- Credential capture with no user indication
Session hijacking
Session hijacking skips the login entirely. No credentials, no OTP. Just a valid session token, captured through earlier interception or malware, then replayed against the real service. As CISA’s 2025 guidance on phishing-resistant authentication notes, session token theft allows adversaries to bypass authentication controls entirely, gaining access without supplying credentials. Authentication is no longer the control point.
What this enables:
- Post-authentication access without credentials or OTP
- Evasion of MFA and login-time controls
- Lateral movement across SSO-connected systems
Dive deeper into MitM
Preemptive Cybersecurity in Practice: Why Brand Impersonation Protection Can’t Wait for the Takedown
Why MitM attacks
bypass modern authentication defenses
The problem isn’t poor implementation. These defenses were never designed to stop an attacker already inside the authentication sequence.
- Passwords alone offer no protection against relay. Credentials are captured the moment a user types them into a spoofed interface. Password complexity is irrelevant.
- VPNs protect traffic between the user’s device and the VPN endpoint. They don’t prevent a user from connecting to a spoofed endpoint. The encrypted tunnel simply carries credentials to the attacker’s relay server.
- MFA and OTP are technically still functioning during a relay attack. The attacker receives the completed authentication result, not the raw secret. As Forrester noted in its analysis of the Odido breach, “phishing kits make it compelling for users to share credentials and accept MFA challenges.” MFA completes as intended. It just completes for the attacker. See how MFA bypass works in practice.
- Passkeys and FIDO2 are meaningfully stronger. Domain-bound credentials can’t be reused on a different domain, which blocks most reverse proxy phishing. The FIDO Alliance’s March 2025 white paper frames passkeys as a journey toward phishing resistance, not a single deployment event. They don’t eliminate DNS redirection, session hijacking, or advanced relay flows.
The gap isn’t a flaw in any single tool. These attacks operate across the authentication sequence. Closing it requires a detection layer that correlates signals in real time, not one that evaluates a single factor in isolation.
Industries most exposed to MitM-enabled attacks
MitM-enabled attacks don’t hit every industry equally. Exposure tracks two factors: the value of what’s being protected, and the strength of authentication already in place. Here’s the kicker: stronger authentication can increase attacker motivation to use relay techniques rather than brute force.
Banking and financial services
Strong authentication is already standard. That’s precisely why relay attacks are increasingly preferred. Attackers work around strong authentication rather than through it. Since January 2025, FBI IC3 received more than 5,100 ATO fraud complaints with losses exceeding $262 million, with financial institution impersonation as a primary vector.
Fintech and crypto platforms
Fast onboarding, high transaction velocity, and immediate financial consequence make these platforms high-value targets. Account access translates directly to financial loss, often before fraud detection systems trigger.
Healthcare and insurance
Patient portal credentials and insurance account access open the door to downstream fraud, identity theft, and prescription abuse. Security maturity is often lower relative to the value of what’s being protected.
Enterprise SaaS and identity providers
SSO compromise doesn’t affect a single account. It carries blast radius across every connected application.
Crush Atos Earlier, and Keep Them Crushed Longer
Discover why global brands replace their previous solution with Memcyco
How to detect MitM-enabled attacks: a signal-based framework
Signature-based tools, link scanners, and email gateways won’t catch these attacks. The HTTPS connection is valid. The domain may be newly registered but not yet flagged. Nothing is broken from the browser’s perspective.
Effective Man-in-the-Middle detection requires correlating behavioral and contextual signals in real time, not evaluating any single factor in isolation. As Javelin Strategy & Research notes, ATO risk signals are often subtle and hard to catch with authentication models that validate users only at login.
Six signal categories matter:
- Interaction with spoofed assets: users reaching impersonation infrastructure before credentials are submitted. This is the earliest detectable signal.
- Credential harvesting activity: anomalies in authentication request structure, timing, or origin suggesting a relay layer is present.
- Device and session inconsistencies: the attacker’s device initiates the real authentication, creating a detectable fingerprint mismatch.
- Timing anomalies: relay infrastructure introduces measurable latency between user action and server-side authentication event.
- Behavioral deviations: sequence, cadence, or method diverging from the user’s established patterns.
- Geographic and network anomalies: login origin inconsistent with the user’s current session context.
Detection alone isn’t enough. For account takeover prevention, these signals must be correlated and acted on in seconds. In relay-based attacks, the window between credential submission and account access is measured in seconds, not minutes. Alerts generated after the fact don’t close that gap.
MitM vs. related attack types: disambiguation for security teams
MitM is frequently conflated with adjacent attack types. The distinctions matter because the right detection approach differs for each.
Phishing
captures and stores credentials for later use. MitM-based phishing relays them in real time. The attacker authenticates immediately, closing the delay window standard phishing leaves open. Phishing is often the delivery mechanism that gets a user to the reverse proxy.
Account takeover (ATO)
is the outcome, not the technique. MitM is one of the most effective paths to ATO because it bypasses controls built to stop credential-based attacks.
Credential stuffing
uses previously breached credentials in bulk automated attempts, with no real-time interception involved. The two are often sequential: MitM harvests fresh credentials that later fuel stuffing campaigns.
Session hijacking
targets a valid authenticated session token, not credentials during login. Earlier MitM-based interception can create the conditions that make it possible.
Building a credible defense: what the detection layer must do
Most existing tools act too late. By the time a credential hits the real login endpoint, the relay has already happened. A credible detection layer has to start earlier.
That means correlating signals across the full authentication sequence in real time: device fingerprint, session context, timing anomalies, behavioral patterns, and network origin. No single factor is sufficient.
It also means individual victim visibility. Knowing a phishing campaign exists is not the same as knowing which users are actively at risk right now.
And it means acting within the seconds-long window relay attacks operate in. Blocking, step-up authentication, or risk score escalation must happen before access is granted, not after.
Platforms built for account takeover prevention and man-in-the-middle detection that combine these capabilities can meaningfully reduce ATO incidents and investigation time, replacing reactive remediation with preemptive prevention.
Conclusion
MitM attacks succeed because they don’t trigger the signals your stack was built to detect. Reverse proxy phishing produces valid certificates. OTP relay uses credentials exactly once. Session hijacking starts after authentication completes. Closing that gap requires detection at the session and device layer, not just at the credential layer.
See what your authentication stack is missing
Memcyco’s detects credential harvesting activity, interaction with impersonation infrastructure, and device and session anomalies that precede or accompany account takeover – in real time, before access is granted.
Fight real-time phishing, with advanced Man-in-the-Middle attack protection
Reduce ATOs
by at least
50%
Reduce mean time
to detection to
Zero
Slash incident-related
expenses by
$Millions
Already solved MitM attacks? Solve more

Account takeover (ATO)




Credential Stuffing


Remote desktop takeover


Fake e-shops, purchase scams, gift card scams

Get a Custom Demo
See it in action and discover why others switch to Memcyco
Get a demo to learn how Memcyco customer :
-
Identify individual scam victims in real-time
-
Predict and preempt ATO incidents
-
Deceive threat actors
Frequently asked questions
Can HTTPS protect against Man-in-the-Middle attacks?
HTTPS encrypts traffic in transit and verifies the server's identity via certificates, which protects against network-level interception between the user and the server. It does not protect against reverse proxy phishing, where the attacker's fake site presents a valid certificate for its own domain while relaying your credentials to the real site in real time. From the browser's perspective, the HTTPS connection is entirely legitimate - the padlock is green, the certificate is valid. Certificate transparency logs and browser trust mechanisms help identify suspicious domains after the fact but do not prevent users from interacting with spoofed domains that hold valid certificates.
What is the difference between a Man-in-the-Middle attack and a Man-in-the-Browser attack?
A Man-in-the-Middle attack operates at the network or application layer, intercepting or relaying communication between your browser and a remote server - the attacker's infrastructure sits between you and the legitimate service. A Man-in-the-Browser attack involves malware installed inside your browser that manipulates transactions or captures credentials locally, before they are even transmitted. Both can produce similar outcomes - credential theft, session compromise, unauthorized transactions - but the attacker's position differs significantly, and so does the appropriate detection approach. MitM attacks are detectable through network and session signal correlation; MitB attacks require endpoint-level detection.
Are passkeys safe from Man-in-the-Middle attacks?
Passkeys based on the FIDO2 standard are domain-bound, meaning a credential created for one domain cannot be used on a different domain - this makes them resistant to most reverse proxy phishing scenarios where the attacker's fake site has a different domain than the legitimate service. The FIDO Alliance's March 2025 white paper frames passkey adoption as a journey toward phishing resistance, not a single deployment event. However, passkeys do not eliminate risks from DNS redirection scenarios, session hijacking, or cases where your device or session is already compromised before authentication. They significantly raise the bar for attackers but are not a complete defense on their own - a detection layer addressing post-authentication and session-level risks remains necessary.
What is an OTP relay attack and how does it bypass MFA?
An OTP relay attack works by placing a phishing interface between you and the legitimate login page - when you enter your one-time password on the fake site, the attacker immediately forwards it to the real service and uses the resulting authenticated session to access your account. The OTP itself is never reused or cracked; it is used exactly once, as designed, just by the attacker instead of you. The relay is typically automated, closing the gap between your OTP entry and the attacker's authentication attempt to near-zero - well within the 30-60 second validity window of most TOTP implementations. This is why MFA alone is insufficient against relay-based attacks: MFA verifies possession of the credential, but it cannot verify that the authentication session itself has not been intercepted.
How do attackers use DNS poisoning to enable phishing?
DNS poisoning manipulates the DNS resolution process so that your request for a legitimate domain resolves to an attacker-controlled IP address - you type the correct URL, but your browser connects to a fake site. The attacker's site may present a valid TLS certificate for its own domain, so you see a secure HTTPS connection with no visible warning. Unlike standard phishing, you made no error: you did not click a suspicious link or misread a URL. Detection requires identifying interaction with the resulting spoofed site - through behavioral signals, device anomalies, or known impersonation infrastructure - not the DNS manipulation event itself, which occurs upstream of the user's browser.