Adversary-in-the-middle attacks: The threat that makes your MFA useless

For years, security teams have treated MFA as the definitive answer to credential theft: even if an attacker gets the password, they still need the second factor to get in. That assumption held up well against traditional phishing, brute force, and credential stuffing. It does not hold up against Adversary-in-the-Middle attacks.

AiTM is not a theoretical concern or a niche technique used by a handful of nation-state groups. Phishing kits with built-in AiTM capabilities are now sold as subscriptions. Open-source frameworks make it possible to stand up a fully functional attack in an afternoon. The Canadian Centre for Cyber Security documented over 100 AiTM campaigns targeting Microsoft Entra ID accounts between 2023 and early 2025 alone, and research from Obsidian Security found that 84% of the accounts compromised through these techniques already had MFA enabled. The attacks are not bypassing weak security. They are bypassing the security measure most organizations consider strong.

This article breaks down how AiTM attacks work, what distinguishes them from the classic Man-in-the-Middle attacks that preceded them, why traditional defenses fail against them, and what actually works to detect and stop them. It also covers the role that phishing-resistant authentication (like passkeys) and real-time behavioral detection play in closing the gap that AiTM exploits.

What is an Adversary-in-the-Middle attack?

An Adversary-in-the-Middle (AiTM) attack is a phishing technique where an attacker positions a reverse proxy server between a user and a legitimate service. Rather than presenting a static fake login page that simply collects a username and password, the proxy relays all traffic to the real service in real time. The user sees the actual login page, enters their credentials, completes their MFA challenge, and goes about their day. The attacker, meanwhile, captures everything that passes through the proxy, including the session cookie that the legitimate service issues after authentication succeeds.

That session cookie is the real prize. It acts as a temporary key that tells the service "this user has already been verified." Once an attacker has it, they can inject the cookie into their own browser and access the victim's account from anywhere in the world without ever needing to re-authenticate. MFA has already been satisfied. The attacker is in.

The term "Adversary-in-the-Middle" comes from the MITRE ATT&CK framework (technique T1557), which uses the word "adversary" to emphasize that the person in the middle is an active, malicious threat actor, not a passive eavesdropper.

How AiTM attacks work

The anatomy of a typical AiTM attack follows a predictable chain, but each link is designed to be invisible to the victim.

1. ‍The lure. The attack starts with a phishing email. These are not the poorly formatted messages of a decade ago. Modern AiTM campaigns use compromised business email accounts to send messages that look like they come from trusted colleagues or partners. A common pattern involves a link to a file hosted on a legitimate platform like SharePoint or Dropbox. The file itself contains a secondary link that redirects the victim to the attacker's proxy infrastructure. Because the initial link points to a trusted domain, email security gateways often let the message through.‍
2. The proxy. When the victim clicks through and reaches the attacker's server, they see what looks exactly like a normal login page for Microsoft 365, Google Workspace, Okta, or whatever identity provider the attacker is targeting. This is not a screenshot or a clone. The attacker's reverse proxy is fetching the real login page from the real service and forwarding it to the victim. Every element on the page is genuine because it is being served from the genuine source.‍
3. The authentication relay. The victim types in their email address. The proxy forwards it to the real identity provider. The victim enters their password. The proxy forwards it. The identity provider prompts for MFA. The victim completes the challenge, whether it is an authenticator app code, a push notification, or an SMS one-time password. The proxy forwards that too. At no point does the user interact with anything fake. Every response comes from the real service, passed through the proxy.‍
4. The session hijack. After the victim successfully authenticates, the identity provider issues a session cookie. This cookie flows back through the proxy, and the attacker captures a copy before forwarding it to the victim's browser. The victim lands in their inbox or dashboard, unaware that anything happened. The attacker now has a fully authenticated session.‍
5. Post-compromise activity. With the stolen session, attackers move quickly. Common next steps include registering a new MFA device on the account (to establish persistence), setting up email forwarding rules (to monitor communications), launching business email compromise schemes (to redirect payments or extract sensitive data), and exfiltrating documents from cloud storage. Because the session is legitimate, these actions often do not trigger the alerts that a brute-force attack or a login from an unfamiliar location would.

