Tycoon 2FA Operators Turn to OAuth Device-Code Phishing to Steal Microsoft 365 Tokens

· Original article ↗

Summary

eSentire analyzes a Tycoon 2FA campaign that uses a multi-layer phishing chain to trick victims into authorizing OAuth device codes, giving operators Microsoft 365 tokens despite successful MFA.

Key points

  • The campaign repurposes Tycoon 2FA’s existing phishing kit for OAuth device-code phishing; it does not capture passwords or proxy Microsoft’s sign-in page.
  • A Trustifi click-tracking link redirects victims through a Cloudflare Workers subdomain to a fake Microsoft voicemail lure and device-login instructions.
  • Victims enter an attacker-issued code at Microsoft’s legitimate device-login page and approve a Microsoft Authentication Broker consent prompt; the operator then receives tokens.
  • The kit retains recognizable fingerprints, including a Check Domain URL pattern, AES-CBC encryption with a hardcoded key and IV, anti-debug checks, and Base64/XOR wrapping.
  • eSentire observed operator activity from Alibaba Cloud ASN AS45102, with “node” and “undici” user agents; refresh-token reuse continued after revocation.
  • The SOC isolated affected accounts, revoked sessions and refresh tokens, and audited application consents. Recommended defenses include restricting device-code authentication and user consent, and hunting for anomalous Entra sign-ins.

Article Details

Attack Vectors
  • A forwarded vendor-invoice email used a Trustifi click-tracking link that redirected through a disposable Cloudflare Workers subdomain to deliver the phishing content.
  • A four-layer in-browser chain used encrypted and obfuscated JavaScript, anti-analysis checks, ASN-based filtering, and a decoy branch to control what visitors saw.
  • A Microsoft 365 voicemail-themed lure directed victims to enter an operator-issued device code at Microsoft's legitimate device-login page and consent to token issuance for Microsoft Authentication Broker.
  • The kit polled its operator backend for device-code flow status and forwarded victim session coordination data, including browser, IP, and country information.
  • After consent, operators used issued tokens to access Exchange Online and Microsoft Graph and continued attempting refresh-token reuse after revocation.
Defensive Notes
  • Block OAuth Device Code authentication for end users with Conditional Access, allowing it only for explicitly approved scenarios.
  • Restrict OAuth application consent and require administrator approval for third-party applications.
  • Enable Continuous Access Evaluation and revoke refresh-token chains promptly after suspected compromise.
  • Apply device-compliance policies to limit access to managed and compliant devices.
  • Hunt for successful device-code sign-ins involving Microsoft Authentication Broker and the user agents "node", "undici", or "axios/*", including repeated error 50173 events after token revocation.
  • Review mailbox rules, OAuth application consents, and forwarding configurations after a suspected successful phish.

Indicators of compromise

TypeIndicatorContext
DOMAINfijothi[.]comOperator backend domain receiving encrypted session-coordination requests and returning device-code flow status.
HOSTNAMEcookies[.]28gholland[.]workers[.]devDisposable Cloudflare Workers subdomain used as the delivery point for the malicious payload.
IPV447[.]252[.]11[.]99Operator-side IP observed during sustained refresh-token reuse.
IPV447[.]90[.]180[.]205Operator-side IP observed during device-code token acquisition and post-consent activity.

MITRE ATT&CK

Vendors

Products

Tools

Related Articles