# Detecting Tycoon 2FA AiTM attacks across Entra ID and Google Workspace

Tycoon 2FA PhaaS reverse-proxies Entra ID and Google logins, relaying real MFA to steal post-MFA session tokens and mint device-bound PRTs.

- Payout: Real-world hack
- Severity: high
- Program: Tycoon 2FA
- Analysis by: Samir Bousseaden, Terrance DeJesus
- Disclosed: 2026-05-26
- Write-up quality: 8/10
- Original: https://www.elastic.co/security-labs/threat-command/tycoon-2fa-aitm-detection-engineering
- Library page: https://bugbountylibrary.com/r/blog%3Aelastic-co-security-labs-threat-command-tycoon-2fa-aitm-detection-engineering
- Tags: area:cloud domain:cloud impact:ato impact:data-leak kind:incident platform:threat-intel sev:high tech:azure tech:gcp tech:oauth technique:chained technique:reverse-engineering vuln:account-takeover vuln:auth-bypass vuln:mfa-bypass vuln:secrets-leak

**Target:** Microsoft Entra ID / Microsoft 365 and Google Workspace identity providers (login flows, OAuth token endpoints, Graph API)
**Root cause:** Tycoon 2FA operates as a reverse proxy between the victim and the legitimate identity provider (Entra ID or Google), relaying credentials and the real MFA challenge in real time so the proxy intercepts the post-MFA session token before it reaches the victim's browser.
**Steps:**
1. Victim receives phishing email with link or QR code in a PDF, SVG, HTML, or PPTX attachment.
2. Link routes through multi-layer redirect chain with browser fingerprinting, CAPTCHA, and anti-analysis checks before showing the login page.
3. Victim sees a replica Microsoft/Google login page with dynamically fetched org branding.
4. Credentials are relayed in real time to the real IdP; the real MFA challenge is proxied back and completed normally.
5. IdP issues a session token; the proxy intercepts it before it reaches the victim's browser.
6. Microsoft variant: kit relay obtains a device code from `oauth2/devicecode` with client `29d9ed98-a469-4536-ade2-f981bc1d605e` (Microsoft Authentication Broker), shows it as a verification code, and exchanges it for access/refresh tokens after the victim signs in at `microsoft.com/devicelogin`.
7. Persistence: resource-swap the MAB refresh token at `oauth2/token` for an access token with aud `urn:ms-drs:enterpriseregistration.windows.net`, POST `EnrollmentServer/device` with a PKCS#10 CSR to get a device cert, build an RS256 JWT with the refresh token and cert in the header, POST to `login.microsoftonline.com/common/oauth2/token` as JWT bearer grant to receive the PRT plus JWE session key.
8. Operator console (residential proxy IPs, 10-20 min later) uses the token for Graph recon: `transitiveRoleAssignments`, `memberOf/directoryRole`, `tenantRelationships/getResourceTenants`, `me/mailboxSettings`, `me/contactFolders/contacts?$top=1000`, `subscribedSkus`, `organization`, `appRoleAssignedResources?$top=999`.
9. Google variant: kit relay IPs perform login_success, login_verification (is_second_factor true), token authorize for Chrome client `77185425430.apps.googleusercontent.com` with scope `https://www.google.com/accounts/OAuthLogin`, then DEVICE_REGISTER_UNREGISTER_EVENT within ~1 second.
**How found:** Detection engineering: decompiled kit JavaScript to map anti-analysis layers and cipher, then correlated sign-in, token, and device telemetry across Entra ID and Google Workspace to fingerprint kit relay (cloud-VPS ASN, Node.js UAs, Auth Broker client) versus operator console (residential ASN, single c_sid, browser UAs) and the ~1s Google four-event sequence.
**Exploitation:** Operator monetizes the captured session cookie/token: replays minted tokens post-MFA to access M365 web apps and Graph API for recon (roles, cross-tenant relationships, mailbox settings, contacts, licensing), and on Microsoft escalates to device-PRT persistence that survives revokeSignInSessions, then brokers access tokens for Teams, Outlook, OneDrive, Office, Intune via HMAC-SHA256 signed assertions. Google blast radius is limited to a long-lived Chrome Sync-capable sign-in.
**Escalation:** Refresh token -> DRS device registration -> PRT that survives session revocation, enabling token brokering for any first-party client_id; harvested contacts feed next-wave phishing.
**Insight:** On Entra ID, hunt the cross-tier pivot: two distinct ASNs (cloud-VPS then residential-shaped) authenticating the same user within minutes, and treat device registration with non-native UAs (axios) as PRT persistence — delete devices before revoking sessions or the PRT survives. On Google, the kit footprint lives only in login, token, and device streams; is_suspicious and Alert Center stay silent, so pivot on the Chrome OAuth client 77185425430 from hosting ASNs followed by device registration.

## Proof of concept (copied exactly from the original report)

**Auto-fill email and auto-click Next JS**

```
var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
 emailinputcheck.value = email;
 emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }
```