Tycoon2FA Now Bypasses MFA on Microsoft 365 Accounts

By Yonatan Hoorizadeh — CISSP, CISM, CRISC, AAISM

Published: May 19, 2026

Last updated: May 19, 2026

Tycoon2FA's new device-code variant tricks Microsoft 365 users into pasting an attacker-supplied code at microsoft.com/devicelogin. Real MFA completes at Microsoft's own login servers, and tokens are issued to the attacker's polling client. MFA isn't bypassed; what it authorizes is hijacked. Conditional Access can block the OAuth device-code flow for users who don't need it.

What happened with Tycoon2FA in late April 2026?

Tycoon 2FA, the phishing-as-a-service kit that international law enforcement disrupted in March 2026, came back online within weeks and added OAuth device-code phishing for Microsoft 365 accounts. eSentire's Threat Response Unit caught the new variant in a late-April campaign and published its analysis on May 12, 2026. The lure type changed. The underlying kit did not.

The March 2026 takedown was a coordinated effort by Microsoft and Europol with help from eSentire and other industry partners. The operators kept their codebase intact, stood up fresh infrastructure, and were running normal campaign volume again before the press releases finished circulating.

What's different this time is the lure. The kit used to relay credentials through an attacker-in-the-middle proxy that mimicked the real Microsoft login page. The April 2026 variant doesn't do that. It hands the victim a real Microsoft device code and asks them to type it into Microsoft's real login portal. From the victim's browser, the authentication is genuine. The phishing happens earlier, in what the user thinks they're approving.

eSentire reports the kit still uses the same AES-CBC encryption key it used in 2025 (the string "1234567890123456"), the same anti-debug timing trap, and the same "Check Domain" gate pattern. Code fingerprints don't lie. This is the same operation with a new payload type bolted onto the front.

Why does device-code phishing defeat MFA?

The OAuth 2.0 Device Authorization Grant was built for devices that can't easily display a login form, like smart TVs and command-line tools. There's no cryptographic link between the device that requested the code and the user who approves it. Anyone who initiates a device-code grant against a Microsoft first-party application can collect the resulting tokens from any user who consents.

Most MFA training tells employees to check the URL bar, look for the padlock, and approve the push only if they recognize the sign-in. None of that helps here. The URL bar reads microsoft.com/devicelogin. The padlock is genuine. The push notification is from Microsoft's actual MFA service. The user approves a sign-in because, from where they're standing, every signal looks right.

eSentire's framing of the attack is the most useful line in their report: "The phish does not bypass MFA. It changes what MFA is being used to authorize."

The OAuth client the attacker impersonates is Microsoft Authentication Broker, AppId 29d9ed98-a469-4536-ade2-f981bc1d605e. That's a first-party Microsoft application, and it's a broker. One successful consent issues tokens that can be exchanged for access to Exchange Online, Microsoft Graph, and OneDrive for Business without further prompts. In the Entra sign-in log, the consent appears as a Microsoft application receiving tokens, not as an unknown third-party app, so the unverified-publisher detections that catch most OAuth phishing don't fire.

This is why standard "look for the lock icon" training catches none of it.

How does the Trustifi lure get past email gateways?

The lure email contains a click-tracking URL from Trustifi, a legitimate enterprise email security platform. Trustifi isn't compromised. The operator is abusing its clean-reputation domain, events.trustifi.com, to launder the URL through email gateways that would otherwise block it. After the click, Trustifi issues a 307 redirect to a disposable Cloudflare Workers subdomain that delivers the actual payload.

Reputation laundering is the term researchers use. The first link a recipient sees points to a domain with a long track record of legitimate use, so spam filters and URL reputation services let it through. Behind that link is a throwaway Cloudflare Workers URL — eSentire documented one as cookies.28gholland.workers.dev — which delivers an AES-GCM-encrypted page that decrypts in the victim's browser.

The script then checks the visitor's network ASN against a hardcoded blocklist of 230 vendor names before showing anything malicious. The list, published by eSentire, includes every major cloud provider, every well-known sandbox vendor, the major endpoint AV companies, and the user-agents of AI crawlers from Anthropic and OpenAI. If the visitor isn't a target, the page either redirects to a normal Microsoft Outlook URL or renders a complete decoy site branded "NexusCore," a fictitious domain registrar.

Only after passing all of that does the victim see a Microsoft-branded "voicemail message" lure, with a copy-code button that opens microsoft.com/devicelogin in a popup.

Why does this matter for any business running Microsoft 365?

Every organization on Microsoft 365 is in scope. The attack doesn't depend on a vulnerability, a missing patch, or a misconfiguration. It works against fully patched tenants with strong MFA enrolled. The risk surface is the OAuth device-code flow itself, which is enabled by default in Microsoft Entra and rarely used outside developer or specialty hardware scenarios.

A successful consent gives the attacker working access tokens for the user's mailbox, files, and Graph API permissions. eSentire's incident telemetry shows the operator backend starting non-interactive Exchange and Graph calls within two seconds of consent, which is fast enough that traditional log review catches it only after data has moved.

