Adversary-in-the-Middle: how phishing kits learned to walk straight through your MFA

For a decade, the answer to phishing was "turn on multi-factor authentication." It was good advice. It is no longer sufficient advice. A class of phishing kit now steals the one thing MFA can't protect — the live session — and it is sold by subscription, with customer support.

Multi-factor authentication does exactly one job well: it proves, at the moment of sign-in, that the person holding the password also holds a second factor. For years that closed the door on the overwhelming majority of account-takeover attacks, because the attacker had the password and nothing else. Defenders got comfortable. "We have MFA" became shorthand for "we're covered."

Attackers adapted, as attackers do. Rather than try to defeat the second factor, they decided to let the victim pass it — and simply steal what the identity provider hands out afterward. That artifact is the session token, and it is the master key this whole article is about. The technique is called adversary-in-the-middle (AiTM) phishing, and by 2025 it had become the dominant form of credential phishing that security teams actually encounter. Cisco Talos found that roughly 60% of its incident-response engagements in 2024 involved an identity component, and that nearly half of early-2024 incidents turned on an MFA weakness — fatigue, token theft, or rogue device registration rather than a cracked password. (Cisco Talos IR Trends.)

What actually gets stolen — and why it matters

Start with the mechanics, because the defense follows directly from them. When you sign in to Microsoft 365, Google Workspace, or Okta, the server doesn't ask for your password on every click. After you authenticate once — password plus MFA — it issues a session token (carried in a browser cookie): a signed credential that says "this browser has already proven who it is; let it through." That token is what keeps you logged in for the rest of the day.

Here is the crucial asymmetry. MFA validates the authentication event. The token represents the session. Those are two different things, and only the first is protected. Once the token exists, anyone holding it is logged in — no password, no code, no prompt. Classic phishing stole the password and ran into the MFA wall. AiTM waits for you to climb over the wall yourself, then lifts the token out of your pocket on the way down.

Because the proxy relays the real login page, the victim experiences nothing unusual: the branding is correct because it is the real branding, the MFA prompt is real, the approval works. Nothing looks off, because from the user's side of the glass, nothing is off. The only lie is the address bar — a lookalike domain the proxy is served from — and modern kits work hard to keep even that from mattering, as we'll see.

Phishing-as-a-service: crime that ships like software

None of this requires the attacker to be sophisticated. The reverse-proxy engine — the genuinely clever part — was solved years ago and packaged. The open-source framework Evilginx demonstrated the technique publicly and became the technical basis that commercial operators copied and productized. What followed was a full phishing-as-a-service (PhaaS) economy: subscription kits sold and supported over Telegram, complete with hosting, anti-analysis features, template libraries for every major brand, and update cadences that mirror legitimate SaaS.

The business model is the story. When a working reverse-proxy attack costs an entry-level criminal a monthly subscription and requires no ability to write one, the volume follows. Takedowns land — Microsoft and Europol seized 300+ Tycoon 2FA domains in a March 2026 action, and Microsoft disrupted ONNX in late 2024 — but operators re-provision within weeks, because the infrastructure is disposable and the customers are still paying.

The full kill chain

A modern AiTM operation is a chain of small, deliberate steps, each designed to survive one layer of defense. Understanding the whole sequence is what lets you place controls where they actually bite.

1. The lure. An email, an SMS, or increasingly a QR code or evasive attachment, impersonating a routine business flow — a DocuSign envelope, a shared SharePoint file, an HR "acknowledge the new code of conduct" notice. Microsoft documented a multi-stage "code of conduct" campaign in 2026 that ended in exactly this token compromise.
2. Trusted-service redirects. The link often routes through a legitimate service — a real cloud redirector, Google Sites, a trusted CDN — so the first hop has a spotless reputation and passes URL filters.
3. The CAPTCHA gate. Before the phishing page loads, a Cloudflare Turnstile (real or faked) fingerprints the visitor. Automated scanners and sandboxes get a benign challenge; only a real human browser is served the actual kit. This single trick blinds a large share of automated analysis.
4. The relay. The victim reaches the lookalike page and signs in. The proxy passes credentials and the MFA response to the real identity provider live, and the login genuinely succeeds.
5. Token theft. The proxy captures the session cookie the provider issues and ships it to the attacker — often straight into a Telegram bot.
6. Replay. The attacker injects the cookie into their own browser and is inside the mailbox, with no further prompt.
7. Persistence and monetization. This is where the real damage begins, and it is worth its own section.

What the attacker does with your mailbox

Microsoft's analysis of the Storm-1167 campaign in 2023 remains the clearest public worked example, and the post-compromise playbook it documented is still the template. Once inside, the actor:

