Adversary-in-the-Middle Attacks Explained

📅 September 26, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A financial analyst at a mid-sized investment firm opens what appears to be a routine multi-factor authentication prompt. She enters her credentials. Nothing seems wrong. Meanwhile, an attacker sitting between her browser and the firm’s authentication server has silently captured her session token — and is already browsing her client portfolio data. No malware was installed. No firewall rule was triggered. The breach was invisible, fast, and devastatingly effective. This is an Adversary-in-the-Middle (AiTM) attack in its most refined form, and it rendered traditional perimeter defenses completely irrelevant.

AiTM attacks — sometimes called machine-in-the-middle or man-in-the-middle (MiTM) in older literature — represent one of the most technically sophisticated and underappreciated threat categories facing enterprise environments. As organizations have adopted cloud platforms, zero-trust frameworks, and phishing-resistant authentication, adversaries have adapted their interception toolkits accordingly. Understanding how these attacks work, where they succeed, and how to engineer real defenses is no longer optional for security teams.

What Adversary-in-the-Middle Attacks Actually Mean

The terminology shift from “man-in-the-middle” to “adversary-in-the-middle” is more than semantic housekeeping. It reflects a maturation in how threat intelligence communities categorize active interception attacks — specifically distinguishing them by the adversary’s capability to relay, modify, and inject traffic in real time, rather than simply eavesdrop passively. MITRE ATT&CK catalogs AiTM under Technique T1557, covering sub-techniques like LLMNR/NBT-NS Poisoning and DHCP Spoofing, among others.

At its architectural core, an AiTM attack inserts a threat actor between two communicating parties — typically a user and a web service, or two network nodes — in a way that neither endpoint detects. The adversary can read plaintext communications, strip or downgrade encryption, replay authentication tokens, or inject malicious payloads into otherwise-legitimate traffic streams.

The Anatomy of an AiTM Session

Modern AiTM attacks, particularly those targeting enterprise Microsoft 365 or Google Workspace environments, follow a recognizable operational pattern. An adversary stands up a reverse proxy server — often using tools like Evilginx3, Modlishka, or Muraena — that impersonates a legitimate login portal. When the victim authenticates, the proxy forwards credentials to the real identity provider, captures the returned session cookie, and hands the victim a legitimate-looking session. The attack succeeds because the victim actually does authenticate to the real service — the adversary simply intercepts the session token generated after successful authentication.

This architecture is particularly dangerous because it defeats SMS-based and TOTP-based multi-factor authentication entirely. The proxy captures the MFA response in real time and forwards it before the time-based token expires. According to Microsoft’s 2025 Digital Defense Report, AiTM phishing frameworks were responsible for compromising over 10,000 organizations in a single coordinated campaign targeting financial and legal sectors, with attackers using captured session tokens to perform business email compromise (BEC) fraud worth hundreds of millions of dollars.

Primary Attack Vectors and Delivery Mechanisms

AiTM attacks reach victims through a narrower but increasingly refined set of delivery vectors. Understanding the specific entry points allows security architects to prioritize control placement effectively.

Network-Level Interception Techniques

At the network layer, AiTM attacks exploit trust relationships inherent in protocols that were never designed with hostile network environments in mind. ARP poisoning remains a foundational technique — by broadcasting forged ARP replies, an attacker on a local network segment can associate their MAC address with a legitimate gateway IP, redirecting all traffic through their machine. DHCP spoofing takes a similar approach, racing to respond to DHCP discovery packets before the legitimate server, assigning victims a rogue default gateway.

LLMNR and NBT-NS poisoning — heavily used in Active Directory environments — exploit the Windows name resolution fallback chain. When a hostname cannot be resolved via DNS, Windows broadcasts LLMNR or NBT-NS queries to the local subnet. Tools like Responder intercept these broadcasts and respond with poisoned answers, capturing Net-NTLMv2 hashes that can be relayed or cracked offline. The 2024 Verizon Data Breach Investigations Report noted that credential theft via network protocol abuse remained a top initial access vector for internal threat actors and compromised endpoints.

Application-Layer and Proxy-Based Interception

At the application layer, reverse proxy toolkits have dramatically lowered the operational barrier for AiTM attacks against cloud identity systems. Evilginx3, for instance, operates as a man-in-the-middle HTTPS proxy that uses DNS hijacking combined with Let’s Encrypt certificates to present a fully valid TLS session to the victim while proxying traffic to the legitimate identity provider. The victim sees a green padlock, a familiar-looking URL with minor typographic variations, and a pixel-perfect replica of the target login page.

