What Is an Adversary-in-the-Middle (AitM) Attack?

An adversary-in-the-middle (AitM) attack is a phishing method in which an attacker places a reverse proxy between a user and a real login page, then steals the session token and credentials issued after authentication succeeds.

A victim moving through this flow sees nothing unusual at any point. The password is correct. The MFA prompt is approved. Every step works because the traffic is relayed to the genuine service in real time.

Ordinary phishing and this attack differ on one decisive point. Resetting the password afterwards does not lock the attacker out. The attacker never needed the password and holds the session token instead

How an AitM Attack Works

An AitM attack works by relaying a real login through attacker infrastructure and capturing the session artifact at the end of it. Nothing is faked except the domain the victim lands on.

Lure and Redirect

The victim receives a message with a link to what looks like a normal sign-in page. Modern campaigns send these from compromised business accounts, which removes the sender anomalies that filters catch. Spear phishing of this kind carries no attachment and no malware, which removes every signal that standard phishing detection is built to catch.

Reverse Proxy Relay

A click opens a page hosted on attacker infrastructure. That page does not imitate the login form. It forwards every request to the real identity provider and returns the real response. Genuine branding, genuine error messages, and a genuine MFA challenge all appear, because they come from the actual service.

Authentication and Token Capture

Authentication then proceeds exactly as the user expects it to proceed. The identity provider validates the password. An MFA challenge fires and the user approves it. A session cookie is issued to what the provider believes is the user's browser. That cookie passes through the proxy, and the attacker copies it.

Session Replay

Attackers load the stolen cookie into a browser they control. The application accepts it as proof of a completed login. No password prompt appears and no MFA challenge fires, because the authentication event already happened and the token records that it did.

What Types of Authentication Tokens Are Targeted in AitM Attacks?

Token targeting in AitM attacks centers on session artifacts that represent authenticated trust rather than credentials used during login.

Session Cookies

Session cookies maintain a logged-in state within a browser after authentication succeeds. Control of these cookies allows attackers to impersonate users instantly without triggering reauthentication.

Access Tokens

Access tokens grant scoped permissions to applications and APIs on behalf of a user. Theft enables direct interaction with protected resources using the victim’s identity and privileges.

Refresh Tokens

Refresh tokens extend session duration by issuing new access tokens without user involvement. Compromise increases persistence and allows attackers to maintain access long after initial login.

SSO Tokens

Single Sign-On tokens enable access to multiple applications through a single authentication event. Abuse creates broad lateral access across services tied to the same identity provider.

OAuth Grants

OAuth grants authorize delegated access between services once user consent is established. Misuse allows attackers to operate across connected applications without repeated identity checks.

Why MFA Fails to Stop AitM Attacks

MFA fails against AitM attacks because it validates the login event, not the session that follows it. Once the identity provider issues a token, that token becomes the credential, and the system stops checking who is holding it.

Session tokens work as bearer credentials in almost every implementation. Whoever holds one is treated as the authenticated user. Most carry no binding to a device, browser instance, or TLS channel, so a cookie copied to another machine works exactly as it did on the original.

Method choice decides whether the relay succeeds or fails at this point. One-time codes, SMS messages, and push approvals all travel through the proxy with everything else. Each one authenticates the attacker's relayed session as readily as the user's. FIDO2 and WebAuthn behave differently, for reasons covered further down.

AitM Phishing-as-a-Service Operations

Running an AitM campaign no longer requires any real technical skill. Packaged platforms handle the proxy, the phishing pages, the hosting, and the delivery of stolen tokens. CloudSEK researchers gained administrator access to one of these platforms and published the contents in an investigation into BigBear 2.0, a pattern now visible across current phishing trends.

The panel managed 42 virtual private servers configured against Microsoft 365. It held 5,137 stolen records tied to 461 organizations and 3,331 victim IP addresses across more than 40 countries. Those records broke down into 1,032 plaintext passwords, 4,148 session cookies, and 474 complete authenticated sessions captured after MFA had succeeded.

Access was leased to at least five affiliate operators, each receiving stolen material through a live Telegram bot. IT service providers and managed service providers made up 151 of the 461 organizations identified, which is the heaviest concentration in the dataset and reflects the privileged access those staff hold into customer environments.

Beyond the raw volume, the panel's operational design deserves closer attention. Residential proxies were matched to each victim's country, so attacker authentication traffic looked geographically consistent with the user. Injected JavaScript suppressed FIDO2 and WebAuthn prompts, pushing victims onto a weaker authentication method the proxy could relay.

AitM Attacks vs MitM Attacks

Adversary-in-the-middle (AitM) attacks operate at the identity layer, while Man-in-the-middle (MitM) attacks operate at the network layer. MITRE catalogs adversary-in-the-middle as technique T1557, and every sub-technique listed there is network-based: ARP cache poisoning, DHCP spoofing, name resolution poisoning, and evil twin access points.

Reverse-proxy phishing maps elsewhere in that same framework entirely. Its closest entries are session cookie theft and application access token theft. Teams that treat the two attack classes as one end up buying network controls for an identity problem.

Session Artifacts Targeted in AitM Attacks

Attackers want whatever the identity provider issues at the end of a successful login. Each artifact grants a different reach and a different lifespan.