• Registers a new MFA method — in Storm-1167's case a phone number the attacker controlled — so they can come back through the front door even after the stolen token expires. Because the session was already trusted, adding the method raised no challenge.
• Creates hidden inbox rules that auto-forward or auto-delete messages matching keywords like invoice or payment, so the victim never sees the fraud unfolding in their own name. These rules can be created in a way that doesn't show in the normal Outlook interface — you need Get-InboxRule -IncludeHidden in Exchange Online PowerShell to see them.
• Grants an illicit OAuth app consent, giving a malicious application standing, token-independent access to the mailbox that survives a password reset.
• Launches internal phishing from the now-trusted account. Storm-1167 sent more than 16,000 second-stage emails to the victim's contacts — mail that sails through filters because it comes from a real, authenticated colleague, inside real threads.

That last move is why AiTM is not just an account problem but a business-email-compromise problem. A single stolen token becomes a beachhead for wire fraud, vendor-payment redirection, and lateral compromise across the organization.

Why your current MFA doesn't help

Here is the uncomfortable part. SMS one-time codes, authenticator-app TOTP codes, and push-approval prompts are all phishable, for the same structural reason: none of them is cryptographically bound to the website you're actually on. They authenticate you; they don't check where you are. So a proxy can present the real prompt on a fake domain, you approve it in good faith, and the protocol has no way to notice. Push approvals add a second failure mode — MFA fatigue, where an attacker who already has the password spams approval requests until a tired or distracted user taps "yes."

And once the token is issued, its origin is irrelevant. A bare session cookie is portable: replay it from any browser, any device, anywhere, and unless something binds it to the original hardware, it just works — typically for the life of the session, which can be hours or days. The token is domain-agnostic by design. That design is the vulnerability.

What actually works

The good news is that the fix is not theoretical and not exotic. It follows directly from the mechanics: if the weakness is that the credential isn't bound to the real domain, use a credential that is.

1. Move high-value accounts to phishing-resistant MFA. Passkeys, FIDO2 security keys, Windows Hello for Business, and certificate-based authentication all share one property that ordinary MFA lacks: the credential is cryptographically bound to the origin domain. When the browser is on a lookalike domain, the authenticator simply won't produce a valid signature — there is nothing for the proxy to relay. CISA classifies exactly these methods as phishing-resistant and everything else (SMS, TOTP, push) as not. Start with administrators, finance, and executives, then widen.

2. Bind the token to the device. Microsoft Entra's token protection (token binding) cryptographically ties the session token to the device it was issued on, so a cookie replayed from the attacker's machine is rejected. Pair it with Conditional Access policies that require a compliant or managed device — which strips most of the value from a bare stolen cookie, because the attacker's unmanaged box doesn't qualify.

3. Shrink the usable window. Turn on Continuous Access Evaluation, which lets the identity provider revoke a session in near real time when risk signals fire — an IP change, a disablement, a new-country sign-in — rather than waiting for the token to expire on its own schedule.

4. Watch for the replay, because that's the visible part. The malicious login itself looks clean; the token's use does not. Alert on sign-ins from hosting-provider/datacenter ASNs, impossible travel, unfamiliar sessions, and — a signal ReliaQuest specifically recommends — the same token in use from two places at once. When something fires, don't just reset the password: revoke the refresh tokens, or the attacker's live session survives the reset untouched.

5. Hunt the persistence. After any suspected token compromise, enumerate hidden inbox rules with -IncludeHidden, review recently registered MFA methods, and audit OAuth app consents — the three things Storm-1167 taught us to expect. Restrict user consent to unverified apps in the first place, so that door is closed before it's used.

What to do

1. Enroll your highest-risk accounts in phishing-resistant MFA now — admins, finance, leadership. Passkeys and FIDO2 keys are origin-bound and cannot be relayed.
2. Turn on token protection and require managed/compliant devices in Conditional Access, so a stolen cookie is useless off a trusted machine.
3. Enable Continuous Access Evaluation to cut the token's usable lifetime when risk appears.
4. Alert on the replay signals in the table above, and make token revocation — not just password reset — your standard response to a suspected takeover.
5. Add hidden-inbox-rule, new-MFA-method, and OAuth-consent checks to your incident playbook, and restrict user consent to unverified apps by default.
6. Treat "we have MFA" as the start of the conversation, not the end of it. Ask specifically: which MFA, and is it phishing-resistant?

Related reading

• Microsoft 365 email hardening checklist — the Conditional Access, legacy-auth, auto-forwarding, and audit-logging settings that underpin every defense above, in order of impact.
• The BEC prevention checklist — what a stolen mailbox is used for next, and the payment-verification process that stops the wire.
• If you clicked the link — the first-hour response when an account may already be compromised.

Written by the Family Sentinel security desk — a working Security Architect and the team who watch business and family inboxes around the clock. Sources: Microsoft Threat Intelligence (Storm-1167, June 2023; AiTM/token-compromise campaign reporting, 2024–2026); Sekoia (Tycoon 2FA, Sneaky 2FA analyses); Proofpoint (EvilProxy executive-targeting campaign); Cisco Talos IR Trends; Group-IB (W3LL); ReliaQuest 2025 Annual Threat Report; CISA guidance on implementing phishing-resistant MFA. Figures are as reported by the cited source for the year noted. Have a suspicious message you'd like a verdict on? Forward it to security@familysentinel.org — no charge, no strings.