Key Insights
Organizations spent years and real budget deploying multi-factor authentication (MFA) on the assumption that a stolen password alone wouldn't be enough to get an attacker into an account. Adversary-in-the-middle (AiTM) attacks break that assumption. Rather than guessing a second factor, an AiTM attack sits between the user and the real login page and waits for the user to complete authentication, MFA included, before capturing the session token the service issues afterward. From that point, the attacker holds a valid, authenticated session and doesn't need the password or the MFA code again.
This is a different threat than traditional man-in-the-middle attacks, which intercept network traffic. AiTM operates one layer up, at the authentication exchange itself, which is exactly why network-focused defenses tend to miss it. Security teams need to treat authentication as a full process with a session lifecycle, not a single pass/fail event at login.
Insights in this article draw from the webinar "Supercharged Deception: How AI Is Accelerating Social Engineering," featuring cyberpsychologist Dr. Mary Aiken and Abnormal's E.J. Whaley.Watch the full recordingfor more on AI-powered threats and human-centered defense.
Key Takeaways
Adversary-in-the-middle attacks capture the session token issued after a user completes MFA, which means traditional MFA methods reduce password-based risk without closing the session-hijacking gap.
Phishing-resistant authentication such as FIDO2, WebAuthn, and passkeys defeats the AiTM proxy path by cryptographically binding the login to the legitimate domain, something SMS codes, app tokens, and push notifications cannot do.
Phishing-as-a-service platforms have packaged AiTM infrastructure into commodity kits, which has turned what used to require specialized skill into a repeatable, scalable attack available to far more threat actors.
A layered defense pairs authentication upgrades for high-risk users with session monitoring, email threat detection, and a culture that rewards employees for verifying unusual requests rather than penalizing them for asking questions.
What Is an Adversary-in-the-Middle Attack?
An adversary-in-the-middle (AiTM) attack positions a threat actor's reverse proxy between a user and a legitimate service so the attacker can capture credentials and the session token that follows successful authentication.
The name invites comparison to traditional man-in-the-middle attacks, but the two operate at different layers. Traditional MitM attacks typically exploit unencrypted communications, weak protocols, or a compromised network position, such as a rogue wireless access point or ARP spoofing, to intercept traffic. AiTM attacks instead target the application and authentication layer directly, using a phishing email attack to get the victim onto attacker-controlled infrastructure in the first place.
The distinction matters because multi-factor authentication methods were built on the premise that a stolen password isn't sufficient on its own. The attacker still needs the second factor. AiTM doesn't defeat that second factor directly. It relays a real, complete authentication flow and steals the proof of that flow, the session token, after the fact. The user experiences what looks like a normal login, because for most of the exchange, it is one.
How Adversary-in-the-Middle Attacks Work
AiTM attacks follow a four-phase sequence, and each phase creates a different detection opportunity, which is why the phases matter as much for defense planning as for understanding the attack itself.
Phase 1: Initial Access Through a Phishing Lure
The attack starts with a phishing email containing a link to what looks like a legitimate login page. That page is hosted on attacker-controlled reverse proxy infrastructure, often behind a typosquatted or recently registered domain designed to pass a quick visual check.
Phase 2: Credential Relay Through the Proxy
When the victim clicks through and enters credentials, the reverse proxy relays that traffic to the real identity service in real time. In doing so, it terminates the victim's TLS connection with a certificate it controls, then opens its own separate TLS connection to the real service, so two encrypted tunnels exist with the attacker's infrastructure sitting between them. The victim is looking at a working login page because the proxy is, in effect, performing a live pass-through of an authentic session. It isn't faking the login. It's relaying it.
Phase 3: Session Capture After MFA Completes
The victim completes the MFA challenge exactly as they would in a normal login. The real service verifies it and issues a session cookie confirming that authentication succeeded. The reverse proxy captures that cookie before passing the response along to the victim's browser, so the user reaches their inbox or dashboard with no obvious sign anything went wrong.
Phase 4: Session Replay From Attacker Infrastructure
With a valid session cookie in hand, the attacker can access the account from separate infrastructure, at a separate time, without triggering another MFA prompt. The service has no reason to challenge the session again: as far as its logic is concerned, the user already proved who they are. This is the phase where password resets alone fall short: resetting a password doesn't necessarily terminate a session token issued before the reset, which is why session revocation needs to be treated as a distinct response action.
Adversary-in-the-Middle vs. Traditional Man-in-the-Middle Attacks
The two attack types diverge enough in layer, position, and target that they call for different detection strategies entirely.
Attribute | Traditional MitM | AiTM |
|---|---|---|
Primary Layer | Network layer | Application and authentication layer |
Required Position | Compromised router, ARP spoofing, or rogue wireless access point | Victim connection to an attacker-controlled phishing page |
Primary Target | Network traffic | Authentication credentials and session tokens |
Access Method | Network positioning | Reverse proxy infrastructure |
Detection Focus | Network anomalies and certificate validation | Email, identity, and session signals |
Phishing-as-a-service has turned AiTM from a specialized technique into a commodity offering. As Abnormal's E.J. Whaley explained in the webinar, "Phishing as a service has been around for some time now, and it allows just about anybody to go on the dark web and target organizations via these phishing kits." Those kits now bundle pre-built reverse proxy infrastructure, realistic login templates, and automated session-token harvesting, which means a threat actor can stand up a credible AiTM campaign with limited technical background.
Why Adversary-in-the-Middle Attacks Matter for Security Teams
A stolen session token converts directly into financial fraud and data exposure, and either one can trigger regulatory consequences. That combination is what makes AiTM a business problem and not only a technical one.
Once an attacker holds a valid session, they inherit whatever access the compromised user has, without tripping another authentication check. For an executive or a member of the finance team, that access can translate into an authorized-looking payment request.
As E.J. Whaley described it in the same webinar, "Being able to redirect a payment for several million dollars, that's a huge payout. And you can, in a lot of cases, execute that by sending three or four emails back and forth." The effort required is small relative to the payout, which is exactly why privileged and payment-authorized accounts should be the starting point for stronger controls.
Beyond direct payment fraud, a hijacked session can open the door to several connected risks:
Business Email Compromise (BEC): Attackers can operate from inside an executive's authenticated session to send fraudulent payment instructions that look like they came from a trusted internal source.
Data Exfiltration: A valid session grants access to whatever mailboxes, file shares, or repositories the user can reach for as long as the session stays alive.
Regulatory Exposure: A session-hijacking incident that touches sensitive data can trigger the same investigation and notification obligations as any other breach.
These outcomes compound the longer a stolen session survives, which is why session monitoring and rapid revocation matter as much as blocking the initial phishing attempt.
How to Detect Adversary-in-the-Middle Attacks
Effective AiTM detection connects signals across network, identity, and email telemetry, because no single layer catches these attacks reliably on its own.
Network and Identity Signals
Several indicators can surface AiTM infrastructure and session misuse before or during replay. Suspicious login domains that closely mimic a legitimate service, along with certificate authorities or certificate chains that don't match established patterns, can point to reverse proxy infrastructure.
Once a session is underway, session cookie reuse from different IP addresses or user agents is one of the more reliable post-authentication indicators available: a user authenticating from Chicago followed by the same session token appearing in Eastern Europe within an implausible window is worth investigating immediately. Impossible travel detection formalizes that comparison, and device or browser attestation mismatches between the device that completed authentication and the device now presenting the session add further context.
Email and Behavioral Signals
Because AiTM almost always starts with a phishing email, catching that initial message remains one of the highest-leverage interventions available. Abnormal uses behavioral AI to help identify targeted phishing emails by analyzing patterns such as workflow cadences, vendor interactions, recipient behavior, timing, and engagement flows, surfacing messages that deviate from a user's normal correspondence even when they contain no traditionally malicious indicators like a known-bad link or attachment.
This kind of email-layer analysis is meant to complement identity and session monitoring rather than substitute for it. It doesn't stand alone, though: connecting a suspicious phishing message to unusual post-authentication activity, such as new inbox rules or unexpected application consent requests, gives investigators a clearer path from initial targeting to potential compromise than any single signal offers alone.
3 Steps to Prevent Adversary-in-the-Middle Attacks
A layered defense against AiTM combines authentication that resists proxying, monitoring that catches a hijacked session in progress, and email controls that stop the initial lure.
1. Deploy Phishing-Resistant Authentication Where It Matters Most
FIDO2, WebAuthn, and passkeys defeat the AiTM proxy path by cryptographically binding the authentication exchange to the legitimate domain. When a user attempts to authenticate, the protocol checks the origin before completing the challenge, so a request arriving through an attacker's proxy domain fails that check outright.
This is a fundamentally different guarantee than SMS codes, authenticator app tokens, or push notifications provide: each of those confirms that a factor was presented, but none of them independently verifies where that authentication intent was actually directed, which is precisely the gap AiTM exploits.
Rolling out phishing-resistant MFA to an entire organization at once isn't necessary and isn't usually realistic given application compatibility and device requirements. A risk-based sequence works better: prioritize executives, finance team members with payment authority, and IT administrators with privileged access first, since these accounts represent the highest-value targets for BEC and payment fraud. From there, extend coverage to other privileged accounts, vendor management roles, and staff with access to sensitive data repositories, before expanding across the broader workforce.
2. Monitor Sessions and Email Together
Continuous session validation can flag suspicious behavior throughout a session's lifetime rather than checking only at login, which matters because AiTM compromise happens after authentication succeeds, not during it. Pairing that with AI-powered email security creates coverage on both ends of the attack.
Email detection is positioned to intercept the phishing lure before a user ever reaches the proxy, while session monitoring is positioned to catch a hijacked session that gets through anyway. Neither layer substitutes for the other.
3. Build a Verification Culture That Doesn't Punish Caution
Technical controls only go so far if employees are afraid to slow down and verify an urgent request. Dr. Mary Aiken, a cyberpsychologist and the author of "The Cyber Effect," made this point directly in the webinar: "Those who are at the C-level in the organization should never punish employees for resisting those commands or orders with that level of urgency attached to them."
An organization that treats verification as friction to be punished ends up training employees to stop asking questions at exactly the moment questions matter most.
Common Mistakes to Avoid
Several recurring gaps show up across organizations working through AiTM readiness, and most of them come down to treating one control as sufficient on its own.
Applying One MFA Standard to Every User: A single MFA rollout for the whole organization overlooks the outsized exposure of executives, finance staff, and administrators. Prioritize phishing-resistant options for these groups before expanding further.
Resetting Passwords Without Revoking Sessions: A password reset doesn't necessarily terminate a session token issued before the reset. Credential resets, session revocation, and post-authentication monitoring need to be treated as separate, deliberate actions.
Investigating Signals in Isolation: A single unfamiliar IP address or login location rarely proves compromise on its own. Correlating session, identity, network, and email signals together gives investigators the context a lone indicator can't.
Leaving AiTM Out of Incident Exercises: With phishing kits making these attacks broadly accessible, tabletop exercises that never simulate reverse-proxy phishing and session hijacking leave escalation and response procedures untested against the attacks teams are actually likely to face.
Avoiding these gaps requires treating AiTM defense as a coordinated program rather than a checklist of isolated controls. Each mistake above compounds the others, so closing them in parallel is what turns individual safeguards into a resilient posture.
AiTM Defense Checklist for Security Teams
AiTM defense cuts across identity, email, operations, and awareness functions, so responsibilities need to be assigned explicitly rather than assumed. The checklist below distributes ownership across the teams that each hold one piece of the response.
Identity Team: Audit current MFA coverage for phishing-resistance, and prioritize administrators, executives, and finance staff for the first rollout phase.
Email Security Team: Review email security controls for phishing pages and reverse-proxy lures, and confirm findings can feed identity investigations.
Security Operations Team: Stand up session anomaly monitoring across critical applications, including visibility into session reuse from different IP addresses or user agents.
Incident Response Team: Document session-hijacking response procedures that separate session revocation, credential resets, and follow-on investigation into distinct steps.
Exercise Owner: Run tabletop exercises that simulate AiTM scenarios end to end, from initial phishing through session replay.
Security Awareness Owner: Confirm the organization's policies reward verification rather than penalize it, and that employees know how to report a suspicious login page.
Assigning these items to named owners turns AiTM defense from a shared concern into a set of accountable actions, which is what allows detection, response, and prevention to operate as one coordinated program rather than arallel efforts.
Treat Authentication as an Ongoing Process, Not a One-Time Check
Adversary-in-the-middle attacks succeed by exploiting the moment after authentication, which is exactly the moment most MFA strategies stop paying attention. Traditional MFA still meaningfully reduces password-based risk, but closing the AiTM gap requires origin-bound authentication for the accounts that matter most, plus session and email monitoring that catches what authentication alone misses. Abnormal, named a Customers' Choice in the 2026 Gartner® Peer Insights™ Voice of the Customer for Email Security, builds behavioral email detection to work alongside those identity and session controls rather than in place of them.
Ready to see where your organization stands against AiTM and other session-based attacks? Request a demo to see how Abnormal's behavioral AI can help identify the phishing activity that AiTM attacks depend on.
Frequently Asked Questions
Does HTTPS Protect Against AiTM Attacks?
No. HTTPS protects data in transit, but in an AiTM attack the victim's browser connects to a domain carrying a valid certificate the attacker controls. The encryption works correctly. It just encrypts the connection to the wrong server.
Are Hardware Security Keys Immune to AiTM?
FIDO2 hardware keys and passkeys provide strong protection against reverse-proxy phishing because they bind authentication to the legitimate origin cryptographically. No control is absolute, but this class of authentication is specifically designed to block the proxy path described above.
Do I Need to Replace My Existing MFA Entirely?
Not necessarily. Phishing-resistant MFA can start with the highest-risk users while traditional MFA continues to provide value against password-only attacks for the rest of the organization during a phased rollout.
Can Email Gateways Detect AiTM Phishing Emails?
Traditional email gateways (SEGs) can struggle with AiTM phishing because the infrastructure often uses newly registered domains and valid certificates that pass initial reputation checks. Behavioral email analysis is designed to add context that reputation-based filtering alone can miss.
How Long Do Stolen Session Tokens Remain Valid?
Session duration depends on the service, tenant policy, and configuration. Organizations can configure shorter session lifetimes and faster revocation policies for their most sensitive applications.