Tycoon 2FA AiTM Kit Bypasses MFA on Entra ID and Google Workspace
Analysts at Elastic Security Labs have identified the detailed mechanics behind the Tycoon 2FA AiTM Kit. Their Elastic said in a report shared with Cyber Security News (CSN) that the kit uses two...
Analysts at Elastic Security Labs have identified the detailed mechanics behind the Tycoon 2FA AiTM Kit. Their Elastic said in a report shared with Cyber Security News (CSN) that the kit uses two structural variants, WebSocket-based session relay and device-code-grant abuse, to carry out attacks against different cloud identity platforms. Their findings shed light on just how embedded this threat has become in the modern phishing landscape.
Even a coordinated March 2026 takedown led by Microsoft and Europol, which seized over 300 domains, could not stop the campaign for long.
Operators bounced back within weeks, adapting their infrastructure and blending their methods with OAuth Device Code phishing flows, as documented by eSentire in late April 2026. The kit’s resilience reflects how professional and well-resourced the group behind it really is.
The scale and sophistication of Tycoon 2FA make it one of the most consequential phishing threats active today.

Organizations relying solely on traditional MFA are not protected, as this kit bypasses those controls through session token theft. Understanding how the kit works is the first step toward building defenses that can hold up.
How Tycoon 2FA Bypasses MFA
Tycoon 2FA does not steal credentials the old-fashioned way. Instead, it acts as a reverse proxy, standing between the victim and the real Microsoft or Google login page and relaying everything in real time.
The victim completes their MFA challenge normally, never knowing the kit intercepted the session token the moment it was issued. The attack begins with a phishing email carrying a link or QR code embedded in a PDF, SVG, HTML, or PowerPoint file.
The link routes through a multi-layer redirect chain before landing on a pixel-perfect replica of the target login page, often loaded with the victim’s organization branding pulled directly from the real service.
Once the victim finishes MFA, the kit captures the session cookie and hands it to the attacker, who can then access the account without any further prompts.
Evasion and Post-Compromise Persistence
Tycoon 2FA is built to survive incident response. The kit can register a rogue device in Entra ID, obtaining a primary refresh token that stays valid even after a defender revokes the compromised user’s sessions.
This means the standard “revoke sessions and reset password” playbook is no longer enough to fully contain a Tycoon 2FA compromise.

Beyond persistence, the kit takes extreme steps to avoid analysis. It filters visitors from cloud and hosting IP ranges, blocks developer tools, detects automation frameworks, and removes its own malicious code from the page after execution.
Each victim receives a uniquely encrypted payload seeded with per-session values, making signature-based detection nearly impossible.
To defend against this threat, Elastic recommends deploying phishing-resistant MFA such as FIDO2 security keys or passkeys, since these are the only methods immune to AiTM session theft.
Organizations should also enforce device compliance through Conditional Access, block device code flows for all users except approved scenarios, and enable token protection to bind tokens to specific devices.
Defenders must carefully enumerate and delete registered devices before revoking sessions to fully break the device-PRT persistence chain.
Indicators of Compromise (IoCs):-
The following indicators were documented by Elastic Security Labs in their analysis of Tycoon 2FA campaigns.
| Type | Indicator | Description |
|---|---|---|
| Client App ID | 29d9ed98-a469-4536-ade2-f981bc1d605e | Microsoft Authentication Broker client ID used by the kit relay for device-code-grant abuse and PRT minting |
| OAuth Client ID | 77185425430.apps.googleusercontent.com | Google Chrome OAuth client targeted in every Google Workspace relay session |
| OAuth Scope | https://www.google.com/accounts/OAuthLogin | Chrome’s internal bootstrap sign-in scope used by the kit to initiate Google relay sessions |
| User-Agent | node, axios/1.15.2, node-fetch/1.0, undici | Node.js HTTP client user agents used by the Tier 1 kit relay against Microsoft Entra ID |
| API Domain | api.ipapi.is | IP geolocation/ASN lookup service called by the kit to filter out researcher and cloud provider traffic |
| ASN | Alibaba Cloud (and similar cheap-VPS ASNs) | Tier 1 kit relay infrastructure used for automated token acquisition and renewal |
| ASN | Clouvider, Host Telecom | Cheap hosting ASNs used by kit relay IPs in Google Workspace campaigns |
| Socket.IO Event | recieveid | Consistent kit fingerprint (note deliberate typo) used in the WebSocket C2 relay channel |
| Crypto Key | 1234567890123456 | Hardcoded AES-CBC key found in kit JavaScript for encrypting collected credentials |
| Library | CryptoJS 4.2.0 | JavaScript library bundled in the Google-targeting kit variant for credential encryption |
| Socket.IO Version | Socket.IO 4.6.0 | WebSocket C2 library version used in the Google-targeting kit variant |
| Entra Error Code | 53003 | Error returned when device code flow is blocked via Conditional Access, confirming successful policy enforcement |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.