Adversary-in-the-Middle attacks: Detection and prevention measures

A user completes MFA. They enter a password, approve the push notification, and get into their account as expected. What they don't know is that an attacker sat between them and their account the entire time, silently copying their session cookie. By the time the login completes, the attacker has already authenticated as that user without needing credentials or a second factor. This is an adversary-in-the-Middle attack, and it's why "we have MFA" is no longer a complete answer to security risks.

What is an adversary-in-the-middle attack?

An adversary-in-the-Middle (AiTM) attack is a phishing technique that positions an attacker's infrastructure between a user and a legitimate authentication service, intercepting session credentials in real time. Unlike attacks that try to crack passwords or break encryption, AiTM doesn't need to. It waits for the user to authenticate successfully, then performs session cookie theft by stealing the token that gets issued as proof of the completed login. With that cookie, an attacker can access an account as the legitimate user, with no password and no second factor required.

The term "adversary-in-the-middle" distinguishes this class of attack from traditional man-in-the-middle (MitM) interception. The adversary isn't intercepting network traffic between two parties. They're inserting themselves into the authentication flow itself, operating as a transparent relay that captures credentials and session state simultaneously.

How are AiTM attacks different from MitM?

Traditional MitM attacks are about intercepting traffic at the network layer. The classic playbook involves ARP spoofing to redirect traffic on a local network, DNS spoofing to point domains at attacker-controlled servers, and packet sniffing to capture data in transit. This is often executed over unsecured connections where Wi-Fi eavesdropping requires little more than being on the same network. SSL/TLS stripping was another common technique: downgrading HTTPS connections to HTTP so that credentials passed in plaintext could be captured directly.

Widespread TLS adoption largely neutralized that approach. Encrypted connections meant packet sniffing yielded ciphertext, not credentials. ARP and DNS spoofing still work at the network layer, but they can't read traffic that's properly encrypted end-to-end.

AiTM attacks emerged as the response to that hurdle. Rather than trying to break encryption, AiTM abuses the trust that authentication systems extend to session tokens. When a user authenticates on a web application, the server issues a session cookie that proves "this browser already logged in." In a classic session, that cookie is valid for hours or days. AiTM attacks are designed to steal that cookie at the moment it's issued, then replay it from the attacker's machine to impersonate the authenticated user without a password or second factor.

The key architectural difference is intent. Classic MitM is opportunistic interception of network traffic. AiTM is a targeted authentication bypass, engineered specifically to defeat the MFA layer that organizations have invested heavily in deploying. It doesn't need to be on the same network. It doesn't need to see a single packet in transit. A phishing email does the positioning.

How attackers execute an AiTM attack  

The reverse proxy technique  

The most prevalent AiTM method uses a reverse proxy server controlled by the attacker. A phishing email delivers a link that looks like a legitimate login page for services such as Microsoft, Google, Dropbox, or any identity provider (IdP) the target uses. But instead of pointing to the real login page, the link points to the attacker's proxy.

Here's what happens in sequence:

1. The victim visits the attacker's proxy, which forwards the request to the legitimate IdP in real time.
2. The real login page is rendered through the proxy. Even though the URL may look suspicious, many users don't check.
3. The victim enters credentials and completes MFA. The proxy transparently passes all of this to the real IdP.
4. The IdP issues a valid session cookie and returns it through the proxy to the victim's browser.
5. The proxy intercepts and copies that session cookie before forwarding it to the victim.

The attacker now holds a fully authenticated session token. They can import it into their own browser and operate as the victim, accessing email, files, and connected apps without triggering another authentication prompt.

This threat is amplified in environments where employees access corporate accounts over public Wi-Fi. On an unsecured network, traffic can be monitored more easily, and users are often less vigilant about URL inspection. An employee logging in from a hotel lobby or airport lounge is less likely to scrutinize a slightly-off domain in the address bar, which is exactly the inattention AiTM phishing depends on.

Tools that automate this attack are freely available. Evilginx, Modlishka, and Muraena are open-source frameworks built specifically for reverse-proxy phishing. Evilginx, in particular, has been deployed against Microsoft 365, Google Workspace, GitHub, and dozens of other platforms. Defenders should assume attackers have already tested these tools against their IdP.

Browser-in-the-browser phishing as a delivery mechanism  

A secondary technique that's commonly used is browser-in-the-browser (BitB) phishing. This is a social engineering method, not a network attack. Attackers craft a fake browser window that looks complete with a rendered URL bar inside a legitimate webpage using HTML and CSS. The fake window mimics a real SSO pop-up, making users believe they're logging in through a trusted OAuth flow.

BitB doesn't perform the interception itself; it's a delivery technique that makes the credential entry step more convincing, often used in combination with reverse proxy infrastructure to capture both credentials and session tokens in one flow.

Real-world business impact  

AiTM attacks aren't theoretical. In 2022, Microsoft documented a large-scale AiTM phishing campaign that compromised more than 10,000 organizations in a single operation. Attackers targeted Microsoft 365 users, stole session cookies post-authentication, then immediately accessed victim email accounts to conduct business email compromise (BEC) fraud—intercepting financial conversations and redirecting wire transfers.

The attack chain compressed what used to be a multi-stage operation into something that can unfold in minutes: A phishing email is opened; the user authenticates their identity securely; the session token is stolen; the attacker accesses the victim's inbox, monitors payment discussions, and issues fraudulent wire instructions, all before the IT team receives an alert.

