In March 2026, Microsoft, working with Europol and industry partners, seized 330 domains behind Tycoon 2FA, a phishing-as-a-service kit. By mid-2025, Tycoon 2FA accounted for about 62 percent of the phishing attempts Microsoft blocked. "Healthcare and education organizations were hit hardest," Microsoft wrote. More than 100 members of Health-ISAC were phished. In New York alone, at least two hospitals, six municipal schools and three universities faced attempted or successful compromise. Microsoft says the incidents "disrupted operations, diverted resources, and delayed patient care."
The kit's selling point was in its name: it was built to beat two-factor authentication. That is the uncomfortable lesson. "MFA" and "phishing-resistant MFA" are not the same thing.
The kit sits in the middle
An adversary-in-the-middle (AiTM) kit does not fake a login page. It relays the real one. In Microsoft's words, attackers "deploy a proxy server between a target user and the website." The user sees their real sign-in screen and types their password. Then they approve the push or enter the code. Every step passes through the attacker's server to the real service and back.
When sign-in succeeds, the service issues a session cookie, and the proxy keeps a copy. The attacker now holds a logged-in session, and the second factor has already done its job. Open-source tools such as Evilginx2 made this easy years ago. Microsoft is careful to add: "this is not a vulnerability in MFA." Tycoon 2FA industrialized the technique, defeating SMS codes, one-time passcodes, and push notifications at scale.
Why a passkey breaks the relay
Every method where a person reads, types or taps something shares this weakness. NIST SP 800-63B-4 defines phishing resistance as the ability of the protocol to "prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier." It must do this without relying on the user's vigilance. NIST says plainly that authenticators requiring manual entry of an output, such as one-time passcodes and out-of-band codes, do not qualify.
WebAuthn, the protocol behind FIDO2 security keys and passkeys, does qualify. NIST calls the mechanism verifier name binding: the authenticator picks its key based on the authenticated domain name of the site. On a lookalike domain there is no matching credential, so there is nothing to relay. That is why CISA has said "the only widely available phishing-resistant authentication is FIDO/WebAuthn." One condition applies: remove the weaker fallbacks. If password-plus-code is still allowed, a kit can push users down to it.
Device-code phishing: the real page, used against you
In February 2025, Microsoft described a device-code phishing campaign by a group it tracks as Storm-2372. The group had been active since August 2024, against targets including government, defense and health. The campaign abuses device code flow, the sign-in method for TVs, printers and conference-room devices. The attacker requests a genuine code and persuades the victim to enter it on Microsoft's real sign-in page. The victim signs in, MFA and all, and the attacker's session receives the access and refresh tokens.
Volexity reported on the technique the same day. It found the method more effective than most targeted spear-phishing it had seen. Part of the reason is that the only link in the lure points to a legitimate Microsoft domain.
In 2026 it went mass-market. In April, Tanmay Ganacharya, Microsoft's VP of security research, told The Register the company was seeing "hundreds of compromises occurring daily across affected environments." In September, Microsoft reported on campaigns using the EvilTokens kit. They had compromised more than 12,000 inboxes in over 10,000 organizations, healthcare among them.
Why passkeys alone do not close this
Here is the honest caveat. In device-code phishing the victim really is on Microsoft's domain, so an origin check has nothing to object to. The user authenticates correctly. The mistake is approving a sign-in for a device that belongs to someone else.
Consent phishing works on a similar principle. Microsoft describes it as tricking users "into granting permissions to malicious cloud applications." A strong login proves who you are. It does not prove that the app you just approved deserves your mailbox.
Lures blend, too. Proofpoint documented fake OAuth apps posing as Adobe, DocuSign and others. They served mainly as a trusted-looking first step that sent victims on to a Tycoon AiTM page. Phishing-resistant MFA would have stopped that last step.
The policy half of the fix
Block device code flow. Microsoft Entra Conditional Access treats it as an authentication flow condition. Microsoft "recommends blocking device code flow wherever possible." A Microsoft-managed policy can do this, noting the flow "is rarely used by customers, but is frequently used by attackers." Managed policies start in report-only mode. Hospitals with meeting-room devices or digital signage should inventory them and scope narrow exceptions.
Take consent away from end users. Allow consent only for verified publishers and low-risk permissions. Route the rest through the admin consent workflow.
Bind tokens to devices. Token protection rejects refresh tokens that are not cryptographically bound to the device they were issued to. It covers only some apps so far, so pair it with network-based policies.
Contain fast. Microsoft advises temporarily disabling a compromised account. Revoking sessions alone can leave access tokens valid for up to an hour.
A short checklist
List which accounts still use SMS, voice, push or codes. Move clinicians and admins to FIDO2/WebAuthn first, then retire the fallbacks.
Block device code flow tenant-wide, and document every exception.
Restrict user consent and turn on the admin consent workflow.
Review existing app grants for broad mail and file permissions.
Enable token protection where supported.
Teach staff one rule: never enter a code or approve an app because an email or a caller asked.
