MFA Is Dead. Long Live Phishing-Resistant Auth: The 2026 AiTM Defense Playbook

TL;DR

Adversary-in-the-Middle (AiTM) phishing has rendered traditional multi-factor authentication — SMS OTPs, TOTP codes, push notifications — operationally obsolete as a primary defence layer. The tooling to execute these attacks is publicly available, requires no advanced tradecraft, and is now bundled into polished all-in-one Phishing-as-a-Service platforms with AI assistants, domain management, and real-time victim tracking. Bluekit, the latest entrant documented by Varonis Threat Labs this week, ships 40+ brand templates, AiTM session-cookie theft, and a jailbroken LLM assistant in a single operator dashboard — aimed at GitHub, iCloud, Microsoft 365, ProtonMail, Ledger, and more. The defence is not "more MFA." It is a fundamental shift to phishing-resistant authentication (FIDO2/passkeys), origin-bound session validation, and continuous identity assurance. This playbook tells you exactly how to get there.

---

Background: How We Got Here

Multi-factor authentication was introduced to defeat a simple problem: stolen passwords. The logic was sound. If the attacker has your password but not your phone, they cannot log in. For a decade, that logic held well enough.

Two things broke it.

First, the adversary model evolved. Nation-state actors and organised cybercriminal groups stopped trying to steal MFA codes and started trying to relay them. The technique is called adversary-in-the-middle (AiTM), a real-time reverse proxy attack that sits between the victim and the legitimate service. When the victim types their credentials into what looks like a real login page, the proxy forwards those credentials to the real site in real time, receives the MFA challenge, forwards that challenge to the victim, collects the response, returns it to the real site, and walks away with a fully authenticated session token. The MFA code was genuine. The login was real. The session belongs to the attacker.

Push notification fatigue compounds this. When a victim suspects something is wrong and dismisses the push, the attacker simply triggers 15 more until the victim approves one to stop the noise.

Second, the tooling was commoditised. Evilginx, Modlishka, Muraena — the original open-source AiTM proxy frameworks — have been available and actively maintained on GitHub for years. They require no vulnerability, no exploit, and no deep technical skill. They require a VPS, a plausible domain, and a TLS certificate. The attacker's barrier to entry is approximately $20 and a few YouTube tutorials.

In 2026, the attack is now being packaged and monetised at scale.

---

Technical Analysis: Bluekit and the PhaaS Evolution

Varonis Threat Labs published their analysis of Bluekit in late April 2026. The kit represents what happens when AiTM tooling meets the SaaS business model.

What Bluekit Is

Bluekit is a Phishing-as-a-Service platform accessible via a managed operator dashboard. Its differentiators versus earlier PhaaS offerings:

All-in-one operator workflow. Prior PhaaS markets were fragmented. Operators bought credential-harvesting pages from one seller, a domain rotator from another, an SMS gateway from a third, and stitched infrastructure themselves. Bluekit collapses that into one panel — site creation, domain purchase/registration, captured credential logs, Telegram exfil, and campaign analytics from a single interface.

40+ brand templates. The template library covers consumer email (Gmail, Outlook, Hotmail, Yahoo, ProtonMail), developer platforms (GitHub), social media (Twitter/X), cloud identity (iCloud, Apple ID), enterprise productivity (Microsoft 365, Zoho), retail (Zara), and cryptocurrency wallets (Ledger). The breadth signals both broad targeting and deliberate prioritisation of high-value identity targets: developer credentials unlock supply chains; Ledger credentials unlock wallets.

AiTM session-cookie theft. The kit does not merely harvest passwords. Bluekit intercepts and stores session cookies and local storage data in real time. The Mammoths Details view — Varonis' term for the session tracking panel — maintains a live view of the victim's post-login browser state, replaying session dumps continuously. This means the attacker can take over an authenticated session long after the victim's login has completed, without the victim taking any subsequent action.

