Skip to content
Start with Identity
Join free
SWI-T001 · Authentication

Attacker-in-the-middle phishing proxy

A reverse proxy sits between the user and the real login page, relays every step of authentication including MFA, and keeps the session cookie the successful login produces.

WidespreadHard to detect
First observed: 2017ATT&CK T1557 ↗ATT&CK T1539 ↗ATT&CK T1550.004 ↗

How it works

The victim clicks a link to a page the attacker controls. That page is not a copy of the login screen, it is a reverse proxy in front of the real one. An adversary-in-the-middle kit such as Evilginx, published in 2017, terminates TLS on a lookalike domain, opens its own TLS connection to the genuine identity provider, and rewrites hostnames in every request and response so the two halves stay in step. The victim sees the authentic login flow, including their own tenant branding and their own MFA prompt, because the HTML really did come from the identity provider a few milliseconds earlier.

Every field the victim submits is forwarded upstream: username, password, the one-time code, the push approval, the "stay signed in" answer. When authentication succeeds, the identity provider sets its session cookies on the response. In Microsoft Entra ID those are the ESTSAUTH family of cookies on login.microsoftonline.com; in other providers they are whatever cookie marks the session as authenticated. The proxy copies them before passing the response along, then usually redirects the victim to a harmless page or the real application so nothing looks wrong.

The attacker imports the cookies into their own browser and is signed in as the victim. They never need the password again and never face another MFA challenge, because the cookie records that MFA was already satisfied. From there the usual next steps are mailbox access, inbox rules to hide replies, payment fraud, and registering a new MFA method or device so access survives a password reset.

This is sold as a service. ANY.RUN traced the Mirage2FA toolkit across 4,532 unique organization email domains between 2024 and 2026. The Kratos kit, taken down by German, US and Indonesian authorities in July 2026, used a Node.js reverse proxy and had about 1,800 paying customers. CloudSEK found that the Evilginx-based BigBear 2.0 service went a step further and injected JavaScript that disabled WebAuthn in the victim's browser, so the victim fell back to a factor the proxy could relay.

Why it works

Every authentication factor except an origin-bound credential produces something that can be forwarded. A one-time code, a push approval, and a password are all values the victim hands over, and a relay does not care what the value is. The victim's own judgment is the only origin check in the loop, and a lookalike domain on a page with correct branding defeats it routinely.

The control assumption that fails is that completing authentication proves presence at the legitimate service. It does not. It proves the user completed a challenge, and the challenge never verified who was asking. Phishing-resistant MFA closes this because a FIDO2 or WebAuthn authenticator signs a challenge that includes the origin the browser actually loaded, so the proxy receives a signature scoped to the lookalike domain, which the real service rejects. The BigBear downgrade shows the corollary: phishing resistance only holds if the weaker methods are switched off for that account, not merely available beside it.

The second assumption that fails is that a session cookie is only ever presented by the browser that earned it. Most session cookies are bearer tokens, so once copied, they work from the attacker's machine exactly as they did from the victim's.

How to detect it

  • Identity provider risk detections. Entra ID Protection raises an "Attacker in the Middle" detection (attackerinTheMiddle) when an authentication session is linked to a malicious reverse proxy, and "Anomalous token" (anomalousToken) when a session token is replayed from an unfamiliar location. Both appear in the RiskEventTypes_V2 column of the SigninLogs table.
  • Session issued in one place, used in another. In Entra sign-in logs, group by SessionId and look for the same session appearing from a different IPAddress or AutonomousSystemNumber within minutes of the interactive sign-in, especially where the second ASN is a hosting provider. Huntress hunted the 2026 replay campaign by looking for OAuth2:Token requests from hosting infrastructure with bare node or Mozilla/5.0 user agents.
  • Okta. The System Log event security.session.detect_client_roaming fires when Okta sees a roaming session, and user.session.context.change records a significant change in device or network context on an active session.
  • Persistence right after sign-in. A new MFA method (user.mfa.factor.activate in Okta, "User registered security info" in Entra audit logs), a new device registration, or a new inbox rule within an hour of a sign-in from an unfamiliar ASN is the follow-on pattern in most AiTM incident reports.
  • Lookalike domains. Newly registered domains resembling your tenant or IdP name in mail gateway and DNS telemetry.

Be honest about the limits: a legitimate user on a corporate VPN, a mobile network or a split-tunnel setup can produce the same IP change between sign-in and use, so session roaming needs correlation rather than a blocking rule. The "Attacker in the Middle" detection is calculated offline, so it tends to fire after the cookie has already been used. Detection here is mostly about shortening attacker dwell time, not preventing the first sign-in. See what is ITDR.

How to stop it

  • Make origin-bound credentials the only allowed method. Passkeys and FIDO2 security keys defeat the relay outright. Enforce them with an authentication strength policy in conditional access so no phishable fallback remains, which is what the BigBear downgrade exploited. Check which of your SaaS apps can actually require them in the MFA matrix.
  • Require a compliant or managed device for token issuance. A proxy cannot present the victim's device state from the attacker's machine.
  • Bind sessions to the device. Entra Token Protection, device-bound session credentials in the browser, and DPoP for API tokens make a lifted cookie fail elsewhere.
  • Require step-up for persistence actions. Registering a new MFA method or device should demand a fresh, phishing-resistant authentication, since that is how attackers turn one stolen session into durable access.
  • Rehearse full session revocation. A password reset leaves the stolen session alive. Revoke sessions and refresh tokens, then remove unrecognized devices and MFA methods separately. See token theft and the identity incident response runbook.

Seen in the wild

Adversary-in-the-middle proxies account for 3 of the 25 MFA bypasses in the Identity Breach Report 2026, part of the 13 bypasses in which a person handed over or approved access, the pattern the report calls a talk-past attack.

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.