TL;DR

The perimeter is dead. Malware is optional. In 2026, attackers have industrialized identity theft to a degree that makes traditional MFA—TOTP, SMS, and push notifications—a checkbox rather than a control. The EvilTokens Phishing-as-a-Service (PhaaS) campaign, tracked since February 2026, has compromised 340+ Microsoft 365 organizations while running 10–15 distinct sub-campaigns per day by abusing the OAuth Device Code Authentication flow. It bypasses MFA completely, grabs 90-day rolling refresh tokens, and enables persistent SSO access that survives password resets. Alongside AiTM (Adversary-in-the-Middle) toolkits, pass-the-cookie infostealers, and OAuth consent abuse, this represents the full maturation of the credential-free intrusion era. This playbook tells you how to build defenses that actually hold.

---

Background: The Collapse of the Password-Centric Model

For the better part of two decades, enterprise security was structured around a simple mental model: keep bad code off the network and verify who's at the front door with something they know (a password) and something they have (a second factor). The endpoint was where the fight happened. Firewalls were the boundary.

That model assumed attackers needed to run malicious code to accomplish anything meaningful. That assumption is now thoroughly obsolete.

A significant share of confirmed breaches in 2026 involve no malware at all. The initial access technique in a growing majority of targeted intrusions is identity compromise — stolen session tokens, device code fraud, or manipulated OAuth grants. When an attacker authenticates with a stolen, valid session cookie, they are invisible to EDR (no malicious process), transparent to the firewall (normal authenticated traffic), and silent in the SIEM (authentication appears legitimate). The perimeter is no longer the network edge; it is the authentication event itself.

Three forces accelerated this shift:

1. The infostealer explosion. Redline, Lumma, Vidar, and their successors have turned session cookie theft into a commodity service. Stealer logs containing browser-extracted OAuth tokens are sold on Telegram for as little as $10 per "log." Every stolen session cookie represents a fully authenticated cloud session — including any MFA that was already completed.

2. The AiTM toolkit market. Evilginx, Modlishka, and their derivatives made Adversary-in-the-Middle phishing drag-and-drop. An attacker stands up a reverse proxy between the victim and the real identity provider, lets the user complete a legitimate MFA challenge, and intercepts the resulting session token in real time. No exploit required.

3. OAuth Device Code abuse industrialization. What was once a niche academic technique — abusing the OAuth 2.0 Device Authorization Grant (RFC 8628) to hijack tokens — has entered mainstream criminal adoption in 2026. The EvilTokens PhaaS kit represents the first large-scale criminal commoditization of the technique.

---

Technical Analysis

The EvilTokens Campaign: Device Code Phishing at Industrial Scale

The OAuth Device Code flow was designed for input-constrained devices — think smart TVs, CLI tools, IoT dashboards — that cannot easily render a browser-based login. The flow works like this: the device contacts Microsoft's /oauth2/v2.0/devicecode endpoint, receives a user code and a verification URL, and polls the token endpoint until the user enters the code at microsoft.com/devicelogin and authenticates.

The critical design flaw exploited by device code phishing: when the user enters the code and authenticates, the token is issued to whoever generated the code — not to the device in front of them. An attacker who generates a fresh code and tricks the user into entering it at Microsoft's legitimate login page receives the resulting access and refresh tokens, while the user sees a completely normal, unmodified Microsoft login experience and approves a real MFA push notification.

EvilTokens (a PhaaS kit sold on Telegram since mid-February 2026) industrialized this in several important ways:

• Live code generation with no timeout gap. Prior device code phishing tools struggled with the 15-minute expiration window; EvilTokens fires a fresh code generation request the moment the victim clicks the phishing link, delivering a code that is still valid when the victim enters it.
• AI-personalized lures. Generative AI crafts hyper-specific phishing emails — RFP language matching a target's industry, invoice formats matching their vendor relationships, calendar invite styles matching their organization's templates. Microsoft observed lures covering DocuSign, SharePoint, Adobe Acrobat Sign, OneDrive, voicemail alerts, and email quarantine notices.
• Redirect chain evasion. Links bounce through Cloudflare Workers, Vercel functions, AWS Lambda, and compromised legitimate sites before landing on the phishing page, defeating URL scanners and sandboxes.
• Token persistence. Once access tokens (60–90 minute validity) are captured, EvilTokens uses them to perform device registration, acquiring Primary Refresh Tokens (PRTs) — essentially full browser-level SSO credentials with rolling 90-day validity that survive password resets.
• Automated BEC targeting. Built-in mailbox analysis identifies high-value financial threads and automatically positions for Business Email Compromise interception.

