MFA succeeded and the account still fell: adversary-in-the-middle phishing and session cookie theft

"We have MFA" is the answer most organisations give when asked about phishing, and until fairly recently it was a good one. Stealing a password stopped being enough, so credential phishing stopped paying.

Attackers did not respond by breaking MFA. They responded by letting it succeed and stealing what it produces.

The technique is adversary-in-the-middle phishing, and the shape is simple: the attacker runs a reverse proxy in front of the real login page. The victim sees the genuine sign-in flow, because it is the genuine sign-in flow, enters their password, completes the MFA prompt on their phone, and lands in their actual account. Everything works. Everything is real.

And as all of that passes through the proxy, the attacker captures the session cookie the identity provider issues at the end.

That cookie is the thing that actually grants access. Replay it in another browser and you are authenticated as the victim, with no password prompt and no second factor, because from the identity provider's point of view authentication already happened. The user did it, correctly, minutes ago.

Why this is not a niche technique

This is industrialised. The tooling, Evilginx as the open-source reference, plus commercial kits such as Tycoon 2FA, EvilProxy, Sneaky 2FA and NakedPages, is sold as phishing-as-a-service at roughly $100 to $1,000 a month. The buyer needs no ability to write any of it.

The volume is the part worth internalising: in October 2025 alone, Microsoft Defender for Office 365 blocked more than 13 million malicious emails associated with Tycoon 2FA campaigns. That is one kit, one month, one mail platform, and only the messages that were caught.

Through 2025 there were repeated documented campaigns against universities using lookalike single sign-on domains to hijack Microsoft 365 sessions. A sector chosen because it combines a large, transient user population with genuinely complex, federated sign-in flows that make an unusual URL look normal.

The chain, end to end

The individual steps are all ordinary. That is the point, no single one looks like an attack.

1. Reconnaissance that costs nothing. Names, roles and reporting lines from LinkedIn. The email format from a single public address. Vendors and software from job adverts and press releases. Sometimes an actual document: an onboarding pack, an org chart, a supplier list, indexed by a search engine or sitting in a misconfigured bucket.

That last one is what turns a generic phish into a convincing one. A message referencing your real HR system, your real onboarding process and your real manager's name is a different object from "Dear User".

2. The lure. Almost always one of a handful: a document share, an expiring password, an HR or payroll action, a voicemail, a signature request. It arrives from a compromised third party as often as a spoofed domain. A real supplier's real mailbox, in an existing thread, which defeats every check based on sender reputation and prior contact.

3. The proxy. The link goes to attacker infrastructure that relays to the real IdP. Modern kits do this well: valid TLS, plausible domain, correct branding, because the branding is the genuine page. They also fingerprint visitors and serve a harmless decoy to anything that looks like a sandbox, a scanner or a security vendor's IP range, which is why the URL you check in a sandbox may come back clean.

4. Authentication succeeds. The victim's credentials are correct. Their MFA prompt is genuine and they approve it, because they are signing in. They just do not know who else is watching.

5. The cookie is captured and replayed. Now the attacker has an authenticated session. No further prompt, no anomaly the user would notice.

6. Persistence, quickly. This is where the damage is decided, and it is usually within minutes: register an attacker-controlled MFA method, create an OAuth application consent or an app password, add a mailbox forwarding rule or an inbox rule that files security notifications straight into a folder nobody reads. Once any of those is in place, the stolen cookie is no longer needed, revoking the session does not evict them.

7. Onward. Internal phishing from a genuine mailbox, which is far more effective than anything external. Access to whatever SSO fronts. And in a hybrid estate, a route toward the directory itself, where the attack paths already present in Active Directory take over, and the goal becomes a privileged account that outlives the phish.

What actually stops it

Ordinary MFA does not, so the honest list is short and specific.

1. Phishing-resistant MFA, required rather than available. FIDO2 security keys, or passkeys, or Windows Hello for Business. These bind the credential to the origin, so a proxy on a lookalike domain cannot complete the ceremony. The browser will not release the assertion to the wrong origin. This is the one control that defeats the technique outright rather than making it harder.

The word required is doing the work. If a phishable fallback remains, SMS, push, TOTP, "having trouble? use another method". An attacker will steer users to it, and the kits are built to do exactly that. A strong method that can be downgraded is the strength of its weakest fallback.

2. Bind sessions to device and location. Conditional access requiring a compliant or managed device means a replayed cookie from unmanaged infrastructure fails. Token protection, where available, ties the token to the device it was issued to.

3. Shorten what a stolen cookie is worth. Sensible session lifetimes and re-authentication for privileged operations. If the cookie expires in hours rather than weeks, the window closes on its own.

4. Watch the post-authentication actions, not the login. The login is legitimate. There is nothing to catch there. The registration of a new MFA method, the creation of a forwarding rule, the consent to a new OAuth application: those are the events worth alerting on, and they are what makes a compromise survivable.

5. Make reporting fast and blameless. The user who clicked is the fastest detection you have, and they will only use it if reporting is one button and carries no punishment. An organisation where people hide their mistakes has traded its best signal for a training statistic.

6. Train for the right thing. Spotting typos is obsolete advice. These pages are pixel-perfect because they are the real page. Train the rule that survives: never authenticate from a link. Navigate to the service yourself, from a bookmark. That single habit defeats the whole chain regardless of how good the lure is.

Detection

• Impossible travel and new-ASN sign-ins for a session that authenticated normally minutes earlier. The cookie moves; the person does not.
• A session token used from a different user agent or device fingerprint than the one it was issued to. This is the highest-fidelity signal available for token replay.
• New MFA method registered, alert on every one, and treat it as urgent when it follows a sign-in from an unusual location.
• New OAuth app consent, app password creation, or a new mail forwarding or inbox rule. Rules that move messages containing "security", "verify" or "password" to Deleted Items are close to a definitive indicator.
• Sign-ins to your tenant from hosting providers and VPS ranges. Legitimate staff rarely sign in from a datacentre.
• Newly registered domains resembling yours or your IdP's, certificate transparency logs will tell you, and this is one of the few chances to catch the infrastructure before the campaign.
• Mail from established external partners with an unexpected link, thread hijacking from a compromised supplier is the hardest variant and it defeats reputation-based filtering by design.

Take this away

The attack does not defeat multi-factor authentication. It waits for it to succeed and takes the receipt.

Which means the security question is not "do we have MFA?" but two harder ones: can our MFA be completed through a proxy on a domain we do not own?, and what would we detect in the ten minutes after somebody's session was stolen?

If the answers are "yes" and "nothing", the controls to change are the origin binding and the post-authentication alerting, in that order.

---

Further reading

• Microsoft: token theft and adversary-in-the-middle playbooks
• FIDO Alliance on phishing-resistant authentication
• MITRE ATT&CK T1557, Adversary-in-the-Middle