• Session cookies: these hold browser login state. A cookie loaded into another browser opens the same webmail or SaaS dashboard as an already-signed-in user.
• Access tokens: these grant scoped permission to APIs. A stolen token reads mail or files through the API directly, without ever touching a login page.
• Refresh tokens: these mint new access tokens without user involvement. Compromise extends attacker access for weeks past the original sign-in.
• SSO assertions: a single identity provider token unlocks every connected application. One stolen assertion reaches email, chat, CRM, and HR systems under one identity.
• OAuth consent grants: delegated access to a third-party application survives password changes entirely, because the grant is a separate authorization record.

How to Detect AitM Session Hijacking

Detection has to look after the login, because the login itself succeeds and logs cleanly. These signals separate a hijacked session from a legitimate one.

Authentication and Session Context Mismatch

The sign-in happens from one device and user agent. Subsequent requests on the same session arrive from a different one. A token issued to a Windows browser and used from a Linux client within minutes is strong evidence of replay.

Sign-In Source Anomalies

Authentication traffic arriving from hosting provider address space, VPS ranges, or a residential proxy that does not match the user's normal pattern warrants investigation. Geographic matching by attackers reduces the value of location alerts on its own, so pair location with ASN and device.

Impossible Travel With a Valid Token

Concurrent sessions on one identity from distant locations inside a short window point to a shared token. The second session produces no failed logins at all, so failure-based alerting misses it completely.

Post-Login Mailbox and Consent Changes

Attackers move quickly once a replayed session opens for them. New inbox rules, forwarding addresses, MFA method registrations, and OAuth consent grants appear within the first hour, which is the pattern behind most business email compromise that follows a session theft. A security operations workflow that alerts on these changes catches the intrusion at its earliest actionable point.

Lookalike Domain Registrations

AitM infrastructure needs a domain that survives a quick glance. Newly registered domains resembling the organization's own, or its identity provider's, are the earliest signal available and appear days before any message is sent. Brand impersonation monitoring surfaces them during setup.

Controls That Stop AitM Attacks

Phishing-resistant authentication is the only control that prevents an AitM attack outright. Everything else limits the damage after a token is taken.

Origin-Bound Authentication

FIDO2 and WebAuthn tie each credential to the exact domain that registered it. The authenticator checks the origin before signing and refuses when the domain does not match. A proxy on a lookalike domain never receives a valid assertion, so the attack fails at the authentication step rather than being detected afterwards.

Weaker fallback methods undo that protection completely in practice. The BigBear panel injected JavaScript to suppress FIDO2 prompts and push victims onto weaker options. Passkeys stop AitM only when those weaker methods are removed from the account entirely.

Token Binding and Continuous Evaluation

Binding a token to a device or cryptographic key makes it useless elsewhere. Continuous access evaluation revokes sessions mid-flight when risk signals change, instead of waiting for expiry. Both controls attack the bearer-token weakness directly.

Conditional Access on Device Compliance

Policies that require a managed, compliant device block replay from attacker-controlled machines even when the token is valid. This is the strongest available control for organizations that cannot deploy passkeys everywhere, and it applies zero trust conditions to session use rather than to login alone.

Short Token Lifetimes

Shorter access token lifetimes narrow the window for replay. Refresh token lifetime matters more, since a long-lived refresh token restores attacker access again after each expiry.

Responding to an AitM Session Compromise

Standard account recovery procedures fail against this attack entirely. A password reset leaves the stolen session live. Users are told to reset and move on while the attacker stays connected throughout.

1. Revoke the sessions first. Invalidate every session token and refresh token for the account before anything else. This is the step that actually ends the attacker's access.
2. Reset the password and re-register MFA. Remove any authentication method registered during the exposure window, since attackers add their own method early to secure a second route back.
3. Audit mailbox and application configuration. Check forwarding rules, inbox rules, delegate permissions, and OAuth consent grants. Remove anything created after the sign-in in question.
4. Scope the wider campaign. Search the tenant for other sign-ins from the same address space and for other recipients of the same lure. Mapping the full attack path matters because AitM operations run against many targets at once.
5. Submit the phishing domain for takedown. Removal through domain takedown ends the infrastructure for every other target, not just the one that reported it. Takedown coverage decides how fast that happens.

Detecting AitM Infrastructure Before the Lure Arrives

Every AitM campaign needs a domain and a hosted proxy before it sends a single message. That infrastructure is registered, configured, and tested in public view, days ahead of the first email reaching an inbox.

CloudSEK's XVigil is a digital risk protection platform that monitors surface, deep, and dark web sources for that preparation. Newly registered lookalike domains, cloned sign-in pages carrying an organization's branding, and credentials already circulating on dark web sources surface while the operation is still being assembled, with takedown support to remove the infrastructure from circulation.

Removal before launch changes the arithmetic of the attack. A proxy taken down ahead of the campaign protects every intended recipient at once, which no amount of post-login detection can match.

AitM Attack FAQs

Does changing a password stop an AitM attack?

No. The stolen session token remains valid after a password change. Access ends only when sessions and refresh tokens are revoked.

Can AitM attacks work against HTTPS connections?

Yes. The proxy terminates one encrypted connection and opens another. Encryption stays intact on both sides throughout.

Do passkeys fully prevent AitM attacks?

Yes, when no weaker fallback exists. Attackers suppress passkey prompts to force a downgrade, so alternate methods must be removed from the account.

Is an AitM attack the same as session hijacking?

No. Session hijacking describes the outcome. AitM describes the method used to obtain the session token in the first place.

How long does stolen AitM access last?

Until session revocation or refresh token expiry. Refresh tokens often extend attacker access for weeks beyond the original sign-in.

Which industries face the highest AitM risk?

IT services, managed service providers, and any organization on cloud identity platforms where one identity reaches many connected applications.