Scale: Since March 15, 2026, Microsoft observed 10–15 distinct EvilTokens sub-campaigns launching every 24 hours. Push Security tracked a 37.5x increase in device code phishing pages detected by late April 2026. Over 340 M365 organizations have confirmed compromise.

AiTM: The Session Cookie Assembly Line

Running parallel to device code abuse, AiTM phishing via Evilginx and related toolkits continues to mature. The technique is architecturally simple but devastating: a reverse proxy sits between victim and identity provider, forwarding all traffic bidirectionally. The user authenticates — including completing MFA — against the real IdP, but the proxy captures the resulting session cookie at the moment of issuance.

The stolen session cookie grants access to any resource the user was authenticated to, with no additional factor required. Token theft has fundamentally superseded credential theft as the primary objective: a stolen password can be reset; a stolen session cookie only needs to be used before it expires, and expiry windows on enterprise SaaS tokens commonly range from hours to weeks.

OAuth Consent Phishing

A quieter but persistent threat: attackers register malicious OAuth applications with broad permission scopes (Mail.Read, Files.ReadWrite.All, offline_access) and trick users into authorizing them via consent screens that mimic legitimate enterprise apps. Once granted, the OAuth app maintains persistent API access that survives password resets, MFA changes, and account recovery flows, because the permission grant was made by the legitimate user to what appeared to be a legitimate application.

Microsoft introduced application consent governance features in Entra ID, but many organizations have not fully enforced admin consent requirements for third-party apps, leaving the vector open.

MFA Fatigue and Hybrid Social Engineering

Push notification bombing remains a viable and heavily used technique. Attackers obtain credentials (phishing, infostealer logs, credential stuffing), trigger repeated MFA push notifications, and wait for the victim to approve one out of frustration. Enhanced variants pair push fatigue with direct voice calls impersonating IT helpdesk, dramatically increasing approval rates. The technique requires no technical sophistication and has a documented success rate high enough to remain in every threat actor's standard playbook — from script kiddies to state-sponsored APT groups.

Cross-Plane Lateral Movement

Once an attacker holds a valid cloud identity token, the pivot chain typically looks like this:

1. Mailbox access — read historical email to understand org structure, vendor relationships, and pending financial transactions

2. Lateral phishing — send phishing from the compromised account to trusted internal recipients (internal email passes every spam filter)

3. SaaS enumeration — use the OAuth token to enumerate connected SaaS apps (Salesforce, ServiceNow, GitHub, AWS) that accepted the same IdP token

4. Device registration — register an attacker-controlled device to obtain a PRT and achieve durable SSO that persists independently of the compromised session

5. Privilege escalation — target overprivileged service accounts or Conditional Access policy gaps to escalate from a user context to an admin context

---

Indicators of Compromise (IOCs)

These are behavioral and telemetry-based IOCs; network-layer IOCs for redirect chains rotate too quickly to be useful as static block lists.

| Type | Indicator | Significance |

|---|---|---|

| Behavioral | Device code auth flow from a new device + no prior device registration | Likely device code phishing |

| Behavioral | OAuth token issued to microsoft.com/devicelogin but user's Entra registered devices unchanged | PRT acquisition attempt |

| Behavioral | Access token used from IP geographically distant from user's known locations within minutes of issuance | Session cookie replay |

| Behavioral | Inbox rules created immediately after auth event (hide/delete/redirect) | BEC post-compromise persistence |

| Behavioral | OAuth app grant with offline_access + Mail.Read + Files.ReadWrite scopes from first-time app | Consent phishing |

| Log Pattern | Multiple Sign-In events from new IP followed by Add device action | PRT-seeking device registration |

| Log Pattern | AITM proxy redirect chain (Cloudflare Worker domain → Vercel domain → final page) in redirect history | AiTM infrastructure |

| Log Pattern | Repeated MFA push denials followed by approval within 5-minute window | MFA fatigue attack |