The AI assistant: Abliterated Llama. This is the detail most coverage has underweighted. Bluekit ships its own AI assistant built on an abliterated version of Meta's Llama — a model from which all safety guardrails and refusal filters have been deliberately removed. The assistant interface also shows GPT-4.1, Claude Sonnet 4, Gemini, and DeepSeek variants as selectable models, though Varonis could only confirm the abliterated Llama was functional during their review. Researcher Daniel Kelley noted this marks a shift "toward open-weight models without safety guardrails, which is more consistent than working around prompt-level filters." The current implementation generates campaign skeletons (structured drafts with placeholders) rather than finished lures — but the development velocity is fast. Voice cloning, geolocation emulation, and antibot cloaking are in active development.

Telegram exfiltration. All stolen data — credentials, session cookies, local storage — is forwarded in real time to an operator-controlled Telegram channel. This means no C2 infrastructure to build or defend, near-zero latency between victim compromise and attacker receipt, and exfil that blends into normal Telegram traffic.

The AiTM Mechanics — Step by Step

Understanding exactly how the relay works is essential to understanding why the defence is architectural, not procedural.

1. Attacker stands up a reverse proxy (Evilginx / Modlishka / Bluekit's embedded proxy) at a convincing domain, e.g., microsoft-secure-verify[.]io. Wildcard TLS cert is provisioned automatically. The domain may resolve to a CDN-backed subdomain to defeat URL categorisation.

2. Victim receives a lure (email, SMS, LinkedIn DM, or QR code in a physical or digital document). The lure references a legitimate reason to re-authenticate — security alert, MFA re-enrolment, account review.

3. Victim clicks. The proxy transparently loads the real Microsoft login page through itself and mirrors it to the victim. The victim sees pixel-perfect Microsoft UI. Every interaction is forwarded upstream in real time.

4. Victim enters username and password. The proxy captures both and relays them to Microsoft.

5. Microsoft responds with an MFA challenge (push, TOTP, or SMS). The proxy relays the challenge UI back to the victim.

6. Victim completes the MFA challenge — on what they believe is a real Microsoft page, and which is, for the purposes of Microsoft's authentication logic, a real response.

7. Microsoft issues a session token (cookie). The proxy intercepts it before forwarding the victim to a success page. The victim's browser sees a normal post-login experience. The attacker now holds a live authenticated session.

Why conventional MFA cannot interrupt this: SMS OTPs, TOTP codes, and push notifications all authenticate the exchange of a shared secret. They do not verify that the session origin is the same endpoint the authenticating user occupies. They cannot detect proxied sessions. The MFA challenge was answered correctly, by the real user, in real time. From Microsoft's perspective, nothing anomalous occurred.

The Breach-to-AiTM Attack Chain

The BleepingComputer analysis of the February 2026 Figure breach (967,200 exposed email records) offers a concrete illustration of how credential exposures feed AiTM campaigns:

• Hour 0–6: The exposed email list enters breach aggregators. Adversaries combine it with RockYou2024 and LinkedIn password dumps for credential stuffing. At a 2–3% success rate, that yields ~19,000–29,000 valid credential pairs.
• Hour 6–24: AI-assisted tooling generates personalised phishing campaigns from the email list. Lures are tailored with job title, company name, and public LinkedIn data.
• Parallel: Help desk social engineering begins. Valid email addresses plus basic OSINT enable impersonation calls to IT support requesting MFA device resets — bypassing authentication technology entirely.
• Ongoing: AiTM phishing campaigns target the validated credentials to steal authenticated sessions for accounts where passwords were already confirmed valid.

The Figure breach required no vulnerability exploitation. The attack chain it enables does not either.

---

IOCs and Indicators

Note: Bluekit infrastructure rotates rapidly. The following patterns are structural, not static IP lists.

• Domain patterns: AiTM proxy domains commonly use brand name + "secure", "verify", "login", "portal", or "auth" + common TLDs (.io, .co, .cloud, .net). Example patterns: microsoft-secure-[random].io, github-login-verify[.]co
• TLS fingerprints: Evilginx and derivatives frequently use Let's Encrypt wildcard certs issued within 48 hours of domain registration. New domain + wildcard Let's Encrypt cert = elevated suspicion signal.
• HTTP headers: Bluekit and related kits modify X-Forwarded-For handling inconsistently. Proxy detection systems can flag session origin mismatches in authentication logs.
• Telegram exfil: Real-time Telegram bot webhooks from phishing infrastructure. Network monitoring for outbound Telegram API calls from unusual internal hosts.
• AI assistant fingerprinting: The abliterated Llama model signature in phishing campaign content — placeholder syntax like [RECIPIENT_DEPARTMENT], [TARGET_QR_BLOCK] in raw source of intercepted lures.
• Session cookie replay: Authentication events from new IP/device/geolocation for accounts that authenticated within the last 30 minutes from a different context.

---

Lyrie Take

The industry has been on notice about AiTM for three years. Microsoft documented it in Storm-0558 and dozens of BEC campaigns. CISA issued guidance. Academic papers named it "the end of legacy MFA." And yet enterprise MFA deployments globally remain dominated by TOTP apps and push notifications — technologies that provide zero protection against a proxied session.

The Bluekit release is not a technological leap. It is a market signal: AiTM has graduated from a targeted, sophisticated attack to a commodity service affordable to any mid-tier criminal operator. The abliterated LLM is similarly notable less for its current capability — campaign skeleton generation with placeholders — and more for what it signals about the development trajectory. Six months from now, that assistant will be generating finished, personalised, undetected lures without human cleanup.

The window to mandate phishing-resistant authentication before this attack class becomes routine in mid-market enterprise is closing. It may already be closed for organisations that haven't started.

What Lyrie watches next:

• Bluekit feature releases, specifically voice cloning integration. Vishing + AiTM + AI-generated voice clone of the CFO's IT contact is a sequence that defeats both technical and human controls simultaneously.
• Passkey adoption rates in enterprise SSO vendors (Okta, Entra ID, Ping). Current enterprise passkey deployment is estimated below 12%.
• Emergence of AiTM-as-a-Service targeting specific verticals — legal, M&A advisory, healthcare — where a single authenticated session to a document management system carries multi-million dollar consequence.

---

Defender Playbook

This playbook is tiered by implementation priority. Start with Tier 1 regardless of current maturity level.

Tier 1 — Break the AiTM Kill Chain (Do This Now)

1. Deploy FIDO2 / WebAuthn / Passkeys for all privileged accounts. This is the only authentication mechanism that defeats AiTM at the protocol level. FIDO2 credentials are origin-bound: the authenticator signs a challenge that includes the RP (Relying Party) origin — the exact domain the browser is communicating with. A proxy domain does not match login.microsoft.com. The authentication fails. The relay attack fails. This is cryptographic, not heuristic. It cannot be social-engineered at the authentication layer.

Priority order: privileged admin accounts → all M365/Azure AD/Okta users → external-facing service accounts.

Resources: Microsoft Entra ID phishing-resistant MFA policy documentation; Okta FastPass; NIST SP 800-63-4 (finalised late 2024) defines AAL3 as requiring phishing-resistant authentication.

2. Enforce Conditional Access with sign-in risk policies. Deploy session risk evaluation at every authentication event. Flag and step-up challenge: new device + new geolocation + MFA from anomalous IP, impossible travel, and — critically — new authenticated session + same account + different geolocation within 60 minutes (proxy relay indicator).

3. Enable Continuous Access Evaluation (CAE) in Microsoft 365 / Azure AD. CAE invalidates tokens near-instantly on IP change, session revocation, or policy violation. A session token stolen via AiTM relay that immediately hops to an attacker-controlled IP in a different country is revoked before the attacker can do meaningful damage. This is already available in M365 E3 and above. Most organisations have not enabled it.

Tier 2 — Reduce the Attack Surface

4. Implement DMARC p=reject + DKIM + SPF for all sending domains. Bluekit lures arrive via email. Domain spoofing and lookalike domains are their primary delivery vector. DMARC reject policy with proper DKIM and SPF eliminates spoofed internal domain impersonation. Register common lookalike variants of your domain and configure them to p=reject with no legitimate mail flow.

5. Enable email URL rewriting and real-time detonation. Modern secure email gateways (Microsoft Defender, Proofpoint, Mimecast) rewrite URLs in inbound email and check them at click time. AiTM proxy domains are often brand-new and will not have malicious reputation at delivery time — but may be flagged by click-time detonation against phishing classification models. Enable click-time protection even if you have delivery-time scanning.

6. Block newly registered domains (< 30 days) at DNS and web gateway. The vast majority of AiTM infrastructure is created within days of use. A DNS or proxy policy blocking resolution of domains registered in the last 30 days eliminates the bulk of opportunistic proxy infrastructure. Acceptable false positive rate in enterprise contexts is manageable via exception policy.

7. Audit and restrict OAuth app permissions. AiTM attacks that successfully capture sessions often proceed to create persistent OAuth application grants, enabling long-lived access that survives password resets. Review OAuth app consent grants monthly. Require admin approval for all third-party app consent. Restrict user-level OAuth consent to pre-approved publishers.

Tier 3 — Detect and Contain What Gets Through

8. Monitor for session anomalies in SIEM. Key detection signatures:

• Authentication event followed by resource access from a different IP/ASN within 5 minutes
• User agent string change within an authenticated session
• Token lifetime anomalies (sessions that appear to refresh at unusual frequency — AiTM proxies sometimes re-request tokens to maintain relay fidelity)
• Multiple MFA push events (>3) for a single login attempt in a 5-minute window (fatigue attack indicator)
• Helpdesk tickets requesting MFA reset combined with recently phished email address in threat intel feeds

9. Implement Hardware Security Keys for the highest-risk roles. For C-suite, legal, finance, M&A, and cloud infrastructure admins: mandate physical FIDO2 hardware keys (YubiKey 5 series, Google Titan). No exceptions, no fallback to push. The compromise of these accounts via AiTM represents existential risk.

10. Run tabletop exercises simulating the breach-to-AiTM chain. Test whether your IR team can identify an AiTM-originated session compromise from SIEM logs within 30 minutes. Most cannot on first attempt. The Figure breach example is a good scenario template: 967K emails exposed → credential stuffing → AiTM phishing campaign targeting validated accounts → session token theft → lateral movement.

11. Educate to a specific standard (not generic phishing awareness). The required user behaviour change is narrow and learnable: if you receive an unexpected authentication prompt on a device that is not your YubiKey/passkey-enrolled authenticator, stop and report. Generic "hover over links" phishing training provides zero mitigation against AiTM because the proxy domain may look entirely plausible and the TLS cert is valid.

---

The Regulatory Dimension

FBI Operation Winter SHIELD, launched January 28, 2026, is a two-month campaign explicitly recommending passkeys as the cornerstone of phishing resilience. CISA and NSA's ongoing guidance already positions FIDO2 as the mandatory path for any organisation handling sensitive federal data. NIST SP 800-63-4, finalised in late 2024, formally elevated phishing-resistant authentication to AAL3 — the highest assurance level — and explicitly deprecated SMS OTP for high-assurance use cases.

For financial services organisations, FFIEC, NCUA, and OCC examiners are now explicitly reviewing phishing-resistant MFA adoption. The regulatory question is no longer "do you have MFA?" It is "is your MFA phishing-resistant?"

The answer, for most enterprises, is currently no.

---

Sources

1. Varonis Threat Labs — "Meet Bluekit: The AI-Powered All-in-One Phishing Kit" (April 2026): https://www.varonis.com/blog/bluekit

2. HackRead — "New AI-Powered Bluekit Phishing Kit Targets Major Platforms with MFA Bypass Attacks" (April 29, 2026): https://hackread.com/bluekit-phishing-kit-targets-platforms-mfa-bypass-attack/

3. BleepingComputer — "When attackers already have the keys, MFA is just another door to open" (April 2026): https://www.bleepingcomputer.com/news/security/when-attackers-already-have-the-keys-mfa-is-just-another-door-to-open/

4. Corbado — "Why the FBI backs Passkeys in Operation Winter SHIELD" (April 2026): https://www.corbado.com/blog/fbi-operation-winter-shield-passkeys

5. WorkOS — "Adversary-in-the-middle attacks: The threat that makes your MFA useless": https://workos.com/blog/adversary-in-the-middle-attacks

6. NIST SP 800-63-4 Digital Identity Guidelines (2024)

7. CISA / NSA Phishing-Resistant MFA Guidance

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk