Push-based MFA was a decade-old patch on a broken model. Here's how AiTM toolkits like EvilProxy and Tycoon 2FA defeat it — and the phishing-resistant controls that actually stop them.
For most of the last decade, "turn on MFA" was the canonical answer to credential theft. It worked — for a while. Push notifications and one-time codes broke the cheap automated credential stuffing economy and pushed attackers up the food chain. In 2026, that ceiling has collapsed. The majority of business email compromise and cloud account takeover cases the Maverc Identity Threat Detection team handles now begin with a successful adversary-in-the-middle (AiTM) phishing attack against a user who had MFA enabled and used it correctly.
If you are still measuring identity security maturity by "MFA coverage," you are measuring the wrong thing.
How AiTM actually works
A modern phishing kit does not try to steal a password. It steals a session.
The attacker sends a lure — typically a shared document notification, a voicemail alert, a DocuSign request, or an HR message — that links to a domain the attacker controls. That domain runs a reverse proxy (the original Modlishka and Evilginx2 projects pioneered the technique; commercial kits like EvilProxy, Tycoon 2FA, Mamba 2FA, and NakedPages have industrialized it). When the victim clicks, the proxy fetches the legitimate Microsoft, Okta, or Google login page in real time and serves it back to the user. Every keystroke, every form submission, and every MFA prompt is relayed bidirectionally between the victim and the real identity provider.
The victim sees a perfect login flow. They type their password. They approve the push. They type the TOTP code. The identity provider, satisfied that the human authenticated correctly, issues a session cookie. The proxy captures that cookie before forwarding it on, and the attacker imports it into their own browser. Within seconds the attacker is authenticated as the victim, with a valid session, on a real device, against the real tenant. From the IdP's perspective, nothing is wrong.
Why push and OTP are structurally broken against this
Both push approvals and time-based one-time passwords trust two assumptions: that the human is on the legitimate site, and that the human will refuse a prompt they did not initiate. AiTM destroys the first assumption — the user really did initiate the prompt, just against a proxy. MFA fatigue and prompt bombing destroy the second.
Number matching helped, briefly. Modern AiTM kits now scrape the displayed number from the proxied IdP page and present it to the victim, who dutifully types it into their authenticator. Geo-fencing helped, briefly. Operators now rent residential proxy infrastructure in the victim's metro area for a few dollars an hour. Risk-based step-up helped, briefly. Operators warm up sessions by browsing inbox folders for a few minutes before exfiltrating data, mimicking benign behavior long enough to defeat naive scoring.
This is not a defect that better MFA messaging will fix. It is the predictable result of relying on a shared secret (the code, the approval) that any system in the middle of the conversation can observe.
Controls that actually stop AiTM
Three categories of control move the floor.
- Phishing-resistant authenticators. FIDO2 security keys and platform passkeys use public-key cryptography bound to the legitimate origin. The browser will not release a credential to a proxy domain because the origin in the cryptographic challenge does not match. This is the only control on this list that is mathematically resistant rather than statistically resistant.
- Token protection and device-bound sessions. Microsoft Entra's Token Protection (currently rolling out broadly) binds refresh tokens to the device's TPM. A stolen cookie replayed from attacker infrastructure is rejected because it is no longer on the device that minted it. Apple, Google, and Okta have parallel programs.
- Continuous Access Evaluation (CAE) and Identity Threat Detection and Response (ITDR). The first lets your IdP revoke an active session within minutes of a risk signal — instead of waiting for the one-hour token lifetime to expire. The second watches for the post-compromise behaviors AiTM enables: impossible travel between the legitimate device and the attacker's residential proxy, OAuth consent abuse to install persistent backdoor apps, mailbox rule creation that hides replies from the legitimate user, and stale-token reuse from new IPs.
What about conditional access?
Conditional access policies are necessary but not sufficient. The two policies that move the needle most against AiTM are device compliance enforcement (the session must originate from a managed, compliant device) and authentication strength requirements that mandate a phishing-resistant factor for sensitive applications. If your conditional access policy still allows password plus push for access to email, SharePoint, or admin portals, you have not closed this attack path.
The other policy that matters is sign-in risk and user risk integration. Wire your IdP's risk signals into a real response: high sign-in risk should require a phishing-resistant MFA challenge or block outright; high user risk should force credential reset and revoke active sessions.
The Maverc identity hardening sequence
When we engage on identity hardening, we run the same sequence almost every time:
1. Inventory every authentication path into your tenant — primary user sign-in, federated sign-in, break-glass accounts, service principals, legacy authentication endpoints, partner access, and B2B guest invitations. AiTM operators routinely target the weakest of these, not the front door. 2. Block legacy authentication entirely. Basic authentication and protocols that do not support modern MFA (POP3, IMAP4, SMTP AUTH, MAPI over HTTP without modern auth) remain enabled in roughly half the tenants we audit. 3. Enroll FIDO2 or passkeys for every privileged role first, then for high-impact business roles (finance, HR, legal, executive support), then organization-wide. Phase the rollout, but commit to a date when password plus push is no longer accepted for sign-in. 4. Turn on token protection and continuous access evaluation. Verify the policy is in enforce mode, not report-only. 5. Wire ITDR telemetry into the SOC with playbooks: detected token theft means session revocation, credential reset, device review, and mailbox rule audit within thirty minutes. 6. Run a tabletop exercise where the red team simulates an AiTM compromise of a finance user and a tenant administrator. Measure detection time, containment time, and the blast radius of the access the attacker obtained before the SOC closed the door.
The organizations that complete this sequence reduce AiTM-driven account takeover to near zero. The organizations that stop at "we have MFA enabled" remain at the mercy of a phishing kit that costs the attacker less per month than a streaming subscription.
