Tycoon 2FA OAuth Evolution: Bypassing Microsoft 365 Protections

Tycoon 2FA OAuth: The Evolution of Device-Code Phishing in Microsoft 365

In the rapidly shifting landscape of cybercrime, the Tycoon 2FA OAuth variant represents a significant leap in technical sophistication and strategic adaptation. Historically known as a potent Adversary-in-the-Middle (AiTM) phishing kit, Tycoon 2FA has successfully navigated an international law enforcement takedown in early 2026 to emerge with a new, more dangerous capability: the exploitation of the OAuth Device Authorization Grant flow. This latest evolution, meticulously documented by security firms like eSentire, marks a shift away from traditional credential harvesting toward the silent hijacking of account tokens, effectively bypassing even the most robust multi-factor authentication (MFA) protocols.

The Resilience of Tycoon 2FA: From Takedown to Transformation

Tycoon 2FA first rose to prominence as a high-tier Phishing-as-a-Service (PhaaS) platform, enabling threat actors to conduct large-scale AiTM attacks. By acting as a proxy between the victim and the legitimate service provider, the kit was able to capture both passwords and session cookies in real-time. This allowed attackers to bypass standard MFA prompts, as the victim was technically completing the authentication on behalf of the attacker’s proxy.

In March 2026, a global coalition led by Microsoft and Europol announced a major disruption of the Tycoon 2FA infrastructure. However, the resilience of the PhaaS model was proven within weeks. The operators rebuilt their backend on new hosting providers—specifically migrating many operations to Alibaba Cloud (AS45102)—and updated their code to leverage OAuth device-code exploits. This pivot suggests that the developers had already anticipated the transition to token-based attacks, which are inherently more difficult to detect than traditional credential theft because they occur within the “trusted” channels of Microsoft’s own authentication infrastructure.

Technical Mechanics: Weaponizing the OAuth Device-Code Flow

The core of the new Tycoon 2FA variant lies in the abuse of RFC 8628, the OAuth 2.0 Device Authorization Grant. Originally designed for “input-constrained” devices—such as smart TVs, printers, or CLI tools—this protocol allows a device to request access to an account without requiring the user to type a password on that specific device. Instead, the device generates a short, human-readable “user code” and instructs the user to visit a verification URL (e.g., microsoft.com/devicelogin) on a separate browser-capable device to approve the request.

Tycoon 2FA weaponizes this process through a clever inversion of trust. The attacker’s server (acting as the constrained device) initiates a login request to Microsoft. Microsoft generates a code, which the Tycoon kit then displays to the victim via a phishing page. When the victim enters this code on the legitimate Microsoft login page and completes their standard MFA, they are not logging themselves into a new app; they are authorizing the attacker’s device to receive an OAuth access token and a refresh token. Because the victim interacts only with microsoft.com, they see no red flags, and the organization’s security logs see a “successful” authentication from a legitimate user.

Anatomy of the Attack: The Four-Layer Stealth Chain

The delivery mechanism for the Tycoon 2FA OAuth exploit is a masterpiece of evasion, utilizing a four-layer in-browser delivery chain designed to exhaust automated scanners and security researchers.

• Layer 1: The Encrypted Payload: The attack often begins with a lure email, frequently utilizing legitimate click-tracking services like Trustifi to bypass email filters. Upon clicking, the browser downloads a heavily obfuscated JavaScript payload that uses AES-GCM encryption to hide the subsequent stages of the attack.
• Layer 2: Anti-Analysis and Evasion: This layer executes a battery of environment checks. The kit blocks over 230 known security vendors, sandbox environments, and headless browsers. It performs ASN-based filtering, redirecting traffic from known security firm IPs (such as those from Google, Microsoft, or Cloudflare) to benign sites like Wikipedia or legitimate corporate homepages. This ensures that the malicious content is only served to “clean” residential or corporate IP addresses.
• Layer 3: The “HumanCheck” Gate: To further deter automated analysis, Tycoon 2FA presents a fake CAPTCHA or “HumanCheck” page. Behind the scenes, the kit queries a “Check Domain”—a dynamic gatekeeper that validates the victim’s session before allowing them to proceed to the final payload.
• Layer 4: The Device-Code Phish: Finally, the victim is presented with a convincing Microsoft-themed page. Unlike older versions, this page never asks for a password. Instead, it displays the attacker-generated device code and provides a direct link to the real Microsoft device login page. The kit provides “copy” buttons and step-by-step instructions, guiding the user to finalize their own compromise.