For businesses, the exposure is not just financial. A compromised executive email account can be used to exfiltrate sensitive data, pivot into connected SaaS platforms through OAuth tokens, and move laterally through an organization before detection. Because the session is technically legitimate, standard security tools often don't flag it as anomalous during the initial access phase.

AiTM attack detection: What to watch for  

Detection requires behavioral signals, not just credential alerts, because the authentication event itself looks clean.

Session anomalies

Look for authenticated sessions where the IP address immediately after login differs from the IP used during the authentication handshake. When a user completes MFA from a corporate network in India but the session is active from a datacenter IP in Frankfurt 30 seconds later, it's safe to assume that something is wrong.

Impossible travel detections

Impossible travel detections catch the same pattern at a higher level. Most SIEM and CASB platforms have this rule built in. The challenge is tuning it to reduce false positives from VPN usage while staying sensitive to genuine session hijacking events.

Token replay indicators 

Token replay indicators are more specific. Look for:

• New device fingerprints appearing immediately after successful authentication, particularly from cloud-hosted IPs or known VPN/proxy ranges
• Sessions where the user-agent string changes between the authentication event and subsequent API calls
• High-volume email access or forwarding rule creation in the minutes immediately following a new session

Phishing infrastructure signals

Phishing infrastructure signals can provide an earlier warning. AiTM proxy infrastructure tends to use newly registered domains, certificates issued within days of the attack, and hosting on cloud providers. Threat intelligence feeds that flag these indicators can help email security tools block the initial phishing delivery before the attack chain begins.

AiTM proxy URLs follow recognizable patterns. This could occur as subdomains engineered to look like legitimate identity provider addresses but are resolving to attacker infrastructure. An email security solution that logs link click events and resolves redirect destinations can flag these before a session is ever established.

Prevention measures: What works and what doesn't

The MFA limitation to acknowledge

TOTP codes, SMS OTP, and push-notification MFA all fail against AiTM attacks. This is not a flaw in those implementations; it's an architectural limit. These factors prove that the person has a second device or token, but they don't prove that the person is connecting directly to the legitimate service. The proxy intercepts the factor alongside the credential and uses both in real time.

This is uncomfortable for organizations that have treated MFA rollout as the finish line for phishing protection. However, this doesn't always apply and AiTM has moved the threat past it.

FIDO2 and passkeys: The controls that actually block AiTM

FIDO2-based authentication and passkeys are the most reliable technical countermeasures against AiTM attacks. They are phishing-resistant by design because the cryptographic authentication is bound to the origin, which is the specific domain the browser is communicating with.

When a user authenticates with a FIDO2 key or a passkey, the authenticator verifies that the origin in the authentication request matches the registered domain. An attacker's proxy operates on a different domain. The challenge-response fails. The session token is never issued for the attacker to steal.

Deploying FIDO2 across an organization isn't frictionless, particularly for legacy applications. But for high-value accounts such as executives, finance, IT administrators, and anyone with access to sensitive systems, it should be a priority.

Conditional access policies  

Conditional access doesn't stop AiTM at the authentication layer, but it limits what an attacker can do with a stolen token. Effective policies to configure:

• Token binding and device compliance checks that require sessions to originate from managed, compliant devices. Attackers operating from cloud VPS infrastructure fail these checks.
• Sign-in risk policies that step up authentication requirements when risk scores are elevated by unusual IP addresses or behavioral signals.
• Session lifetime limits that force re-authentication frequently enough to reduce the useful window for a stolen token.

No conditional access policy eliminates the risk entirely, but in combination, they raise the cost and complexity of converting a stolen token into persistent access.

Email security as a prevention layer  

AiTM attacks depend on phishing emails for delivery. Disrupting that delivery layer is prevention at the earliest possible stage in the attack chain, before any credential or token is at risk.

Email security platforms that evaluate link destinations at click time and not just at delivery are particularly effective here, because attacker infrastructure is often not yet classified as malicious when the email arrives but is flagged by the time the user clicks hours or days later. URL rewriting and sandbox analysis of linked pages can catch reverse proxy infrastructure that credential theft depends on.

Domain-based authentication policies (SPF, DKIM, DMARC) don't block AiTM directly, but they reduce an attacker's ability to impersonate trusted senders in the initial phishing email, increasing the detection burden for the attacker before the campaign even launches.

AiTM is a volume threat, not just a targeted one

Security teams often model AiTM as a sophisticated, targeted threat. In reality, the barrier to entry has dropped significantly. AiTM-as-a-service kits are available on criminal forums for a few hundred dollars. Evilginx configurations called "phishlets" are available for specific platforms and are shared openly. This means AiTM is no longer the exclusive domain of nation-state actors or advanced persistent threat groups targeting specific organizations. It is a volume threat.

That reframing matters for prioritization. Organizations waiting to deploy FIDO2 until there's evidence of being specifically targeted are waiting too long. The phishing campaigns that use AiTM techniques run at scale against any organization, regardless of industry or size.

Wrapping up 

The organizations that detect AiTM quickly are the ones that monitor session behavior, not just authentication events, and that have tuned their alerting to flag geographic and device anomalies immediately after sign-in. The ones that prevent it are moving their highest-risk users to FIDO2 and hardening their email security stack to disrupt delivery before a link is ever clicked. The prudent approach would be to address that email delivery layer directly by combining link-time analysis, threat intelligence, and email authentication enforcement to cut off AiTM campaigns at their starting point.

eProtect is a cloud-based email security and archiving solution that protects your organization from AI-based email threats. The solution offers advanced threat detection mechanisms to protect on-premise and cloud email accounts from evolving email threats. eProtect is the security solution that powers Zoho Mail, a platform that millions of users trust.