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

What Happened

Tycoon 2FA is a widespread phishing attack that tricks users into logging into fake Microsoft or Google pages, allowing attackers to steal their access even if they use multi-factor authentication (MFA). Organizations and employees using Microsoft 365 and Google Workspace are targeted. This matters because attackers can maintain access to accounts even after passwords are changed and active sessions are canceled by registering hidden devices. Organizations should use physical security keys for login, block risky login methods, and ensure they remove attacker-registered devices before resetting compromised accounts.

Key Takeaways

• Tycoon 2FA proxies authentication to steal session tokens, bypassing standard multi-factor authentication (MFA).
• Microsoft attacks use a two-tier architecture (Kit Relay and Operator Console) and establish persistence via Device-PRT.
• Google attacks use a single-tier relay with highly compressed authentication and device registration events.
• Standard session revocation is insufficient for Microsoft compromises; defenders must delete registered devices first to break persistence.

Affected Systems

• Microsoft 365
• Entra ID
• Google Workspace
• Windows
• Linux (targeted for evasion)

Attack Chain

The attack begins with a phishing email containing a link or QR code that directs the victim through a redirect chain to an AiTM proxy page. The proxy relays credentials and MFA challenges to the legitimate identity provider in real-time, capturing the resulting session token. In Microsoft environments, the kit automatically registers a rogue device to obtain a Primary Refresh Token (PRT) for persistence, followed by rapid Graph API reconnaissance from a separate operator tier. In Google environments, the kit rapidly authorizes a Chrome OAuth client and registers a device to maintain access.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: Yes
• Other Detection Logic: No
• Platforms: Elastic Security

Elastic provides several ES|QL and EQL detection rules targeting AiTM sign-ins, unusual user agents, Graph API reconnaissance bursts, and rapid device registrations across Entra ID and Google Workspace.

Detection Engineering Assessment

EDR Visibility: Low — The attack primarily occurs in cloud identity providers (Entra ID, Google Workspace) and SaaS applications, bypassing the endpoint entirely. Network Visibility: Low — Traffic flows between the victim and the attacker's proxy, and the proxy and the cloud provider. Corporate network sensors will only see standard HTTPS traffic to the proxy. Detection Difficulty: Moderate — Requires correlating events across different ASNs, monitoring for specific API call bursts, and analyzing user-agent anomalies in cloud logs, which can be noisy or lack context.

Required Log Sources

• Entra ID Sign-in Logs
• Microsoft Graph Activity Logs
• M365 Unified Audit Log
• Google Workspace Reports API

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Consider hunting for interactive sign-ins to cloud identity providers utilizing Node.js HTTP client user agents (such as axios or undici), which may indicate automated proxying.	Entra ID Sign-in Logs	Credential Access	Low
If you have visibility into Microsoft Graph Activity Logs, consider hunting for bursts of API calls hitting multiple distinct reconnaissance categories within a 60-second window.	Microsoft Graph Activity Logs	Discovery	Low
Consider hunting for a single user account successfully authenticating from a cloud hosting provider and a residential proxy network within a short time frame.	Cloud Identity Sign-in Logs	Credential Access	Low
If you have visibility into Google Workspace Reports, consider hunting for highly compressed sequences of login, two-step verification, token authorization, and device registration occurring within seconds of each other.	Google Workspace Reports API	Persistence	Medium

Control Gaps

• Standard session revocation playbooks fail to clear Device-PRT persistence.
• Identity Protection risk engines may not flag rotating cheap VPS IPs.
• Google Alert Center may not alert on multi-ASN sign-ins.

Key Behavioral Indicators

• Node.js user agents (node, axios, undici) in interactive sign-ins
• c_sid shared across multiple IPs in Graph Activity Logs
• Empty C_DeviceId during Graph API recon
• 1-second compression of login, 2SV, token authorize, and device register in Google Workspace
• Socket.IO event 'recieveid'

False Positive Assessment

• Low

Recommendations

Immediate Mitigation

• Verify against your organization's incident response runbook and team escalation paths before acting.
• If a compromise is detected in Entra ID, enumerate and delete attacker-registered devices before revoking user sessions to break the persistence chain.
• Consider implementing automated containment workflows that disable compromised accounts and revoke tokens within minutes of high-fidelity AiTM alerts.

Infrastructure Hardening

• Evaluate whether your Conditional Access policies can require managed, compliant devices for token issuance.
• Consider blocking the device code flow in Conditional Access for all users except explicitly approved headless scenarios.
• If supported by your licensing and environment, evaluate enabling Token Protection (token binding) and Continuous Access Evaluation (CAE).

User Protection

• Consider migrating to phishing-resistant MFA methods such as FIDO2 security keys or passkeys, which are immune to AiTM proxying.

Security Awareness

• Consider updating security awareness training to educate users on the risks of scanning QR codes or clicking links in unsolicited PDFs and SVGs.

MITRE ATT&CK Mapping

• T1566.002 - Phishing: Spearphishing Link
• T1539 - Steal Web Session Cookie
• T1078.004 - Valid Accounts: Cloud Accounts
• T1098.005 - Account Manipulation: Device Registration
• T1550.001 - Use Alternate Authentication Material: Application Access Token
• T1087.004 - Account Discovery: Cloud Account
• T1069.003 - Permission Groups Discovery: Cloud
• T1526 - Cloud Service Discovery

Additional IOCs

• Other:
  • 1234567890123456 - Hardcoded CryptoJS AES-CBC key used in the Google variant's JavaScript payload to encrypt collected credentials.
  • recieveid - Typo in a Socket.IO event name used as a consistent fingerprint in the Tycoon 2FA Google variant kit.