Tycoon 2FA after the March 2026 takedown: two-tier AiTM operator architecture and the OAuth device-code variant

Background. Tycoon 2FA is among the most prolific adversary-in-the-middle (AiTM) phishing-as-a-service kits, built to intercept the post-MFA session cookie of Microsoft 365 and Google Workspace accounts in real time. In March 2026 a coordinated takedown led by Microsoft and Europol — with Cloudflare, SpyCloud and eSentire — seized over 300 domains, but operators adapted within weeks, and by late April 2026 campaigns combined Tycoon tradecraft with OAuth Device Code phishing flows (Elastic Security Labs, 2026-05-26). This brief last covered the post-takedown device-code pivot on 2026-05-18; Elastic's 2026-05-26 analysis is a detailed detection-engineering treatment of the kit's current operator architecture and is the basis for the technique mapping below.

Two operating variants. The kit now runs in two structurally distinct modes. The classic WebSocket AiTM reverse-proxy intercepts the authenticated session cookie as the victim completes MFA against a real Microsoft/Google login (T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie, replayed via T1550.004 Web Session Cookie). The newer device-code-grant abuse variant is Microsoft-only: it leverages the Microsoft Authentication Broker client ID 29d9ed98-a469-4536-ade2-f981bc1d605e to obtain and replay a Primary Refresh Token (PRT), escalating a single phished code into durable token material (T1528 Steal Application Access Token). The token-type progression Elastic observed in Entra sign-in logs is the tell: incomingTokenType:none → refreshToken → primaryRefreshToken.

Two-tier operator architecture and the cross-tier signal. The operation splits across two tiers with different network fingerprints. Tier 1 (Kit Relay) performs token acquisition from cloud-VPS egress IPs using node / axios / undici / node-fetch user agents. Tier 2 (Operator Console) performs post-compromise enumeration from residential-shaped ISP egress with a fixed browser UA. Because single-ASN rules only catch one tier, Elastic's highest-confidence indicator is the cross-tier pivot: two distinct ASNs (one cloud-VPS, one residential-shaped) authenticating as the same user principal within minutes and sharing the same c_sid correlation value. Within roughly 30–60 seconds of a successful token replay, Tier 2 runs a Microsoft Graph reconnaissance burst — transitiveRoleAssignments, tenantRelationships/getResourceTenants (cross-tenant lateral-movement preparation), contact harvesting and subscribedSkus — typically 20–30+ calls spanning four or more recon categories (T1087.004 Cloud Account Discovery, T1526 Cloud Service Discovery).

Detection concepts. Elastic shipped multiple Entra ID and Google Workspace detections, including an ES|QL "Microsoft Graph Multi-Category Reconnaissance Burst" rule that fires on the four-plus-category Graph enumeration inside a short window. Concept-level hunts a SOC can build without the rules: in Entra sign-in logs, alert on node/axios/undici/node-fetch user agents paired with the Microsoft Authentication Broker client ID, and on device-registration events using non-standard UAs (not Dsreg / DeviceRegistrationClient / Dalvik); for Google Workspace, alert on Admin SDK login_success events landing within ~1 second across multiple relay IPs, and on an OAuth token.authorize for the Chrome client 77185425430.apps.googleusercontent.com followed by a DEVICE_REGISTER_UNREGISTER_EVENT within 0.6–1.2 seconds. Critical detection gap: Entra ID Identity Protection may not flag the kit infrastructure because of rapid IP rotation, and Elastic observed the risk engine flagging anomalousToken but subsequently marking the victim aiConfirmedSafe — a false negative that defenders cannot treat Identity Protection alone as sufficient coverage for. Elastic's automated response (disable account, delete device principals, revoke sessions, open a case) runs in under ten seconds, inside the observed 10–20-minute kit-to-operator handoff window — the operational point being that response must beat the handoff, not merely detect after it.

Hardening. Enable Microsoft Token Protection via Conditional Access so a stolen session/refresh token is bound to the originating device; require compliant or managed devices for access to sensitive resources; and use Authentication Methods policies to block the OAuth Device Code flow for the majority of users who never legitimately need it — the device-code variant collapses if the grant is disabled for the targeted population. None of these depend on a patch; they are policy changes that remove the attack path the kit monetises.