Elastic Details Detection Engineering for Tycoon 2FA AiTM Attacks

· Original article ↗

Summary

Elastic describes Tycoon 2FA’s AiTM and OAuth device-code tactics, detection signals across Entra ID and Google Workspace, and defenses including device removal, phishing-resistant MFA, and automated containment.

Key points

  • Tycoon 2FA proxies legitimate sign-ins to capture authenticated session tokens; the article says operators resumed activity after a March 2026 infrastructure takedown.
  • On Entra ID, the kit can register a device and obtain a device-bound PRT that may survive user session revocation; the article recommends deleting registered devices before revoking sessions.
  • Entra ID detection signals include Node.js-style user agents, cloud-hosted relay IPs followed by residential-shaped operator access, and rapid Microsoft Graph reconnaissance.
  • Google Workspace signals include multiple hosting-ASN sign-ins to one user within minutes, rapid OAuth authorization followed by device registration, and a roughly one-second login sequence.
  • The article describes detection rules for both platforms and a proof-of-concept workflow that disables an account, removes registered devices, and revokes sessions in under 10 seconds.
  • Recommended defenses include phishing-resistant MFA, compliant-device requirements, blocking device-code flows where appropriate, token protection, and Continuous Access Evaluation.

Article Details

Defense Focus
Detect AiTM phishing, token relay, post-compromise reconnaissance, and device-registration persistence across cloud identity environments; rapidly contain compromised accounts before operators begin reconnaissance.
Detection Methods
  • Correlate the same user authenticating from a cloud-VPS ASN and a residential-shaped ASN within minutes; pivot on source IP and appId, and use ASN rather than geolocation for enrichment.
  • Detect Auth Broker or OfficeHome sign-ins to Graph or Exchange with Node.js-style user agents such as node, axios, or undici; separately alert on successful interactive device-code sign-ins.
  • Hunt for bursts of 20–30 or more Graph API requests across distinct endpoints in 30–60 seconds; alert when at least four reconnaissance categories occur within 60 seconds, including failed requests.
  • For Google Workspace, detect login, second-factor, OAuth authorization, and device-registration events compressed into roughly one second; correlate Chrome OAuth authorization from a hosting ASN with device registration within 30 seconds.
  • Detect successful sign-ins from an atypical ASN, impossible travel exceeding 800 km/h with at least 500 km separation, unusual user agents during device registration, and bursts of three or more device registrations for one user within a minute.
Data Sources
  • Entra ID sign-in logs, including source IP, appId, user agent, and sign-in type.
  • Microsoft Graph Activity Logs, correlated with sign-in logs using source IP and appId.
  • Microsoft 365 Unified Audit Log (o365.audit) for tenants using it alongside or instead of Entra ID sign-in logs.
  • Entra ID device-registration events and registeredDevices/ownedDevices records.
  • Google Workspace Reports API login, token, and device event streams.
  • Entra ID Protection risk events and user-risk status.
Rule Types
  • ES|QL query-based aggregation rules, including Graph reconnaissance-category and geospatial rules.
  • EQL sequence rules for OAuth authorization followed by device registration.
  • New-term rules for first-time sign-ins from a user's source ASN.
  • Sign-in correlation rules for user, ASN, source IP, appId, and user-agent patterns.
Defensive Actions
  • Use phishing-resistant MFA, such as FIDO2 security keys or passkeys.
  • Require managed, compliant devices through Conditional Access; enable token protection and Continuous Access Evaluation where applicable.
  • Block device-code flows except for explicitly approved kiosk or headless scenarios.
  • For tenants without custom Conditional Access policies, consider Security Defaults; the article notes that enabling it disables custom Conditional Access policies.
  • For suspected device-PRT persistence, disable the account, enumerate and delete registered devices, and then revoke sign-in sessions; session revocation alone may leave the device-bound PRT valid.
  • Automate containment and case creation. The described workflow disables the account, deletes registered and owned devices, revokes sessions, and opens a case; it completed in under 10 seconds in the reported proof of concept.
  • After containment, review passwords, authentication methods, and OAuth grants.

MITRE ATT&CK

Threat Actors

Vendors

Products

Related Articles