SSL stripping — downgrading HTTPS connections to HTTP — has become less viable as HSTS preloading has grown in adoption, but it remains effective against internally-deployed applications and custom enterprise portals that haven’t implemented HSTS headers correctly. Security teams that assume TLS presence equals session integrity are operating on a dangerously outdated assumption.

Why Multi-Factor Authentication Alone Is No Longer Sufficient

This is one of the most consequential truths that security leadership must internalize: MFA, when implemented as knowledge-based OTP or push notifications, does not prevent AiTM session hijacking. It never was designed to. MFA prevents credential stuffing and password-only attacks. It cannot stop a real-time relay that completes the authentication dance on behalf of the user.

The Storm-1167 threat group (tracked by Microsoft Threat Intelligence) demonstrated this in a documented 2024 campaign targeting hospitality and fintech organizations. The group deployed an AiTM phishing kit that relayed Microsoft Authenticator push approvals in real time, capturing post-authentication session cookies and bypassing Conditional Access policies that relied solely on MFA completion as a trust signal. The average dwell time before detection was 11 days — long enough for full BEC fraud execution.

Phishing-Resistant MFA: The Architectural Difference

The solution is not to abandon MFA but to adopt phishing-resistant MFA mechanisms that are cryptographically bound to the legitimate origin. FIDO2/WebAuthn passkeys and hardware security keys (like YubiKeys) achieve this through a public-key challenge-response mechanism where the authenticator signs a challenge that includes the relying party origin. If the origin is a spoofed proxy domain rather than the legitimate service, the authentication attempt fails — the hardware key refuses to sign for an unrecognized origin.

NIST SP 800-63B (Digital Identity Guidelines) classifies FIDO2/WebAuthn as AAL3-capable authentication, the highest assurance level, precisely because it resists real-time phishing and AiTM interception. Organizations that have deployed phishing-resistant MFA at scale — including several U.S. federal agencies under CISA’s phishing-resistant MFA mandates — have reported zero successful AiTM compromises against enrolled accounts. The control works. The deployment gap is the problem.

Detection Strategies for AiTM Activity

Detection of AiTM attacks is challenging because, from the identity provider’s perspective, the authentication completed successfully. The session was legitimately issued. Detection, therefore, requires behavioral analytics and anomaly detection rather than signature-based pattern matching.

Identity and Session Anomaly Signals

Microsoft Entra ID (formerly Azure AD) and similar identity platforms now generate specific risk signals relevant to AiTM activity. Key indicators include:

• Impossible travel: A session authenticated from London and then accessed from Singapore within 15 minutes indicates session token theft and replay.
• User agent inconsistency: The authentication event shows a mobile browser; the subsequent API calls use a Python requests library header.
• Token replay across IP families: Session cookies used from residential ISP IPs shortly after authentication from a corporate egress IP.
• Sign-in from anonymizing infrastructure: Use of residential proxy networks, Tor exit nodes, or hosting providers associated with adversary infrastructure.
• Unusual mailbox rule creation: Post-authentication inbox forwarding rules — a hallmark of BEC follow-through — created within minutes of sign-in.

SIEM correlation rules should map these signals to a unified AiTM kill chain detection story. Microsoft Sentinel’s AiTM detection workbook, for example, correlates Entra ID sign-in logs with subsequent unified audit logs to surface anomalous post-authentication behavior within minutes of occurrence.

Network-Level Detection Controls

On the network layer, Dynamic ARP Inspection (DAI) on managed switches prevents ARP poisoning by validating ARP packets against DHCP snooping binding tables. DHCP snooping itself restricts DHCP server responses to designated trusted ports, blocking rogue DHCP server injection. For internal name resolution abuse, disabling LLMNR and NBT-NS via Group Policy in Active Directory environments eliminates the attack surface entirely — a configuration change that Microsoft’s own security baselines recommend but that remains unimplemented across a significant portion of enterprise AD deployments.

Network Detection and Response (NDR) platforms capable of deep packet inspection can identify anomalous ARP behavior, unusual DNS response patterns, and SSL certificate mismatches at the traffic level. Integrating NDR telemetry with SIEM and SOAR platforms enables automated containment responses — isolating suspect endpoints before lateral movement begins.

Zero Trust Architecture as a Structural Defense

Zero Trust is not a product — it’s an architectural philosophy that fundamentally changes how trust is extended to sessions, devices, and identities. In the context of AiTM, Zero Trust controls address the core weakness that these attacks exploit: the implicit trust granted to an authenticated session regardless of subsequent context.

Continuous Authentication and Session Validation