Technical Indicators and Fingerprints

Despite its stealth, the eSentire Threat Response Unit (TRU) identified persistent fingerprints in the Tycoon 2FA source code. These include a specific CryptoJS AES-CBC implementation that consistently uses the hardcoded key and IV: 1234567890123456. While the data being encrypted has shifted from credentials to operator session metadata, the underlying logic remains a reliable signature of the Tycoon codebase. Additionally, the polling activity from the attacker’s backend often carries distinct Node.js user-agent strings such as node or undici, which stand out in corporate authentication logs.

The Impact of Impersonating Microsoft Authentication Broker

A critical component of this exploit is the specific OAuth application identity used by the attackers. Tycoon 2FA typically impersonates the Microsoft Authentication Broker (AppId 29d9ed98-a469-4536-ade2-f981bc1d605e). This is a first-party, “trusted” Microsoft application used to broker tokens across the entire Microsoft 365 ecosystem.

By obtaining a token for the Authentication Broker, the attacker gains broad, persistent access to:

1. Outlook/Exchange Online: Allowing for email exfiltration and Business Email Compromise (BEC) attacks.
2. SharePoint and OneDrive: Granting access to sensitive corporate documents and internal data.
3. Microsoft Graph API: Enabling the attacker to read user profiles, directory information, and even modify account settings or forwarding rules.

Because the Authentication Broker is a legitimate part of the Windows and M365 ecosystem, its activity rarely triggers “unverified publisher” warnings or the usual scrutiny applied to third-party OAuth apps. To the Entra ID (formerly Azure AD) telemetry, the sign-in looks like a standard user registering a new device or office application.

Strategic Defense: Mitigating OAuth Exploitation

Defeating the Tycoon 2FA OAuth threat requires a shift from password-centric security to identity and token governance. Organizations can no longer rely on the presence of MFA as a guarantee of security, as the “Device Code” flow is designed to leverage the user’s successful MFA for the attacker’s benefit.

1. Disabling the Device Code Flow

The most effective defense is to disable the OAuth Device Authorization Grant flow entirely for users who do not require it. Most standard corporate users have no legitimate need to use the /devicelogin endpoint. In the Microsoft Entra admin center, administrators can create a Conditional Access policy that targets “Authentication Flows” and explicitly blocks “Device Code Flow.”

2. Implementing Managed Device Requirements

Organizations should enforce policies that require devices to be compliant or hybrid joined to access sensitive resources. By requiring a managed device, even if an attacker steals an OAuth token via a device-code phish, they will be unable to use that token from their own unmanaged (Alibaba Cloud or Node.js) environment. The token becomes useless outside of the organization’s verified hardware ecosystem.

3. Monitoring Entra ID Sign-in Logs

Security Operations Centers (SOCs) should monitor for specific anomalies in sign-in logs, including:

• Sign-ins using the Device Code flow from unusual geographic locations.
• The use of the Microsoft Authentication Broker app ID associated with non-standard User-Agents (e.g., node-fetch, undici, or python-requests).
• A sudden surge in successful “interactive” sign-ins followed immediately by “non-interactive” API calls to the Graph API from a new IP address.

4. Advanced Token Protection

Enabling Continuous Access Evaluation (CAE) allows Microsoft 365 to revoke tokens in near real-time if a risk is detected, such as a change in the user’s location or a password reset. Furthermore, organizations with Entra ID P2 licenses should explore Token Protection (Token Binding), which cryptographically binds the token to the specific device that initiated the request, preventing it from being replayed by an attacker.

Conclusion: The Future of Identity-Based Attacks

The emergence of Tycoon 2FA OAuth exploits signifies the end of the era where MFA was a “silver bullet” for account security. By weaponizing legitimate authentication protocols and leveraging advanced evasion techniques, threat actors have found a way to turn the user’s own security actions against them. As Phishing-as-a-Service kits continue to commoditize these advanced techniques, organizations must move toward a Zero Trust identity model that prioritizes device compliance, token governance, and vigilant monitoring of OAuth consents. The battle for the inbox has moved beyond the password; it is now a battle for the token.