AiTM vs. classic Man-in-the-Middle: What changed

Man-in-the-middle (MitM) attacks have existed for decades. The classic version involves intercepting network traffic between two parties, typically by exploiting insecure Wi-Fi, performing ARP spoofing, or manipulating DNS resolution. The attacker eavesdrops on unencrypted traffic or attempts to downgrade encrypted connections to steal data in transit.

AiTM attacks are a fundamentally different animal. While they share the structural concept of sitting between two communicating parties, the mechanics, targets, and capabilities diverge sharply.

• ‍Layer of attack. Classic MitM operates at the network layer. It relies on intercepting raw traffic between devices. AiTM operates at the application layer. It targets the authentication flow itself, which means encryption (HTTPS, TLS) does not help. The proxy terminates the TLS connection on both sides, establishing one encrypted session with the victim and another with the legitimate service.‍
• Relationship with MFA. Classic MitM attacks were largely neutralized by the widespread adoption of HTTPS and MFA. If traffic is encrypted and credentials alone are not enough to gain access, network-level interception loses much of its value. AiTM attacks were designed specifically to defeat MFA. By relaying the entire authentication ceremony in real time, they capture the post-MFA session token that grants access.‍
• Sophistication and targeting. Classic MitM is often opportunistic. An attacker sets up a rogue Wi-Fi hotspot and waits for someone to connect. AiTM attacks are targeted. They begin with carefully crafted phishing campaigns aimed at specific organizations, often using compromised trusted accounts to deliver the lure.‍
• Detection difficulty. Network-level MitM attacks can be detected by monitoring for ARP anomalies, unexpected certificate changes, or suspicious network behavior. AiTM attacks are much harder to spot because the proxy relays legitimate traffic. From the service's perspective, the login looks normal. From the user's perspective, everything works as expected. Security logs may show a successful authentication with valid MFA, making the compromise nearly invisible through traditional monitoring alone.

The industrialization of AiTM

What makes AiTM attacks particularly alarming is how accessible they have become. The tools required to launch these attacks are openly available, well documented, and increasingly commercialized.

Evilginx is the most prominent example. Originally developed as a penetration testing tool, it is an open-source reverse proxy framework written in Go that includes its own HTTP and DNS servers. It uses configuration files called "phishlets" that define how to proxy specific services. Pre-built phishlets exist for Microsoft 365, Google Workspace, Okta, Amazon, LinkedIn, and dozens of other platforms. Setting up an AiTM phishing campaign with Evilginx requires minimal technical skill.

Beyond Evilginx, the Phishing-as-a-Service (PhaaS) ecosystem has industrialized AiTM capabilities. Toolkits like Tycoon 2FA and Rockstar 2FA offer subscription-based access to ready-made AiTM infrastructure, complete with pre-built templates, hosting, automation for harvesting credentials and session cookies, and evasion techniques like CAPTCHAs and bot-detection on the phishing page itself to prevent security researchers from analyzing the attack. AiTM attacks saw a 46% increase in 2025, driven largely by this commoditization.

The barrier to entry is now remarkably low. An attacker does not need to understand reverse proxy architecture or session management. They rent a toolkit, pick a target, send a phishing email, and wait.

The impact

The consequences of a successful AiTM attack extend well beyond a single compromised account.

