# Attacker-in-the-middle phishing proxy

Source: https://startwithidentity.com/techniques/aitm-phishing-proxy/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## 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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/guides/fundamentals/what-is-itdr/).

## How to stop it

- **Deploy origin-bound credentials.** [Passkeys](https://startwithidentity.com/glossary/passkey/) and FIDO2 security keys defeat the relay outright, because there is nothing forwardable.
- **Bind sessions to a device or client** with [DPoP](https://startwithidentity.com/glossary/dpop/) or mutual TLS, so a lifted cookie fails elsewhere.
- **Shorten session lifetimes** and require re-authentication for sensitive actions with [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/).
- **Require a compliant or managed device** in [conditional access](https://startwithidentity.com/glossary/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](https://startwithidentity.com/glossary/token-theft/).

## Seen in the wild

- [Mirage2FA reached 4,500 organizations by stealing sessions instead of breaking MFA](https://startwithidentity.com/blog/2026-08-25-mirage2fa-session-hijacking-microsoft-365/)
- [Kali365 phishes Microsoft's own device login page](https://startwithidentity.com/blog/2026-08-05-kali365-device-code-phishing-microsoft-365/)
- [Infostealers and session hijacking](https://startwithidentity.com/breaches/infostealer-session-hijacking/)

## Sources

- [MITRE ATT&CK T1557: Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/)
- [MITRE ATT&CK T1539: Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/)
- [CISA: Implementing Phishing-Resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf)