How a phishing kit turned your MFA approval into an attacker's login

The Context

Microsoft 365 is the productivity backbone of most mid-size and large organizations. Email, calendar, file storage, video meetings, and Azure cloud infrastructure all run through a single identity layer managed by Microsoft Entra ID. When an attacker gains authenticated access to that identity layer, they can access every connected application, register new devices, create forwarding rules, and in high-privilege accounts, reach every other mailbox in the organization.

EvilTokens is a Phishing-as-a-Service (PhaaS) platform sold as a subscription to criminal affiliates who do not need to build the infrastructure themselves. The operator handles the phishing pages, the token-capture backend, and the post-compromise tooling. This model is why the campaign scaled to over 1,000 active phishing domains and hundreds of daily compromises within weeks of launch.

The Attack, Phase by Phase

Phase 1: Delivery and Evasion

The attack begins in the victim's inbox, but not from a suspicious sender. EvilTokens affiliates send phishing emails from accounts compromised in earlier attacks, meaning messages arrive from real Google Workspace or Microsoft 365 accounts with valid email authentication records. Every filter checking whether a sender is who they claim to be returns a passing grade.

The link routes through a chain of legitimate services—Cisco SafeLinks, Trend Micro, and Mimecast redirect services—borrowing their trusted reputations. The chain then passes through compromised academic or government websites running a bot filter that traps automated scanners while letting real browsers through. Cloudflare Workers and Vercel intermediaries add additional hops before the victim reaches the final page.

The phishing page defeats analysis: the HTML is an empty container, actual content is fetched separately and decrypted inside the browser using AES-GCM. Any tool scanning the page's source sees nothing. The page also disables right-click, blocks developer tool shortcuts, and triggers an infinite loop that freezes the browser if an analyst tries to inspect it.

Phase 2: Dynamic Code Generation and Token Harvest

When the victim lands on the phishing page, a script contacts the attacker's backend, which immediately contacts Microsoft's official device authorization endpoint using the victim's email address. Microsoft returns a fresh device code with a 15-minute lifespan. The code appears on the phishing page, often automatically copied to the victim's clipboard. A button labeled "Continue to Microsoft" opens the real Microsoft device login page at microsoft.com/devicelogin. The victim sees a genuine Microsoft domain, enters the code, completes their normal MFA challenge, and clicks approve. Nothing looks wrong, because it is not wrong—the victim is authenticating against Microsoft's real systems.

What the victim does not know is that the session they just approved belongs to the attacker's backend server. The moment the victim clicks approve, the attacker's server—polling Microsoft's token endpoint every few seconds—receives a live access token and refresh token. The victim's password was never seen by the attacker. The MFA challenge completed correctly. The authentication succeeded for the wrong party.

Phase 3: Persistence and Privilege Escalation

With a refresh token in hand, the attacker's backend registers an attacker-controlled device in Microsoft Entra ID and exchanges the refresh token for a Primary Refresh Token (PRT), enabling silent single sign-on across every Microsoft 365 application with no further MFA prompt. Access tokens are requested separately for each service: Outlook, Microsoft Graph, Azure, Substrate, and SharePoint.

A script called BAV2ROPC runs on an automated schedule twice daily—observed at 11:00 AM and 8:00 PM—refreshing tokens to maintain access for up to 90 days. In high-value cases, device registration happened within 10 minutes of initial compromise. Malicious inbox rules forwarding messages containing keywords like "payroll" or "invoice" were created hours later, timed to avoid triggering immediate alerts.

Phase 4: AI-Augmented BEC Exploitation via MailVault

The MailVault module—presented to affiliates as an "Enterprise Email Management Platform"—is a full Outlook-clone webmail interface that reads and sends email directly using harvested tokens. No password needed.

An AI pipeline built on Meta's LLaMA models ingests up to 5,000 emails from the compromised account. A smaller model (llama-3.1-8b-instant) handles initial triage; a larger model (llama-3.3-70b-versatile) extracts structured financial data including account numbers, routing numbers, wire amounts, and payment deadlines, then generates three ready-to-send BEC email drafts written in the victim's own voice. GPT-4o-mini automatically translates non-English mailboxes. If the compromised account belongs to an Exchange Administrator or Global Administrator, MailVault flags it with a crown icon, signaling access to every mailbox in the organization. The full output—BEC readiness score, financial intelligence summary, and one-click browser cookies—is pushed to the operator's Telegram bot. According to Sekoia, the time from token capture to actionable BEC intelligence dropped from hours to seconds.