| Threat Actor Infra | EvilTokens operator Telegram: @EvilTokensSales (as of April 2026) | PhaaS operator channel |

---

The Lyrie Take

The 2026 identity threat landscape represents a structural defeat for the "something you have" paradigm when "what you have" is a TOTP code or a push notification. Every method that terminates the authentication ceremony at the browser level and issues a transferable session token is vulnerable to AiTM. Every method that requires user action with a numeric code is vulnerable to device code phishing. The attack surface is not a bug in any specific product — it is an architectural property of how web authentication was designed.

This matters for Lyrie's threat detection posture in two ways:

First, behavioral anomaly detection in the identity plane is no longer optional infrastructure — it is the primary detection surface. If you are not correlating authentication events with device registration changes, token issuance locality, subsequent API call patterns, and mailbox rule creation in near-real-time, you are operating blind against the most active attack class in enterprise cloud environments.

Second, phishing-resistant MFA is not aspirational hardening — it is the minimum viable defense. NIS2, DORA, and PCI DSS 4.0 now mandate phishing-resistant MFA as a compliance requirement, not a best practice. FIDO2 hardware security keys and device-bound passkeys are the only methods that are architecturally immune to AiTM and device code phishing because the authentication ceremony is cryptographically bound to the legitimate origin domain — a proxy cannot intercept what it cannot re-sign.

---

Defender Playbook

Tier 1 — Immediate Actions (0–72 hours)

1. Block Device Code Authentication Flow for high-risk users.

In Entra ID (and Okta via authentication policy), disable the Device Authorization Grant flow for your highest-risk user segments immediately: executives, finance staff, IT admins, and anyone with access to sensitive data repositories. In Entra, this is accomplished via a Conditional Access policy blocking the Device Code grant type:

CA Policy: Block device code flow
Users: All privileged roles + Finance + Executives
Conditions: Any platform, any location
Grant: Block

For organizations that require the device code flow for legitimate IoT/CLI use cases, scope it tightly to named, known IP ranges or device compliance policies.

2. Enable Number Matching + Additional Context for all push MFA.

If you remain on Microsoft Authenticator push or similar, enable number matching (force user to type the 2-digit number shown in the app) and geographic context display (show the country/city of the sign-in request). This alone eliminates the bulk of MFA fatigue attacks by breaking the "just tap Approve to stop the spam" behavior pattern.

3. Audit and restrict OAuth third-party app consent.

In Entra admin: set Users can consent to apps accessing company data on their behalf to Disabled. Require admin consent for all third-party OAuth apps. Audit existing grants for apps with offline_access + Mail.Read/Files.ReadWrite— revoke any you cannot account for.

4. Enable Entra ID's Sign-In Risk and User Risk policies.

Entra Identity Protection provides ML-based risk scoring for authentication events, including detection of AiTM phishing infrastructure (based on reverse proxy header characteristics). Set your User Risk policy to require password reset for High risk and Require MFA for Medium+. Set Sign-In Risk policy to Block at High.

Tier 2 — Structural Hardening (1–4 weeks)

5. Deploy phishing-resistant MFA on a triage schedule.

Priority order for rollout:

• Tier 0 (Immediate): All accounts with Global Admin, Security Admin, Exchange Admin, Privileged Role Admin roles → FIDO2 hardware keys (YubiKey 5 series or equivalent)
• Tier 1 (Week 1–2): Finance, legal, M&A, HR leadership → device-bound passkeys via Windows Hello for Business or FIDO2 keys
• Tier 2 (Week 3–4): General workforce → synced passkeys (Apple/Google platform authenticators) — still phishing-resistant even if not hardware-bound

In Entra Conditional Access, create an Authentication Strength policy requiring Phishing-Resistant MFA for Tier 0/1 roles. This blocks TOTP, SMS, and push as acceptable second factors for those accounts.

6. Implement Continuous Access Evaluation (CAE).

CAE allows Entra ID to revoke access tokens in near-real-time when a risk signal is received (anomalous IP, suspicious API call patterns, impossible travel), rather than waiting for token expiry. This dramatically shortens the attacker's usable window after token theft. Enable CAE for Microsoft 365 workloads in Entra → Enterprise Applications → CAE settings.

7. Deploy an ITDR platform with cross-plane correlation.

Point-in-time identity logging does not catch lateral movement. You need a platform that correlates:

