Tycoon 2FA: device code campaign bypasses Microsoft MFA

Excerpt — On May 12, 2026, eSentire documented a Tycoon 2FA campaign abusing Microsoft’s device code to steal OAuth tokens without any password prompt. Here is why phishing-resistant MFA (FIDO2/WebAuthn) satisfies GDPR Article 32.

Key facts

On May 12, 2026, the TRU team at eSentire detailed an active campaign reusing the Tycoon 2FA phishing kit to hijack Microsoft 365’s OAuth Device Authorization Grant flow. The path is simple and effective: an invoice or voicemail email points to a legitimate tracking URL (e.g., events.trustifi[.]com), then to a disposable Cloudflare Workers subdomain (e.g., cookies.28gholland[.]workers[.]dev). After multiple browser anti-analysis layers, the page displays a device code and prompts the victim to enter it on microsoft.com/devicelogin, i.e., on a genuine Microsoft form. The victim then consents, unknowingly, to the “Microsoft Authentication Broker” (AppId 29d9ed98‑a469‑4536‑ade2‑f981bc1d605e), handing the attacker working OAuth tokens for Exchange Online, Graph, and OneDrive, while appearing as normal activity in Entra.

Public IOCs enable hunting and blocking:

• Domains/URLs: events.trustifi[.]com/api/o/v1/click/<id> (abused legit tracker), cookies.28gholland[.]workers[.]dev (redirector), shivacrio[.]com/bytecore~tx1j8 (a “Check Domain” gate for anti-analysis) — eSentire provides a URLScan regex to detect them.
• AppIds: 29d9ed98‑a469‑4536‑ade2‑f981bc1d605e (Microsoft Authentication Broker), 4765445b‑32c6‑49b0‑83e6‑1d93765276ca (OfficeHome, credential‑relay variant).
• Operator User‑Agents: “node”, “undici” seen in automation backends (authentication status polling).

This tradecraft confirms the decline of OTP/push against modern attacks (AiTM, consent phishing, device code). In February 2026, BleepingComputer had already flagged “device code vishing” abusing legitimate authentication flows to bypass classic MFA.

Applicable legal framework

GDPR Article 32 requires “appropriate technical and organizational measures,” considering risks, including — by example — confidentiality, integrity, availability and measures like encryption and resilience to incidents. For authentication, one must demonstrate that mechanisms are state of the art against actual threats (phishing, session theft, rogue consents, token theft). Consolidated text: EUR‑Lex — 2016/679, Art. 32. For further context on GDPR processing security, see our GDPR page.

For entities under NIS 2 in Luxembourg, incident detection and handling are overseen by ILR (notification via SERIMA), but this article focuses on GDPR processing security. Phishing‑resistant MFA is a demonstrable cornerstone for Article 32 compliance.

The technical solution to deploy

Phishing‑resistant MFA (FIDO2/WebAuthn + Conditional Access policies)

• Principle: FIDO2/WebAuthn authenticators generate device‑bound private keys and bind them to the domain (origin binding). No reusable secret (OTP, SMS/push code) is typed on a potentially booby‑trapped site: nothing to intercept.
• In practice (Microsoft Entra, Okta, etc.):
  • Block or restrict the Device Code flow via Conditional Access when unjustified (or require a managed context: compliant device, trusted network).
  • Enforce FIDO2/passkeys for admins and high‑risk users; remove SMS/voice/email OTP.
  • Enable anti‑token theft protections (device‑bound signatures, proof‑of‑possession tokens when available), and govern OAuth consents (verified publisher, app policies).
  • Monitor Entra sign‑in logs: AuthenticationProtocol=deviceCode with unexpected ResultType=0, unusual/suspicious AppIds, and “node/undici” UAs on non‑interactive connections.
• Standards:
  • ISO/IEC 27001:2022 Annex A — A.8.5 Secure authentication, A.5.15 Access control.
  • NIST SP 800‑63B — phishing‑resistant authenticators.
  • CIS Controls v8 — 6.3/6.5 (broad MFA, admin/remote).

How Luxgap delivers this

• Our ISO 27001 governance: authentication policy design (risk mapping, FIDO2 targets by population, entitlement matrix), Article 32 evidence (periodic reviews, KPIs reducing OTP surface).
• Our 24/7 managed SOC: integrated telemetry (Entra/Okta, EDR/XDR), abnormal device code signals, proactive hunting for Tycoon 2FA IOCs and consent‑phishing patterns, and runbooks for token revocation and OAuth response.
• Our e‑learning platform: targeted modules — “never type a code shown anywhere except on your authenticator device,” vishing/abnormal consent simulations, certificates and engagement metrics to demonstrate privacy by design.

Real‑world case in Luxembourg or the EU

An accounting services firm under NIS 2 handling HR and finance data flagged novel deviceCode authentications via Entra. Within 6 weeks we: (1) enforced Conditional Access to block device code off unmanaged devices; (2) migrated admins and sensitive users to FIDO2 passkeys, removing SMS/push; (3) implemented a token revocation process and weekly OAuth consent reviews; (4) added SIEM detections for AppId=29d9ed98-...605e and “node/undici” UAs. Result: multiple later attempts were blocked at the flow control layer, with no operational impact.

Practical first steps

1. Disable weak factors (SMS/voice/email OTP) for privileged and sensitive users; run a FIDO2/passkeys pilot group.
2. In Entra/Okta, restrict or block the Device Code flow and enforce a managed context (compliant device, trusted network) where the flow is truly needed.
3. Deploy SIEM rules: detections on AuthenticationProtocol=deviceCode, AppId 29d9ed98‑...‑605e, “node/undici” UAs, and hunting for suspicious *.workers[.]dev domains and Check Domains such as .../[a-zA-Z0-9]{1,20}[~!@$][a-zA-Z0-9]{1,20}.
4. Review OAuth consents: require verified publishers, restrict sensitive scopes, and set a playbook for token revocation/rotation.
5. Awareness in 15 minutes: “if a page shows you a code and sends you to a legitimate site to enter it, be wary”; alert the SOC immediately.

Official sources

• Tycoon 2FA “device code” campaign (IOCs, TTPs) — eSentire TRU, May 12, 2026.
• “Device code vishing” trend against Entra — BleepingComputer, Feb 19, 2026.
• Legal framework — GDPR, Article 32 (EUR‑Lex).
• Luxembourg NIS 2 — notification via SERIMA (ILR) and NIS 2 (ILR) for scope and national organization.

Need help? Reach out via our contact page.