What Made This Possible

1. The authentication flow cannot distinguish intent. The OAuth Device Authorization Grant was designed for convenience. When a user enters a device code and approves access, Microsoft's systems correctly authenticate the user but have no mechanism to verify whether the session being authorized belongs to the user's own device or an attacker's server.

2. MFA protects credentials, not sessions. Organizations deployed MFA to prevent attackers from using stolen passwords. EvilTokens does not steal passwords—it causes the victim to authenticate a session the attacker already controls. Every MFA method completes correctly because the victim is authenticating against the real Microsoft domain.

3. Nation-state tradecraft commoditized faster than enterprise defenses adapted. Device code phishing was documented as a Russian state intelligence technique in early 2025. By early 2026, it was a subscription service with AI-generated lures and automated fraud pipelines. That 12-month gap is shorter than most organizations' security policy review cycles.

What Should Have Stopped This

Every effective defense shares one trait: it removes the device code flow from the equation entirely, rather than trying to detect malicious use of a flow that looks identical to legitimate use.

• Block device code flow via Conditional Access. Microsoft Entra ID Conditional Access policies include an Authentication Flows condition that can block the device code grant for all users or limit it to a specific group who genuinely need it. This is the single most direct control, identified by Proofpoint and the Cloud Security Alliance as the strongest available mitigation.
• Restrict token lifetimes and revoke on anomaly. Refresh token lifetimes can be shortened via Entra ID token lifetime policies. Continuous Access Evaluation (CAE) revokes tokens in near-real-time when risk signals appear, limiting the 90-day persistence window.
• Monitor for device registration events. Registering a new device in Entra ID within minutes of an authentication event from an unfamiliar IP is a high-fidelity signal. The synthetic User Agent string observed in EvilTokens traffic (iPhone iOS 18.7 with a non-existent Safari Version/26.3) is a specific detection opportunity Huntress flagged.
• Treat admin role assignments as high-risk targets. MailVault automatically flags Exchange Administrators and Global Administrators for expanded exploitation. Apply stricter Conditional Access policies and require Privileged Identity Management (PIM)—which forces admins to explicitly activate elevated permissions for a limited time window—for all admin-role accounts.

The Takeaway

EvilTokens is not a story about a vulnerability in Microsoft's code. Microsoft's systems worked correctly throughout every attack. The story is about a legitimate protocol feature with a structural blind spot: it authenticates the user but authorizes a session the user did not intend to create.

This connects to the pattern seen in the Stryker Intune wipe: in that attack, legitimate administrative tooling was weaponized after credential compromise. Here, the authentication flow itself is weaponized before any credential is compromised in the traditional sense. The meta-pattern across both: systems fail when they trust a boundary the attacker controls.

The commoditization timeline is the detail that should change how organizations think about defensive cycles. A technique used by state intelligence in 2024 became a subscription service with AI-generated lures and automated fraud pipelines by early 2026. That is not a gap annual security reviews can close.

Pattern to remember: MFA protects against credential theft but provides no protection when the authentication flow itself is the attack surface.

What changed: Detection systems and MFA controls can be rendered irrelevant by attackers who operate inside the legitimate authentication protocol rather than against it.

The Technical Mechanism

EvilTokens exploits the OAuth 2.0 Device Authorization Grant as defined in RFC 8628. In the legitimate flow, a device POSTs to the authorization server's device authorization endpoint with a client_id and scope, receiving a device_code, user_code, and verification_uri. The user navigates to the verification_uri on a separate device, enters the user_code, and authenticates. The originating device polls the token endpoint with the device_code until the grant is approved.

EvilTokens' backend acts as the "originating device." When a victim lands on the phishing page, a JavaScript call hits the attacker's /api/device/start/ endpoint, which proxies a POST to https://login.microsoftonline.com/common/oauth2/v2.0/devicecode with the victim's email as a login_hint. The response includes a device_code (held server-side), a user_code (displayed to the victim), and a verification_uri (microsoft.com/devicelogin). The backend immediately begins polling https://login.microsoftonline.com/common/oauth2/v2.0/token with the device_code and grant_type=urn:ietf:params:oauth:grant-type:device_code. When the victim completes authentication at the real Microsoft URI, the poll returns access_token, refresh_token, and id_token. These are stored server-side and the operator is notified via Telegram webhook.