• ‍Account takeover at scale. Microsoft's threat intelligence reports have documented AiTM campaigns targeting over 10,000 organizations. Financial services, healthcare, higher education, and government entities are particularly vulnerable because of the sensitivity of the data they handle and the value of the accounts they manage.‍
• Business email compromise. Once inside a corporate email account, attackers monitor internal communications, identify financial processes, and inject themselves into payment workflows. They impersonate executives to authorize wire transfers or modify vendor payment details. The FBI's Internet Crime Complaint Center has consistently ranked BEC among the costliest forms of cybercrime.‍
• Lateral movement and persistence. A compromised admin account is especially dangerous. Attackers can escalate privileges, create backdoor accounts, disable security policies, and move laterally across the organization's cloud environment. When the initial entry point is a legitimate session cookie, the attacker's presence can persist for days or weeks before anyone notices.‍
• Erosion of trust in MFA. Perhaps the most insidious impact is psychological. Organizations that invested in MFA as their primary defense against credential theft discover that it is not enough. This can lead to security fatigue and a dangerous assumption that if MFA can be bypassed, nothing works.

How to detect AiTM attacks

AiTM attacks are hard to detect precisely because they blend in with legitimate traffic. However, they do leave signals that a well-instrumented environment can catch.

Impossible travel

‍This is one of the highest-signal detections available for identifying session hijack from AiTM attacks. After an attacker captures a session cookie, they replay it from their own location, which is almost certainly not the same city or country as the victim. If a user authenticates from New York at 10:00 AM and someone uses that session from Lagos at 10:05 AM, no human being traveled that distance in five minutes. Impossible travel detection flags exactly this pattern: sequential authentication events from locations that are geographically incompatible with the elapsed time between them.

The challenge is doing it well. Naive implementations produce a flood of false positives from VPN users, mobile workers, and distributed teams. Effective impossible travel detection requires correlating geolocation data with device fingerprinting. A location change from the same device (indicating a VPN switch) is very different from a location change on a completely different device (indicating a stolen session). WorkOS Radar takes this approach. Built on top of AuthKit, Radar analyzes over 20 device signals to fingerprint each client and tracks geolocation across every authentication event. When it detects an impossible travel scenario, the response is configurable: block the attempt, challenge the user with an email OTP, or send notifications to users and admins. Importantly, Radar supports custom allow lists for known VPN exit points and works alongside other detections like bot detection, brute force protection, and credential stuffing defense, so an impossible travel event from an unrecognized device on a dormant account paints a much richer picture than a geolocation anomaly alone.

Anomalous session behavior

‍Beyond location, look for sessions that suddenly change user agents, begin accessing resources the user has never touched before, or start creating mail forwarding rules. These post-compromise behaviors are where many AiTM attacks become visible. Attackers who gain access through a stolen session cookie tend to follow a recognizable playbook: they register a new MFA device on the account to establish persistence, create inbox rules to forward or hide specific messages (especially those related to financial transactions or security alerts), and begin accessing SharePoint, OneDrive, or other cloud storage to exfiltrate documents. A user who has never touched the Azure AD admin portal suddenly accessing it at 2 AM, or a session that switches from a Windows desktop user agent to a Linux-based one mid-session, should be treated as high-priority signals. Monitoring for new MFA device registration events shortly after authentication is one of the most reliable post-compromise indicators, because it is almost always the attacker's first move to ensure they retain access even after the stolen session expires.

Phishing infrastructure indicators

‍Newly registered domains, domains with low reputation scores, and URLs that mimic SSO login pages are all signals. Some organizations have had success analyzing DNS patterns associated with known AiTM toolkits. The Canadian Centre for Cyber Security documented over 100 AiTM campaigns between 2023 and 2025 and found that tracking domain registration patterns was one of the most effective early warning signals. AiTM toolkits like Evilginx use wildcard TLS certificates and generate subdomains that closely resemble legitimate SSO addresses, often with random alphanumeric strings appended to the path. Monitoring for domains that were registered within the past 30 days and that resolve to IP ranges associated with known hosting providers for phishing infrastructure can surface campaigns before they reach your users. Threat intelligence feeds that track indicators of activity (IoAs) specific to AiTM kits, such as the DNS fingerprints of Evilginx phishlets, add another layer of early detection. Organizations with mature security operations can also look for TLS certificate registrations that impersonate their brand or SSO domain names, using certificate transparency logs to catch infrastructure setup before the first phishing email is even sent.

