TL;DR
Multi-factor authentication is no longer a complete defense against account takeover. Two mature attack tracks—Adversary-in-the-Middle (AiTM) session hijacking and OAuth 2.0 device code phishing—intercept or divert the authentication flow rather than breaking it, meaning your users can complete MFA and still hand their session tokens to an attacker. The week of May 4–11, 2026 alone delivered a Microsoft Security Blog post about a 35,000-user campaign, a Sekoia teardown of the EvilTokens PhaaS kit, a SpyCloud analysis of device code mechanics, and an Okta threat intelligence brief on the scattered remnants of Tycoon 2FA. The signal is unanimous: the identity layer is actively under artillery fire and most enterprise MFA configurations are not sufficient to stop it.
Background
The Tycoon 2FA Disruption and Its Aftermath
Through early 2026, Tycoon 2FA was the dominant PhaaS (Phishing-as-a-Service) kit for AiTM attacks against Microsoft 365. It provided turnkey infrastructure for proxying the Microsoft sign-in page in real time, intercepting credentials and session cookies mid-flight while showing the victim a pixel-perfect authentication experience. At its peak, researchers estimated it powered phishing campaigns targeting millions of mailboxes per week.
In March 2026, a coordinated law enforcement and private-sector operation took down approximately 330 domains associated with Tycoon 2FA's infrastructure, including its distributed control panel and hosted phishing pages. The disruption was real—but its effect was to scatter, not eliminate. Okta Threat Intelligence tracked three immediate successor tracks:
- Tycoon 2FA v2 – operators shifted hosting providers and domain registration patterns within weeks, rebuilding with operational-security improvements learned from the takedown.
- Kratos (formerly Sneaky 2FA) – a rebranded kit with similar AiTM capability, observed in the same April 2026 Microsoft campaign.
- EvilTokens – a different-genus threat that emerged in mid-February 2026 and went wide in March, specifically targeting the OAuth 2.0 Device Authorization Grant flow rather than traditional credential proxy methods.
The Microsoft Defender Research campaign analysis from April 14–16, 2026 confirmed that all three kits were operating simultaneously under a shared social-engineering wrapper—code-of-conduct lure emails—with the infrastructure at the tail end linked to different PhaaS providers. This is the PhaaS ecosystem maturing: commodity front-end lures, modular back-end attack infrastructure, and rapid self-repair after takedowns.
Scale of the April 2026 Campaign
| Metric | Value |
|---|---|
| Users targeted | 35,000+ |
| Organizations hit | 13,000+ |
| Countries | 26 |
| US-concentration | 92% of targets |
| Top verticals | Healthcare (19%), Financial Services (18%), Professional Services (11%), Technology (11%) |
| Campaign window | April 14–16, 2026 (2 days, multiple waves) |
Technical Analysis
Track 1: Classic AiTM Session Proxy
The foundational technique is well-documented but still devastatingly effective. The attacker stands up a reverse proxy (using frameworks such as Evilginx2, Muraena, or custom kit infrastructure) between the victim and the legitimate identity provider—Microsoft Entra, Okta, Google Workspace.
Kill chain:
1. Victim receives a phishing email (in the April 2026 campaign: "Internal Case Log – Code of Conduct Review" with a PDF attachment).
2. PDF contains a "Review Case Materials" link pointing to an attacker-controlled domain.
3. Victim passes a Cloudflare CAPTCHA (bot filtering/sandbox evasion stage).
4. Victim is forwarded to an intermediate staging page that reinforces the lure and prompts authentication.
5. Second CAPTCHA. Then "Verification completed successfully."
6. Victim is redirected to the real Microsoft sign-in page, but through the AiTM proxy.
7. Victim enters credentials and completes MFA (TOTP, push notification, SMS OTP).
8. The proxy relays the exchange to Microsoft, receives the authenticated session cookie, and stores it.
9. Victim is shown a benign completion screen. Attacker now has a live, authenticated session token that bypasses all future MFA prompts for the session lifetime.
Why legacy MFA fails here: The victim genuinely completed MFA. The attack didn't break the authentication—it intercepted the result of authentication. SMS OTP, TOTP codes, push approvals, and even some hardware keys (used in a standard TOTP mode) are all interceptible because the authenticating factor is presented to the proxy and relayed to the real IdP. The attacker doesn't need the credential at rest; they capture the post-authentication session.
Track 2: OAuth 2.0 Device Code Phishing (EvilTokens)
This attack surface is fundamentally different and subtler. It abuses a legitimate OAuth flow designed for input-constrained devices (smart TVs, printers, IoT) that has no equivalent defensive control in most enterprise deployments.
The OAuth Device Authorization Grant flow (how it's supposed to work):
1. A device with no keyboard (e.g., a smart TV) requests a user_code from the auth server (POST /oauth2/v2.0/devicecode).
2. The server returns a short alphanumeric code and a verification URL.
3. The user takes that code to a separate device (phone, laptop), navigates to https://microsoft.com/devicelogin, enters the code, and authenticates normally including MFA.
4. The auth server issues access_token + refresh_token back to the original device.
How the attacker exploits it:
1. Attacker, acting as the "device," sends the POST /devicecode request to Microsoft to get a fresh user_code and device_code.
2. Attacker crafts a phishing page displaying the user_code alongside a lure (e.g., "Enter this code to access your secure compliance PDF").
3. Victim navigates to microsoft.com/devicelogin, enters the code (which Microsoft's own UI confirms is a legitimate flow), and authenticates on their own device—completing MFA normally.
4. The auth server, seeing successful authentication, issues tokens to whichever device registered the device_code—the attacker's. The victim's real device never gets anything.
The MFA bypass nuance: If the victim already has an active M365 browser session (default state for most workers during business hours), entering the device code does not even trigger an MFA prompt—the existing session satisfies trust. If no active session exists, the victim does complete MFA, but the tokens are still delivered to the attacker's device.
EvilTokens PhaaS capabilities (Sekoia analysis, March 2026):
- Turnkey Microsoft device code phishing pages, delivered via Telegram bot
- AI-powered automation for downstream BEC attacks post-compromise
- Built-in webmail interface for email harvesting from compromised accounts
- Access weaponization module (automated discovery and exfil of M365 data)
- Announced roadmap: Gmail and Okta phishing pages
- Pricing model: subscription via cybercrime forums, rapidly adopted since February 2026
Why Refresh Tokens Are the Real Danger
Both attack tracks harvest not just access tokens (short-lived) but refresh tokens (long-lived). In Microsoft 365, a refresh token can remain valid for days or weeks, enabling continuous re-authentication without triggering new MFA prompts. Even after a user changes their password, pre-existing refresh tokens may remain valid until explicitly revoked. The attacker can establish persistent access through token re-use—a problem that password-change-as-incident-response completely misses.
Indicators of Compromise (IOCs)
Infrastructure patterns from the April 2026 campaign:
| IOC Type | Example Values |
|---|---|
| Attacker-controlled domains (CAPTCHA stage) | acceptable-use-policy-calendly[.]de, compliance-protectionoutlook[.]de |
| Domain pattern | Terms: compliance, conduct, policy, review + legitimate SaaS brand names |
| PDF filename patterns | Awareness Case Log File – [Day Date Month Year].pdf, Disciplinary Action – Employee Device Handling Case.pdf |
| Email display name patterns | "Internal Regulatory COC", "Workforce Communications", "Team Conduct Report" |
| Subject line patterns | "Internal case log issued under conduct policy", "Reminder: employer opened a non-compliance case log" |
| Fake legitimacy marker | Paubox HIPAA-compliance banner inserted in email body |
| Sending infrastructure | Legitimate cloud-hosted email delivery service (likely compromised/rented VMs) |
EvilTokens infrastructure signatures (Sekoia, March 2026):
- Telegram bot-hosted C2 channels
- Phishing pages ending with
deviceloginredirect flow - Nine-digit device code presented alongside PDF lure
- POST requests to
/oauth2/v2.0/devicecodeoriginating from attacker-controlled servers
Behavioral hunting queries (Entra ID / Microsoft Sentinel):
// Suspicious device code sign-in from unfamiliar IP
SigninLogs
| where AuthenticationMethodsUsed contains "deviceCode"
| where IPAddress !in (known_corporate_IPs)
| where TimeGenerated > ago(1d)
// Token issued to different device than expected
AuditLogs
| where OperationName == "Add device"
| where Result == "success"
| where InitiatedBy.user.userPrincipalName != "expected_device_enrollment_accounts"
// Refresh token re-use from new geography
SigninLogs
| where TokenIssuerType == "RefreshToken"
| where Location.countryOrRegion != UserCountryLyrie Take
The combination of Tycoon 2FA's post-disruption scatter and EvilTokens' rapid market penetration signals a structural shift in enterprise identity attacks. Three things make this moment particularly dangerous:
1. Legacy MFA monoculture. Most enterprises rolled out TOTP or SMS MFA 3–5 years ago and considered the identity problem solved. Neither protects against AiTM proxy interception. The deployment cost of upgrading to phishing-resistant MFA (FIDO2/passkeys) has kept organizations on insecure schemes well past the threat's evolution.
2. The device code flow is invisible to most SOCs. Conditional access policies, SIEM alerting, and endpoint agents were not designed with devicelogin flows in mind. A user completing device code authentication leaves almost no anomalous signal on the victim's device—the token is issued to the attacker's infrastructure with no local footprint.
3. PhaaS makes this accessible to low-skill actors. EvilTokens runs on Telegram, charges a subscription, includes AI-assisted post-compromise automation, and is expanding to Okta and Gmail. The skill floor for a successful AiTM campaign is now near-zero. This stops being a nation-state problem and becomes a commodity ransomware precursor risk.
Lyrie.ai's identity-threat detection models monitor for token anomalies (geographic binding mismatches, device fingerprint drift, refresh token re-use outside established patterns) that sit orthogonal to standard MFA completion signals—precisely because MFA completion is no longer a trust signal in these attack chains.
Defender Playbook: 14 Controls to Harden Against AiTM and Device Code Attacks
Immediate Actions (This Week)
1. Enable Conditional Access with phishing-resistant MFA
Move high-value accounts (executives, IT admins, finance, HR) from TOTP/SMS to FIDO2 hardware keys or device-bound passkeys. These bind authentication to a specific origin using asymmetric cryptography—AiTM proxies cannot relay a valid response because the cryptographic challenge is site-specific. Tycoon 2FA and EvilTokens cannot bypass FIDO2.
2. Block the OAuth Device Authorization Grant for non-device use cases
In Microsoft Entra: go to Enterprise Applications > User Settings > Device Code Flow. For organizations that don't deploy input-constrained IoT/TV devices, disable the Device Code flow tenant-wide or restrict it to a named application allowlist. This kills the EvilTokens attack vector entirely.
3. Enable Continuous Access Evaluation (CAE)
CAE forces Microsoft 365 to re-evaluate session validity in near-real-time when risky conditions are detected (location change, IP change, policy change). It significantly reduces the window during which a stolen session token remains usable.
4. Deploy token binding / sign-in frequency policies
Set conditional access sign-in frequency to 1 hour for sensitive workloads. Couple with persistent browser session controls: disable "Keep me signed in" and require re-authentication after each session close. This limits the benefit of stolen refresh tokens.
Short-Term (Next 30 Days)
5. Alert on Device Code flow authentication from unexpected IPs
Create a Sentinel/Defender XDR rule: AuthenticationMethodsUsed contains "deviceCode" AND IPAddress NOT IN known_ranges. Alert + conditional block for investigation.
6. Alert on suspicious refresh token re-use
Build a baseline of normal geographic and device patterns per user. Alert when a refresh token is exercised from a country/device fingerprint that differs from the user's last 30 days of sign-ins.
7. Implement token protection in Conditional Access (Preview)
Microsoft Entra's Token Protection (preview as of mid-2026) cryptographically binds a token to the device that was authenticated. A token stolen by an AiTM proxy and used on the attacker's device will fail validation because the device certificate doesn't match. Enroll pilot users now while the feature matures.
8. Configure SmartScreen and network protection enterprise-wide
Microsoft's SmartScreen and network protection (via Defender) provide host-based URL filtering that blocks known AiTM proxy infrastructure. The April 2026 Microsoft report specifically recommends this as a defense layer. Ensure Group Policy enforces SmartScreen in Edge/Chrome for all domain-joined devices.
9. Set PDF and attachment scanning for known AiTM patterns
AiTM campaigns increasingly use PDF attachments as the initial delivery mechanism. Configure Defender for Office 365 Safe Attachments in Dynamic Delivery mode and add rules scanning PDF embedded links against threat intelligence feeds.
Medium-Term (60–90 Days)
10. Audit and reduce OAuth application consent permissions
EvilTokens and similar kits frequently request offline_access scope to obtain refresh tokens. Run a consent audit: identify all applications with offline_access, Mail.Read, Files.ReadWrite.All delegated permissions granted by users. Revoke non-business-justified grants. Enable admin consent workflow to prevent future user-driven OAuth app consent.
11. Deploy Identity Threat Detection and Response (ITDR)
Traditional SIEM-based identity monitoring fails against AiTM because the authentication event looks legitimate. ITDR solutions (Entra ID Protection, CrowdStrike Falcon Identity, Lyrie Identity Signal) analyze behavioral baselines, token issuance patterns, and lateral movement indicators post-authentication to catch compromised sessions that bypassed MFA cleanly.
12. Implement Zero Trust session re-verification at resource access
Configure your reverse proxy / app gateway to re-verify session validity at critical resource access points (SharePoint exports, admin panels, finance systems) using step-up authentication. Don't trust a session token that's 4 hours old without re-challenge.
13. Train users specifically on device code lures
Device code phishing is genuinely confusing—users see the legitimate Microsoft devicelogin page and a warning that says "don't enter codes you don't trust," but social engineering pressures them to proceed. Dedicated training scenarios: "when would you ever legitimately receive a device code in an email?" Answer: never.
14. Conduct purple team tabletop exercises on token-theft scenarios
Test your SIEM/SOC response to: (a) stolen session token used from a foreign IP, (b) refresh token re-use after password reset, (c) device code completed by user from phishing email. These scenarios expose detection gaps in most enterprise monitoring stacks before real attackers do.
Sources
1. Microsoft Security Blog – "Breaking the code: Multi-stage 'code of conduct' phishing campaign leads to AiTM token compromise" (May 4, 2026): https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
2. SpyCloud Labs – "Device Code Phishing: The AiTM Attack That Bypasses MFA" (May 8, 2026): https://spycloud.com/blog/device-code-phishing-the-new-aitm-attack-bypassing-mfa/
3. Sekoia TDR – "New widespread EvilTokens kit: device code phishing as-a-service – Part 1" (March 25, 2026): https://blog.sekoia.io/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1/
4. Okta Threat Intelligence – "Tycoon 2FA phishing actors scatter, branch into new attacks" (May 5, 2026): https://www.okta.com/blog/threat-intelligence/tycoon_2fa_phishing_actors_scatter/
5. Barracuda Networks – "Threat Spotlight: Tycoon 2FA didn't die — it's scattered everywhere" (April 16, 2026): https://blog.barracuda.com/2026/04/16/threat-spotlight-tycoon-2fa-scattered-everywhere/
6. The Hacker News – "Microsoft Details Phishing Campaign Targeting 35,000 Users Across 26 Countries" (May 5, 2026): https://thehackernews.com/2026/05/microsoft-details-phishing-campaign.html
7. Mimecast Community – "OAuth Device Code Phishing Campaigns Surge with EvilTokens Toolkit" (May 7, 2026): https://community.mimecast.com/discussion/8955/oauth-device-code-phishing-campaigns-surge-with-eviltokens-toolkit
Lyrie.ai Cyber Research Division — Senior Analyst Desk
Lyrie Verdict
Lyrie's autonomous defense layer flags this class of exposure the moment it surfaces — no signature update required.