For a finance team using M365, that's invoice routing, supplier payment changes, and a familiar mailbox to send forwarded "updated wire instructions" from. For a healthcare practice, it's PHI exposure under HIPAA's Security Rule and an HHS Office for Civil Rights breach-notification clock. For a regulated SMB on cyber insurance, it may be a coverage trigger depending on what the underwriting questionnaire promised about account access controls.

A fractional CISO running a tabletop on token theft asks three things: do you know which accounts can approve OAuth consents, do you know which device-flow authentications happened last quarter, and have you ever revoked a refresh-token chain in production? Most mid-market teams can't answer any of the three with confidence. That's the gap. Purple Shield's vCISO services is the kind of engagement that documents the answers before they're needed in an actual incident.

What should leadership do?

Three controls block this specific attack class, and none of them require buying new tools if you're already paying for Microsoft 365 E3 or E5. Block the OAuth device-code grant via Conditional Access for users who don't need it. Restrict user consent to verified-publisher OAuth apps. Enable Continuous Access Evaluation so that token revocation actually propagates.

eSentire's TRU lists the controls in order of impact, drawing on Microsoft's own published guidance and analysis of in-the-wild campaigns.

Microsoft Entra Conditional Access has a built-in policy template that blocks device-code authentication flows. Apply it to all users by default. Carve out exceptions only for the developer or device-onboarding scenarios that legitimately need it. This single control removes the attack surface for everyone in scope.

User consent for OAuth applications should require admin approval for third-party apps and limit default consent to verified publishers. With that policy in place, the consent prompt the device-code phish reaches simply can't complete without an admin in the loop.

Continuous Access Evaluation (CAE) closes the window between when an IR team revokes a refresh-token chain and when the revocation takes effect. Without CAE, an attacker may keep using tokens for an hour after they're revoked. With it, revocation propagates in near real time.

Device-compliance policies that restrict access to managed, MDM-enrolled endpoints disrupt the attacker's automated polling client, because attacker-controlled devices aren't enrolled. The same control mid-market firms put in place for ransomware exposure also breaks device-code abuse — a useful overlap in cloud security services for any team running M365.

If you've already had a confirmed device-code phish, the response sequence is: revoke the affected user's refresh tokens with Revoke-AzureADUserAllRefreshToken, audit recent OAuth application consents for that user, review mailbox rules and forwarding configurations, and hunt for the eSentire-published indicators (AppId 29d9ed98, user-agents "node" and "undici", source IPs in AS45102) across non-interactive sign-in logs. That sequence is the kind of work that Purple Shield's incident response services covers when the steps have to happen at 9pm on a Friday.

Frequently asked questions

Does Tycoon2FA device-code phishing work against accounts with FIDO2 security keys?

The attack still walks the user through a consent flow, but a properly scoped Conditional Access policy that requires phishing-resistant authentication (FIDO2, Windows Hello for Business, or certificate-based) for the deviceCode authentication protocol blocks the consent step. Microsoft's published guidance is to combine the device-code block with a phishing-resistant MFA requirement for any flow that remains permitted.

If we disable OAuth device-code authentication, what actually breaks?

For most companies, nothing the end user touches. Device-code flows are used for command-line tools like Azure CLI, PowerShell sign-ins from headless servers, the Microsoft Authentication Library on devices without browsers, and a small number of specialty hardware sign-in flows. Carve those out by group or named user in the Conditional Access policy and block the flow for everyone else by default.

How do I tell if someone in our organization has already approved a Tycoon2FA device-code consent?

Run a Microsoft Sentinel or KQL query against Entra non-interactive sign-in logs for AuthenticationProtocol = deviceCode with ResultType = 0 against AppId 29d9ed98-a469-4536-ade2-f981bc1d605e, then filter for the user-agent strings "node" and "undici" or the axios/1.x fingerprint. Any hit on a normal end-user account warrants immediate forensic review. eSentire publishes the exact KQL hunt query in its May 12, 2026 report.

Does Microsoft Authentication Broker show up as a third-party app in Entra logs?

No, and that's part of why this attack is hard to spot. Microsoft Authentication Broker is a Microsoft first-party application with the AppId 29d9ed98-a469-4536-ade2-f981bc1d605e. It appears in sign-in logs as a normal Microsoft service, so the unverified-publisher alerts that catch most OAuth phishing don't fire on it. Detection has to anchor on the combination of the deviceCode protocol and an anomalous user-agent, not on the application identity alone.

The Tycoon 2FA story makes two things plain. Infrastructure takedowns don't end an operation, and strong MFA on its own can't carry the load. The accounts most exposed to this attack are the ones whose owners assume MFA is enough. If your team is running Microsoft 365 without an explicit Conditional Access block on OAuth device-code flows, that's the conversation worth having this week. Purple Shield helps mid-market and regulated businesses get those Microsoft 365 access controls documented, deployed, and tabletop-tested before they become a question on a coverage form or an OCR letter.