Email-layer signals

‍Phishing emails that initiate AiTM attacks often use uncommon sender domains, contain links to URL shorteners, or route through legitimate file-sharing services to evade gateways. Precision-validated phishing, where the attacker verifies the target's email is valid before serving the phishing page, is becoming more common and is a useful indicator that an attack is highly targeted. One of the more effective evasion patterns observed in recent campaigns involves vendor email compromise: the attacker compromises a legitimate organization's email account first, then uses that trusted account to send phishing links to the victim's contacts. Because the email comes from a real address that the recipient has corresponded with before, it sails past reputation-based filters. The phishing link itself often points to a file hosted on a trusted service like SharePoint or Dropbox, with the actual malicious URL buried inside the hosted document rather than in the email body. Detecting this pattern requires looking beyond sender reputation and analyzing the intent and destination of every link, flagging mismatches between the sender's display name and their actual address, and scrutinizing emails that create urgency around authentication actions like password resets, shared document access, or account verification. Many modern AiTM phishing pages also deploy their own anti-analysis defenses, including CAPTCHAs, turnstiles, and IP filtering designed to block security scanners while letting real victims through.

How to mitigate AiTM attacks

Not every defense is equally effective against AiTM. Some measures that work well against classic phishing or MitM attacks provide little protection here.

Phishing-resistant authentication with passkeys

The single most effective mitigation against AiTM attacks is to eliminate the credentials and tokens that the proxy captures. Passkeys, built on the WebAuthn/FIDO2 standard, accomplish this through a fundamentally different authentication model.

When a user registers a passkey, their device generates a cryptographic key pair. The private key stays on the device, protected by biometric verification or a device PIN. The public key is stored by the service.

During authentication, the service sends a challenge, the device signs it with the private key, and the service verifies the signature with the public key. The private key never leaves the device and is never transmitted over the network.

This matters for AiTM defense because of a property called origin binding. The browser will only present the passkey to the exact domain it was registered on. If a user registered a passkey for login.example.com, and an attacker's proxy is serving the page from evil-proxy.com, the browser refuses to use the passkey. The cryptographic ceremony cannot be completed through the proxy. There is no credential to steal, no OTP to relay, and no session cookie to hijack during authentication.

NIST now recognizes synced passkeys as phishing-resistant, placing them alongside FIDO2 security keys as the strongest form of authentication currently available.

WorkOS supports passkey authentication through AuthKit, including progressive enrollment that prompts password-based users to create a passkey on their next sign-in. For organizations that require it, AuthKit treats passkeys as both a first and second factor by requiring user verification (a biometric or PIN) when a passkey is presented, so users who sign in with a passkey are not prompted for a separate TOTP code.

One important caveat: passkeys protect the authentication layer, not the entire security surface. If an attacker gains access through other means (a compromised OAuth consent flow, endpoint malware, or a social engineering attack that does not involve phishing credentials), passkeys will not help. Phishing resistance is a property of the entire authentication chain, not just the strongest method in the chain. If your system still allows password-based recovery flows or SMS-based fallbacks alongside passkeys, attackers will target those weaker paths.

Conditional access policies

Restricting authentication to managed or compliant devices is an effective complementary control. If your identity provider only issues sessions to devices that meet specific criteria (enrolled in MDM, running current OS versions, disk encryption enabled), an attacker replaying a stolen session from an unmanaged device will be blocked. This does not prevent the initial session theft but limits the attacker's ability to use it.

The logic is straightforward: even if an attacker captures a valid session cookie through an AiTM proxy, they need to replay it from their own machine. If your conditional access policy requires that the device be enrolled in your organization's mobile device management platform or that it pass a health check (up-to-date patches, active endpoint protection, compliant configuration), the attacker's unmanaged laptop will fail those checks and the session will be rejected. Microsoft Entra ID, Okta, and Google Workspace all support device compliance policies that can be layered on top of authentication. The key is to enforce these policies not just at the initial sign-in but on every resource access request throughout the session, so that a stolen cookie cannot be used to silently access downstream services like email, file storage, or admin portals from a device that was never registered.