• Identity events (Entra/Okta sign-ins, role changes, device registration)
• Endpoint telemetry (which process is requesting tokens, file access post-auth)
• SaaS API activity (what the token is actually doing after issuance)
• Email/collaboration signals (inbox rule creation, forwarding rule changes)

Without cross-plane correlation, an attacker moving from Entra to SharePoint to a connected AWS workload with a stolen PRT is invisible to each individual tool. CrowdStrike Falcon ITP, Microsoft Defender for Identity, and Huntress EDR+ITDR Correlations are leading options at different price points.

8. Audit service accounts for over-privilege and shared use.

Service accounts are the second-most-common lateral movement vector after user token theft. For every non-human identity in your environment:

• Remove interactive login rights where not required
• Enforce least-privilege: audit last-used scopes vs. granted scopes
• Disable shared service accounts — each automated process should have its own managed identity
• Rotate secrets on a fixed schedule (at minimum quarterly)
• Flag any service account authenticating from a new host or making calls outside its baseline scope

Tier 3 — Mature Detection (4–12 weeks)

9. Build a Device Code Authentication anomaly detection rule.

In Sentinel, Splunk, or your SIEM, implement this detection logic:

SignInLogs
| where AuthenticationProtocol == "deviceCode"
| where DeviceDetail.deviceId == "" or DeviceDetail.isCompliant == false
| where ResultType == 0  // Successful sign-in
| summarize count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)

Alert on successful device code auth where the completing device is not a registered, compliant device.

10. Implement Token Anomaly Honeypots (Cloud Mines).

Following the Cloud Mines technique documented in April 2026: deploy dummy Azure resources (storage containers, key vaults, function apps) with names that look attractive to an attacker reading exfiltrated mailbox content but that legitimate users never access. Any OAuth token that touches a Cloud Mine is, by definition, stolen — legitimate users have no business there. This delivers near-zero-false-positive detection for stolen token replay.

11. Establish impossible-travel and token location correlation baseline.

For every active OAuth token, the issuing location and subsequent use location should be geographically plausible within the token's age. A token issued in Dubai and used in Eastern Europe 4 minutes later represents a physical impossibility. These events should auto-trigger: token revocation, user risk elevation, and SOC notification simultaneously, not sequentially.

12. Require admin consent re-authorization annually.

OAuth grants rot. An app authorized two years ago may now have broader scopes than the current version requires, or the vendor may have been acquired. Annual re-consent review cycles with automatic revocation of grants from apps not re-authorized within the review window.

---

Sources

1. Coralogix / Snowbit – "Evil Token: AI-Enabled Device Code Phishing Campaign" (April 6, 2026): https://coralogix.com/blog/evil-token-ai-enabled-device-code-phishing-campaign/

2. Push Security – "Analyzing the rise in device code phishing attacks in 2026" (April 2026): https://pushsecurity.com/blog/device-code-phishing

3. The Register – "Hundreds compromised daily in Microsoft device code phishes" (May 1, 2026): https://www.theregister.com/2026/04/07/microsoft_device_code_phishing/

4. Andrea Fortuna – "When identity becomes the perimeter: breaking in without malware" (April 26, 2026): https://andreafortuna.org/2026/04/26/identity-new-perimeter/

5. Mine2.io – "Device Code Phishing 340+ Microsoft 365 Orgs: Cloud Mines Stop OAuth Token Attacks" (April 2026): https://mine2.io/blog/2026-04-05-device-code-phishing-oauth-token-cloud-mines/

6. MojoAuth – "8 Reasons 87% of Enterprises Are Deploying Passkeys in 2026" (April 2026): https://mojoauth.com/blog/8-reasons-enterprises-deploying-passkeys

7. Microsoft Learn – "Passkeys (FIDO2) authentication method in Microsoft Entra ID" (2026): https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2

8. Citeables – "Identity threat detection tools for AD/Azure AD/Okta: which ones catch lateral movement and risky service accounts?" (April 2026): https://www.citeables.com/article/identity-threat-detection-tools-for-ad-azure-ad-okta-which-ones-catch

9. Huntress – "A 2026 Guide to Continuous User Baselining in ITDR Tools": https://www.huntress.com/cybersecurity-insights/itdr-tools-and-continuous-user-baselining

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk