AitM Phishing in 2026: How Starkiller and Tycoon 2FA Bypass MFA — and How to Defend

In early March 2026, two events put MFA bypass back in the spotlight. Europol dismantled Tycoon 2FA — the world’s largest phishing-as-a-service platform — while a new suite called Starkiller demonstrated that AitM phishing has evolved from a sophisticated nation-state technique into a commodity SaaS product anyone can buy.

The message is clear: if your organization relies on TOTP, push notifications, or SMS for MFA, it is not phishing-resistant. Here’s how these attacks work and what actually stops them.

How AitM Phishing Works

Traditional phishing clones a login page and captures credentials. AitM phishing is fundamentally different — it doesn’t clone anything. It proxies the real site.

sequenceDiagram
    participant V as Victim
    participant P as Attacker's Reverse Proxy
    participant R as Real Login Page<br/>(Microsoft 365, Google)

    V->>P: Enters credentials
    P->>R: Forwards credentials
    R-->>P: MFA challenge
    P-->>V: Displays MFA prompt
    V->>P: Approves MFA (TOTP / push)
    P->>R: Forwards MFA response
    R-->>P: Authenticated session cookie
    P-->>V: Login success ✅
    Note over P: Captures everything:<br/>passwords, TOTP codes,<br/>push approvals, session cookies
    P->>P: Attacker now has<br/>full session access 🔓

The victim sees the legitimate website. They enter their real password, approve their real MFA prompt, and get logged in normally. Meanwhile, the proxy captures the authenticated session cookie. The attacker now has a fully authenticated session — no password or MFA code needed to use it.

This is why AitM bypasses all traditional MFA: the victim is authenticating against the real service. The proxy just copies the result.

Starkiller: AitM as a SaaS Product

Starkiller, operated by a threat group calling itself Jinkusu, packages this attack into a subscription service with a dashboard UI:

Technical architecture:

• Runs a headless Chrome instance inside Docker as a live reverse proxy
• Loads the real login page and forwards all user interactions
• Captures every keystroke, form submission, session token, and recovery code
• No template maintenance needed — the proxy always shows the current version of the target site

Operator features:

• Brand selection (Microsoft 365, Google Workspace, etc.)
• Custom keyword injection for targeted campaigns
• URL shortener integration for obfuscation
• Real-time monitoring of captured credentials

Why traditional defenses fail:

• URL blocklisting doesn’t work — the phishing domain serves dynamic content from the real site
• Browser fingerprinting detection is defeated because a real browser (headless Chrome) is making the requests
• Email filters catch some campaigns, but the landing pages look identical to the real thing because they are the real thing, proxied

Tycoon 2FA: Scale of the Problem

Before its takedown, Tycoon 2FA was Microsoft’s “most prolific phishing platform observed” in 2025. The numbers reveal the industrial scale of modern PhaaS:

How it worked:

1. Operator signs up, selects pre-built templates (Microsoft 365, OneDrive, Outlook, Gmail)
2. Platform generates phishing pages with AitM proxy infrastructure
3. Victim clicks link → sees real Microsoft login → enters credentials + MFA
4. Platform captures session cookie and delivers it to operator via dashboard or Telegram
5. Operator uses the session cookie to access the victim’s account — fully authenticated

Anti-detection features:

• Domains rotated every 24-72 hours
• Custom CAPTCHAs to filter security scanners
• Browser fingerprinting to detect automated analysis
• Code obfuscation to evade static detection

The March 2026 takedown — coordinated by Europol with Microsoft, Trustwave, Cloudflare, Intel 471, SpyCloud, Proofpoint, and Trend Micro — seized the infrastructure. But as Starkiller demonstrates, the technique is now commoditized. Shutting down one platform doesn’t eliminate the threat.

What MFA Stops AitM — and What Doesn’t

Why FIDO2/Passkeys Are Different

FIDO2 authentication includes the origin (domain name) in the cryptographic challenge. When the user’s security key or passkey signs the authentication response, it includes a hash of https://login.microsoftonline.com. If the user is on https://login-microsoftonline.attacker.com instead, the origin doesn’t match, and the key refuses to sign.

The attacker can’t fix this. Even though the reverse proxy loads the real Microsoft page, the browser’s WebAuthn API checks the URL bar’s actual domain — not what the page content says. No proxy, no iframe, no redirect can change what the browser reports as the origin.

Legitimate login:
  Browser URL: https://login.microsoftonline.com
  WebAuthn origin: https://login.microsoftonline.com  ← MATCH ✅

AitM proxy:
  Browser URL: https://login-secure365.attacker.com
  WebAuthn origin: https://login-secure365.attacker.com  ← MISMATCH ❌
  Passkey refuses to sign

For implementation details on deploying passkeys, see our Passkeys Adoption Guide: FIDO2 WebAuthn in Production.

Defending Your Organization

Step 1: Deploy Phishing-Resistant MFA

NIST SP 800-63-4 (finalized July 2025) now requires organizations to offer a phishing-resistant MFA option. The practical choices are:

• FIDO2 security keys (YubiKey, Google Titan) — best for high-value accounts, admin access
• Platform passkeys (Apple, Google, Microsoft) — best for broad user deployment
• Certificate-based authentication — best for device-managed environments (MDM)

Start with privileged accounts (admins, finance, executives) and expand.

Step 2: Enforce Phishing-Resistant MFA via Conditional Access

Deploying passkeys isn’t enough — you must require them for authentication. In Microsoft Entra ID:

Conditional Access Policy:
  - Users: All users (or start with admins)
  - Cloud apps: All cloud apps
  - Grant: Require authentication strength → Phishing-resistant MFA

In Keycloak, configure WebAuthn as a required authentication flow, not just an option.

Step 3: Reduce Session Cookie Value

Even if AitM captures a session cookie, you can limit the damage:

• Continuous Access Evaluation (CAE): Revoke sessions in real time when risk signals change (IP change, impossible travel)
• Token binding: Bind session tokens to the client’s TLS channel or device certificate
• Short session lifetimes: Reduce the window for stolen session use. See our guide on Keycloak session timeout configuration

Step 4: Detect AitM in Your Logs

Look for these signals:

• Login from known proxy infrastructure — correlate login IPs against known AitM proxy ranges
• Session cookie used from different IP — the attacker’s IP will differ from the victim’s
• Impossible travel — login from the victim’s location followed immediately by API calls from the attacker’s location
• OAuth token minting immediately after login — attackers often create persistent OAuth tokens right after session theft

For organizations using OAuth 2.0, monitor for unusual token grants from newly authenticated sessions.

Step 5: Block Device Code Flow Abuse

A related attack vector — OAuth Device Authorization Grant (RFC 8628) phishing — is surging alongside AitM campaigns. Disable device code flow for users who don’t need it:

• Microsoft Entra ID: Conditional Access → Block device code flow
• Keycloak: Disable the Device Authorization Grant in client settings
• Auth0: Disable Device Authorization in application settings

The Bigger Picture

AitM phishing isn’t new — it was documented as early as 2017 with tools like Evilginx. What changed in 2026 is commoditization. Tycoon 2FA served 2,000 operators at $120-350/month. Starkiller packages the entire attack into a Docker container with a dashboard.

The defense is equally clear: origin-bound authentication (FIDO2, passkeys, certificates) is the only factor category that structurally defeats proxied phishing. Over 3 billion passkeys are now in active use globally. The technology is ready. The question is whether organizations will deploy it before the next Tycoon 2FA emerges — which, given the open-source tooling available, is a matter of weeks, not months.