Token binding and continuous access evaluation

Some identity providers support binding session tokens to specific device properties, making stolen cookies unusable on other machines. Continuous access evaluation protocols can revoke sessions in near real time when risk signals change, such as a session suddenly appearing from a new location or device.

Token binding works by cryptographically tying a session token to the TLS connection or device that originally requested it. If an attacker extracts the cookie and tries to present it from a different machine with a different TLS fingerprint, the server rejects it. This is one of the most direct defenses against session replay because it attacks the core mechanism AiTM relies on: the portability of stolen cookies. The challenge is that token binding support is not yet universal across browsers and identity providers, and implementation varies. Microsoft's token protection policy in Entra ID is one of the more mature examples, allowing organizations to require that sign-in session tokens are bound to the device they were issued to.

Continuous access evaluation (CAE) complements token binding by re-evaluating risk throughout the lifetime of a session rather than only at the moment of authentication. In a traditional model, once a session cookie is issued, it remains valid until it expires, regardless of what happens in the meantime. CAE changes this by allowing the identity provider to push revocation events to resource providers in near real time. If a user's risk level changes (their account is flagged as compromised, their location shifts unexpectedly, or an admin revokes their session), access can be cut off within minutes rather than waiting for the token to expire. For AiTM defense, CAE is particularly valuable because it shrinks the window during which a stolen session is usable, even if the attacker manages to bypass other controls.

Reducing session lifetimes

Shorter session lifetimes limit the window during which a stolen cookie is valid. This is a tradeoff with user experience (nobody wants to re-authenticate every 15 minutes), but for high-privilege accounts, aggressive session policies meaningfully reduce risk.

The calculus here is simple: if a session token is valid for 24 hours, an attacker who steals it at 9 AM has until the next morning to exfiltrate data, register persistence mechanisms, and move laterally. If the token expires in one hour, the attacker has a fraction of that time and must work under pressure, increasing the likelihood of triggering behavioral detection. For standard users, a reasonable middle ground might be sessions that last several hours but require step-up authentication for sensitive actions like changing security settings, accessing admin consoles, or initiating financial transactions. For privileged accounts (global admins, finance roles, IT infrastructure managers), shorter session lifetimes of 30 to 60 minutes, combined with re-authentication requirements for high-risk actions, can dramatically reduce the blast radius of a compromised session. The key is to apply session lifetime policies in tiers based on role and risk rather than uniformly across the organization, so that security improvements do not come at the cost of making the product unusable for the majority of your users.

Security awareness training

Users remain the first line of defense against the phishing emails that initiate AiTM attacks. Training should evolve beyond "look for the padlock" advice, which is ineffective when the attacker's proxy serves real content over valid TLS. Instead, train users to verify URLs carefully, be suspicious of unexpected authentication prompts, and report emails that create urgency around login actions.

AiTM phishing is harder to spot than traditional phishing because the experience feels completely normal. The login page is real, the MFA prompt is real, and the session works afterward. The only anomaly is the URL in the browser's address bar, which will belong to the attacker's proxy domain rather than the legitimate service. Training should focus on this specific behavior: checking the full domain before entering credentials, not just looking for a padlock icon or HTTPS prefix. Users should also be trained to recognize the social engineering patterns that AiTM campaigns rely on, such as emails claiming a shared document requires immediate review, messages warning of account suspension that link to a login page, or requests from colleagues that arrive from unfamiliar or slightly altered sender addresses. Running simulated phishing exercises that mimic AiTM lure patterns (redirects through trusted file-sharing services, urgency around authentication) gives users practice spotting the real thing. And critically, organizations should make reporting easy and consequence-free. The faster a user reports a suspicious email, the faster the security team can investigate and block the campaign before more users click through.