Traditional session models authenticate once and maintain trust for the duration of the session token’s lifetime — often hours. Zero Trust architectures implement continuous access evaluation (CAE), where the identity platform re-evaluates session trustworthiness in real time based on signals like device compliance, location, risk score, and user behavior. Microsoft’s Continuous Access Evaluation in Entra ID can revoke session tokens within seconds of a risk signal being raised — even for sessions that were legitimately authenticated moments earlier.

Device-bound sessions represent another critical control layer. When session tokens are cryptographically bound to a specific device (via Proof of Possession tokens in OAuth 2.0 DPoP or similar mechanisms), a stolen session cookie becomes unusable from a different device — eliminating the primary payoff of AiTM session hijacking. The IETF’s RFC 9449 formally standardizes DPoP as a mechanism for binding tokens to client-controlled key pairs, and major identity providers are progressively rolling out support.

Organizations implementing Zero Trust frameworks that combine phishing-resistant MFA, device compliance checks, Conditional Access policies, and Continuous Access Evaluation have demonstrated measurable reductions in credential-based breach impact. A 2025 Forrester study of 200 enterprise Zero Trust adopters found that those with mature identity controls (including phishing-resistant MFA and CAE) experienced 73% fewer identity-related security incidents than organizations relying on conventional MFA alone.

Incident Response Considerations for AiTM Breaches

When AiTM activity is confirmed or suspected, the incident response timeline must move faster than the attacker’s operational tempo. Threat actors using AiTM for BEC fraud typically move from session capture to fraudulent transaction initiation within 30 to 90 minutes — well within most enterprise IR SLAs for identity incidents.

Immediate Containment and Forensic Priorities

Immediate containment priorities include revoking all active sessions for affected accounts (not just the suspected compromised session — all sessions), resetting credentials, and forcing re-enrollment of authentication methods. In Microsoft Entra ID, this means using the “Revoke Sessions” function combined with a risky user dismissal and password reset workflow. Simply changing a password without revoking active session tokens leaves the attacker’s stolen cookie viable until natural expiry.

Forensically, investigators should prioritize pulling sign-in logs with full IP, user agent, and location data for the 72-hour window around the suspected compromise. Unified audit logs should be reviewed for mailbox rule creation, mail forwarding configuration, SharePoint data access, and OAuth application consent grants — all common post-AiTM actions. Preserving these logs before they age out of their retention window is a time-sensitive priority.

For organizations that may lack the internal expertise to conduct AiTM forensics at speed, retaining a specialized incident response firm with demonstrated identity-focused IR capability (not just endpoint forensics) is a material risk management decision worth making proactively.

Key Takeaways

• AiTM attacks bypass conventional MFA — Real-time proxy toolkits capture and relay OTP/push MFA responses before they expire, defeating legacy multi-factor controls. Only phishing-resistant FIDO2/WebAuthn authentication is structurally immune.
• Detection requires behavioral analytics, not signatures — Successful AiTM authentications look legitimate to identity providers. Detection depends on post-authentication anomaly signals: impossible travel, user agent mismatches, and unusual mailbox rule creation.
• Network hygiene eliminates large attack surface — Disabling LLMNR/NBT-NS, enabling Dynamic ARP Inspection, and enforcing DHCP snooping on managed network infrastructure removes foundational protocol vectors that AiTM relies on at the LAN level.
• Zero Trust with device-bound sessions neutralizes stolen tokens — Continuous Access Evaluation and DPoP token binding mean that even a successfully stolen session cookie cannot be replayed from an adversary-controlled device — breaking the attack’s core payoff.
• IR speed is existential — The window between AiTM session capture and fraudulent action is measured in minutes to hours. Incident response playbooks must include immediate full session revocation, not just password resets, with predefined SLAs shorter than an attacker’s operational tempo.

Conclusion: Closing the Gap Between Policy and Architecture

AiTM attacks succeed not because defenders lack awareness, but because there is a persistent gap between security policy and security architecture. Policies that mandate MFA without specifying phishing-resistant MFA create a false sense of protection. Network standards that permit LLMNR leave credential harvesting attack surface wide open. Session management models that trust tokens without device binding hand attackers a reusable key after every successful phish.

Close that gap deliberately. Start this week by auditing which authentication methods in your environment are phishing-resistant versus phishable, and map the user populations still relying on SMS OTP or push-based MFA. Then build a 90-day migration roadmap to FIDO2 passkeys or hardware security keys for your highest-risk user groups — privileged administrators, finance approvers, executives. Simultaneously, validate that LLMNR and NBT-NS are disabled across your Active Directory environment and that Continuous Access Evaluation is enabled in your identity platform. These are not aspirational controls. They are available now, they work, and every day they’re not deployed is a day an adversary-in-the-middle attack can succeed exactly the way it did in that investment firm — silently, quickly, and at scale.