Tycoon2FA Came Back in Weeks. The OAuth Device-Code Variant Uses Microsoft's Own Login Page Against M365.
Tycoon2FA is back six weeks after the Microsoft/Europol takedown — now phishing OAuth device-code consents against M365 via a Trustifi-laundered relay.
Six weeks after Microsoft and Europol seized Tycoon2FA's infrastructure, the kit is back — with a new OAuth device-code variant that abuses a legitimate email security vendor to launder its reputation and satisfies MFA against Microsoft's own login page.
WALTHAM, MA — eSentire's Threat Response Unit disclosed this week that the Tycoon2FA Phishing-as-a-Service kit — taken down in March by a coalition led by Microsoft and Europol — has resumed operations with a new attack method: OAuth Device Authorization Grant phishing to hijack Microsoft 365 accounts. The variant abuses Trustifi, a legitimate enterprise email security vendor, as a reputation-laundering relay. The attack chain routes victims through a Trustifi click-tracker, a Cloudflare Workers throwaway subdomain, and an encrypted payload — and ends with the victim entering an attacker-generated device code at microsoft.com/devicelogin. The MFA prompt that follows is real. The OAuth tokens it grants go to the attacker.
One successful consent gives the operator working tokens for the entire Microsoft 365 surface — Exchange Online, Microsoft Graph, OneDrive — via the Microsoft Authentication Broker client ID. Tycoon2FA operators kept their codebase across the takedown and adapted within weeks; the same AES encryption key, anti-debug timing trap, and backend route grammar from 2025 are present in the 2026 campaign. The variant is operational against organizations whose Conditional Access policies don't explicitly block OAuth device-code flows — which is most of them.
How the Variant Works
The attack chain has seven steps. (1) The victim receives a lure email — vendor invoice reminder, Microsoft 365 voicemail notification — containing a Trustifi click-tracking URL. (2) Trustifi issues an HTTP 307 redirect to a Cloudflare Workers throwaway subdomain. (3) The Workers endpoint serves an AES-GCM-encrypted payload with the key, IV, and auth tag inline. (4) A four-layer in-browser delivery chain runs anti-debug, headless-browser, and ASN-filter checks; decoy benign content is served to anything that looks like an analyst. (5) The victim sees a Microsoft 365 voicemail lure and is instructed to enter a user code at microsoft.com/devicelogin. (6) The victim authenticates against real Microsoft infrastructure and completes their own MFA. (7) The OAuth Device Authorization Grant flow issues tokens — to the attacker's device, not the victim's.
The trust assumption Device Authorization Grant breaks is that the entity completing the MFA is the one receiving the tokens. In standard authorization-code flow, that's true — the browser session that completes MFA is the one that holds the resulting tokens. In device-code flow, the device requesting the tokens and the device completing the user prompt are deliberately decoupled, which is the whole point — it's what lets a TV or printer authenticate against an account by displaying a code that the user enters on their phone. Phishing this flow inverts the design assumption: the user prompt happens on the victim's device, but the device requesting tokens is the attacker's.
The Trustifi Pattern
Trustifi is not the bug. Trustifi is a legitimate enterprise email security platform whose click-tracking URLs are used by its own customers to instrument links in outbound emails. eSentire is explicit that there is no vulnerability in Trustifi itself and no evidence Trustifi has been compromised. The events.trustifi.com click-tracker is being used as designed — a client-side redirect with HTTP 307 to whatever URL its customer configured.
The reason Tycoon2FA operators care: when a recipient's gateway scanner sees a link that begins with events.trustifi.com, it sees a well-categorized, clean-reputation domain operated by an enterprise email security vendor. Gateways with reputation-based filtering — which is most of them — won't block the URL. The attacker's actual destination, hosted on a Cloudflare Workers throwaway, never appears in the recipient's gateway logs at delivery time. This is the same reputation-laundering pattern we covered in the OpenAI TanStack disclosure and the broader pattern of trusted infrastructure being weaponized to pass the gateway test. Trustifi is a security vendor. The irony is operational.
Why MFA Doesn't Stop This
Strong MFA — TOTP, push notifications, FIDO2 — is the recommended baseline for resisting credential phishing. It works because the attacker, having phished a password, can't satisfy the second factor without the user's device. OAuth device-code phishing routes around that defense entirely. The user satisfies the MFA challenge themselves, against legitimate Microsoft endpoints, because the prompt they're seeing is a legitimate Microsoft prompt. The attacker doesn't need to phish the second factor. The attacker doesn't need to intercept anything. The attacker only needs the user to enter the code they generated on the device-login page.
This is the same architectural insight that drove the broader developer-workstations-as-beachhead pattern — defenders hardened the obvious attack surface (passwords + MFA), so adversaries pivoted to surfaces where the hardened control isn't applicable. Conditional Access blocking device-code flows is the specific countermeasure here, but most organizations haven't deployed it because device-code flow has legitimate uses (CLI tools, edge devices, IoT) and blanket-blocking creates support tickets.
The CyberSignal Analysis
Signal 01: Takedowns Slow Operators by Weeks, Not Quarters
The March 2026 Tycoon2FA takedown — coordinated by Microsoft DCU, Europol, Cloudflare, Coinbase, Intel471, Proofpoint, Shadowserver, SpyCloud, Trend Micro, and eSentire — seized 330 domains and infrastructure in six countries. The operators were back online within weeks because they had codebase backups and the takedown didn't compromise the operators themselves, only their infrastructure. The same AES key, the same anti-debug grammar, the same Check Domain routes appear in the post-takedown variant. The lesson for defenders is that infrastructure-only takedowns are reputation events for the coalition more than operational defeats for the adversary. Sanctions, arrests, and codebase compromise move the needle; domain seizure resets it for three to six weeks.
Signal 02: OAuth Governance Is the 2026 Identity Priority
MFA enforcement was the 2018-2024 identity priority. Every major enterprise has now deployed MFA across most users, and credential-only phishing returns are dropping. OAuth governance — what client IDs your tenant trusts, which consent flows are allowed, which device authorization paths are permitted — is the next surface. The Tycoon2FA device-code variant exploits the lowest-friction governance gap: Conditional Access policies that don't explicitly forbid device-code authentication. Microsoft published the recommended block as a CA template two years ago; eSentire's data suggests most tenants haven't deployed it. The defender opportunity is short — once operators see device-code blocks rolling out, they'll pivot to the next OAuth flow with insufficient guardrails (authorization code with custom redirect URIs, refresh token cycling, broker-to-broker grant). The structural fix is governance, not patches.
What to Do This Week
- Deploy a Microsoft Entra Conditional Access policy blocking OAuth device-code authentication for all users except a documented allow-list. Microsoft provides this as a template policy.
- Restrict user consent for new applications — set tenant-wide consent to admin-approval-required for any non-Microsoft-verified publisher.
- Enable Continuous Access Evaluation (CAE) so revoked tokens are honored within minutes instead of hours.
- Hunt for Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) sign-ins from node, undici, or axios user-agents and from AS45102 IP space — eSentire's IOCs are published.
- Brief your SOC: the 'MFA blocks account takeover' assumption is operationally false for device-code-authorized sessions. Add token-grant audit events to your account-takeover detection logic.
