Attacker-in-the-middle phishing proxy

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 proxy in front of the real one. Every field the victim submits is forwarded to the genuine identity provider, and every response is relayed back, so the victim sees the authentic login flow including their own tenant branding and their own MFA prompt.

When authentication succeeds, the identity provider issues a session cookie to the proxy. The attacker keeps it and replays it from their own browser. They never learn a password they need, and they never trigger a second authentication.

Commercial kits sell this as a service. ANY.RUN traced the Mirage2FA toolkit across 4,532 unique organization email domains between 2024 and 2026, with over 9,000 potential compromise events.

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 control assumption that fails is that authenticating proves presence at the legitimate service. It does not. It proves the user completed a challenge, and the challenge did not verify who was asking. Phishing-resistant MFA closes this because the authenticator signs only for the origin that registered the credential, so the proxy receives a signature the real service will reject.

How to detect it

• Sign-ins where the session was issued to one IP or ASN and used from another within minutes.
• Authentication from a user agent or device that has never appeared for that account, immediately following a successful login.
• Newly registered domains resembling your tenant name appearing in mail gateway or DNS telemetry.
• Session cookies presented without a matching interactive authentication event.

Be honest about the limits: a legitimate user on a corporate VPN can produce a similar IP change, so this needs correlation rather than a blocking rule. See what is ITDR.

How to stop it

• Deploy origin-bound credentials. Passkeys and FIDO2 security keys defeat the relay outright, because there is nothing forwardable.
• Bind sessions to a device or client with DPoP or mutual TLS, so a lifted cookie fails elsewhere.
• Shorten session lifetimes and require re-authentication for sensitive actions with step-up authentication.
• Require a compliant or managed device in conditional access, which a proxy cannot satisfy on the attacker's machine.
• Rehearse session revocation. A password reset leaves the stolen session alive. See token theft.

Seen in the wild

• Mirage2FA reached 4,500 organizations by stealing sessions instead of breaking MFA
• Kali365 phishes Microsoft's own device login page
• Infostealers and session hijacking

Sources

• MITRE ATT&CK T1557: Adversary-in-the-Middle
• MITRE ATT&CK T1539: Steal Web Session Cookie
• CISA: Implementing Phishing-Resistant MFA