The phishing page payload is delivered as a base64-encoded AES-GCM ciphertext fetched asynchronously after page load. The decryption key is embedded in the JavaScript bundle. This defeats static URL scanners and most sandbox environments that do not execute JavaScript. Anti-analysis controls include contextmenu event suppression, keydown interception for F12/Ctrl+Shift+I/Ctrl+U, and a setInterval debugger trap that triggers an infinite debugger statement loop when DevTools is open.

Post-compromise, the backend performs a BAV2ROPC (Basic Authentication with V2 Resource Owner Password Credentials) token exchange to obtain tokens scoped to https://graph.microsoft.com, https://outlook.office.com, https://management.azure.com, https://substrate.office.com, and https://sharepoint.com. Device registration via the Microsoft Device Registration Service (DRS) endpoint converts the refresh token to a Primary Refresh Token (PRT), enabling Seamless SSO across all Entra ID-connected applications. The BAV2ROPC script runs on a cron schedule at 11:00 AM and 8:00 PM UTC, confirmed by Huntress log analysis.

The synthetic User Agent string Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1 is a high-fidelity indicator: iOS 18.7 and Safari Version/26.3 do not exist as of the campaign dates, making this string unique to EvilTokens traffic.

CVE and Advisories

No CVE identifier has been assigned to EvilTokens. The attack does not exploit a vulnerability in Microsoft's implementation. It abuses a legitimate protocol feature as designed. The relevant specifications and advisories are:

• RFC 8628: OAuth 2.0 Device Authorization Grant (IETF, August 2019)
• Microsoft Security Blog: Inside an AI-enabled device code phishing campaign (April 6, 2026)
• Huntress: Riding the Rails (March 23, 2026)
• Sekoia TDR: EvilTokens Part 1 (March 30, 2026)
• Sekoia TDR: EvilTokens Part 2 (April 13, 2026)

MITRE ATT&CK Mapping

Indicators of Compromise

Network Indicators

• Railway.com IP ranges used as token-polling infrastructure; Huntress observed approximately 84% of malicious authentication events originating from three Railway.com IP addresses
• Cloudflare Workers subdomains matching patterns tied to Adobe, DocuSign, OneDrive, and SharePoint branding
• Over 1,000 domains hosting EvilTokens pages as of March 23, 2026 (Sekoia telemetry)
• Backend API paths: /api/device/start/ and /api/device/status/:sessionId

Authentication Log Indicators

• Device code grant authentications (grant_type=urn:ietf:params:oauth:grant-type:device_code) from unfamiliar IP addresses
• New device registration events in Entra ID within minutes of an authentication event
• BAV2ROPC token exchange events at approximately 11:00 AM and 8:00 PM UTC
• User Agent string: Mozilla/5.0 (iPhone; CPU iPhone OS 18_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.3 Mobile/15E148 Safari/604.1 (iOS 18.7 and Safari 26.3 do not exist)

Post-Compromise Indicators

• Inbox rules forwarding messages containing "payroll," "invoice," "wire," or similar financial keywords to external addresses or low-visibility folders
• Microsoft Graph API calls scoped to Mail.ReadWrite and Mail.Send from non-interactive sign-in events
• Entra ID audit logs showing device registration by a service principal rather than a user-initiated flow

Detection is complicated by the use of Railway.com infrastructure, whose clean IP reputation caused Microsoft Identity Protection to not flag the logins as risky during the campaign's early phase.

Attribution

No CVE applies. No nation-state attribution has been confirmed for the EvilTokens platform itself. The operator uses the Telegram handle eviltokensadmin and first advertised on the NOIRLEGACY GROUP Telegram channel on February 16, 2026. Sekoia assessed with high confidence that the backend code was likely AI-generated and that the operator has deep familiarity with Microsoft OAuth token management, suggesting the tool was built first for the operator's own BEC operations before being commercialized as a PhaaS platform.

The underlying technique has documented nation-state lineage. Microsoft and Volexity documented device code phishing as a tactic of Russia-aligned cluster Storm-2372 in February 2025. Proofpoint separately tracked Russia-aligned cluster UNK_AcademicFlare using the technique since at least September 2025, and identified financially motivated actor TA2723 adopting it by October 2025. The Cloud Security Alliance assessed that what began as a Russian state intelligence technique in mid-2024 commoditized into a criminal PhaaS offering within approximately 18 months. EvilTokens itself is assessed as a financially motivated criminal operation with no confirmed state-sponsorship link.

Primary Sources