AiTM defense checklist

The sections above cover a lot of ground. Here is everything in one place, organized by when it matters in the attack chain.

Prevent the authentication from being proxied

• Deploy passkeys (WebAuthn/FIDO2) as a first-class authentication method. Origin binding prevents credentials from being relayed through an attacker's proxy.
• Enable progressive passkey enrollment so password-based users are prompted to register a passkey on their next sign-in.
• Audit your MFA fallback surface. If password resets, SMS recovery, or TOTP fallbacks still exist alongside passkeys, attackers will target those weaker paths.
• Evaluate whether the QR code cross-device authentication flow should be disabled in your environment, as it has been exploited to bypass FIDO2 protections.

Limit what attackers can do with a stolen session

• Enforce conditional access policies that require device compliance (MDM enrollment, OS version, disk encryption) on every resource access request, not just at initial sign-in.
• Enable token binding to tie session cookies to the device and TLS connection that originally requested them, making stolen cookies unusable on other machines.
• Implement continuous access evaluation (CAE) so sessions can be revoked in near real time when risk signals change.
• Reduce session lifetimes for privileged accounts (global admins, finance roles, infrastructure managers) to 30 to 60 minutes.
• Require step-up authentication for sensitive actions like changing security settings, accessing admin consoles, or initiating financial transactions.

Detect compromised sessions after the fact

• Enable impossible travel detection to flag sequential authentication events from locations that are geographically incompatible with the elapsed time. Correlate with device fingerprinting to distinguish VPN switches from stolen sessions.
• Monitor for new MFA device registrations shortly after authentication. This is almost always the attacker's first move to establish persistence.
• Alert on new inbox rules, especially mail forwarding rules or rules that auto-delete or move messages related to security alerts and financial transactions.
• Watch for sessions that change user agents mid-session, or that begin accessing resources the user has never touched before.
• Track dormant accounts that suddenly become active, particularly if the activity comes from an unrecognized device or location.

Catch the phishing campaign before users click

• Monitor for newly registered domains that mimic your SSO or login page URLs. Use certificate transparency logs to detect impersonation infrastructure before phishing emails are sent.
• Integrate threat intelligence feeds that track indicators of activity specific to AiTM toolkits like Evilginx, Tycoon 2FA, and Modlishka.
• Configure email gateways to analyze link destinations rather than just sender reputation. Look for redirects through trusted file-sharing services that lead to external domains.
• Flag emails that create urgency around authentication actions (password resets, shared document access, account verification) from uncommon or recently compromised sender addresses.

Build a culture that catches what automation misses

• Train users to check the full domain in the address bar before entering credentials, not just the padlock icon.
• Run simulated phishing exercises that mimic AiTM lure patterns: redirects through SharePoint or Dropbox, urgency around login, messages from familiar contacts.
• Make reporting easy and consequence-free. The faster a suspicious email is reported, the faster the security team can block the campaign.

A layered approach

No single control defeats AiTM attacks in isolation. The most resilient posture combines:

• phishing-resistant authentication (to break the proxy's ability to relay credentials)
• impossible travel and device fingerprinting (to detect when stolen sessions are replayed from unexpected locations)
• conditional access and token binding (to limit what attackers can do with captured sessions), and
• continuous monitoring (to catch post-compromise behaviors like MFA device registration or mail rule creation)

The tooling to implement this layered approach is available today. WorkOS covers several of these layers through AuthKit's passkey support and Radar's detection engine, including impossible travel, device fingerprinting, bot detection, and credential stuffing protection. For the controls that live outside the authentication layer, such as endpoint management, email gateway hardening, and network monitoring, the right combination will depend on your stack and threat model.

AiTM attacks succeed because they exploit a gap between what users see and what actually happens during authentication. Closing that gap requires moving beyond credentials that can be intercepted and sessions that can be replayed. The technology exists. The question is whether your authentication stack uses it.