Device Code Phishing: Forensics Against the Perfect MFA Bypass
13.07.2026 oauthdevice-code-phishingidentity-forensikmfa-bypass
A Legitimate Protocol Becomes a Weapon
Since February 2026, an attack technique has been spreading at remarkable speed that no security patch can stop — because it exploits no vulnerability at all, only a legitimate protocol feature. Push Security’s threat research team documented a 37.5x surge in device code phishing pages by April 4, 2026, attributed to the commercial launch of EvilTokens — a Phishing-as-a-Service platform that appeared on Telegram in mid-February 2026. What makes it particularly dangerous: device code phishing exploits a legitimate OAuth 2.0 standard (RFC 8628), meaning no vulnerabilities are patched and no indicators of compromise appear in traditional credential-theft telemetry — no stolen credentials, no intercepted session cookies.
The technique abuses the OAuth Device Authorization Grant, originally built for devices without a keyboard or browser. An attacker requests a device code from Microsoft and lures the victim, via phishing email, into entering that code on the genuine Microsoft sign-in page. The attack does not defeat MFA; it redirects it. Victims complete genuine, MFA-verified authentication on legitimate Microsoft infrastructure, but the resulting tokens are issued to the attacker’s OAuth client rather than the victim’s device. The technique first gained notoriety through the Russia-linked group Storm-2372, which had been active since August 2024, creating lures that resemble messaging app experiences including WhatsApp, Signal, and Microsoft Teams. With EvilTokens, it became a mass-market commodity: a campaign that started in March 2026 hit organizations across construction, non-profits, real estate, manufacturing, financial services, healthcare, legal, and government sectors in five countries. The infrastructure choice was notable too: threat actors abused Railway.com, a developer PaaS platform, as a token-harvesting engine, exploiting its clean IP reputation to bypass Microsoft’s risk scoring.
Why Classic Forensics Goes Blind
For incident responders, this creates an entirely new category of problem. There are no multiple failed logins, no credential changes, no suspicious object creation. The only potential signal is a non-interactive token refresh from an unexpected IP — and only if you’re specifically monitoring for it. Unlike classic adversary-in-the-middle phishing via reverse proxies such as EvilProxy, which intercept sessions through a reverse proxy, capturing cookies after MFA — requiring attacker-controlled infrastructure like domains, certificates, and active servers, all of which leave a forensic trail, device code phishing leaves no attacker infrastructure to investigate at all.
The primary forensic entry point sits in Entra ID sign-in logs: any sign-in where AuthenticationProtocol == “deviceCode” can be marked as suspicious and investigated. Crucially, security operations teams need to monitor non-interactive sign-in logs, not just interactive ones — the attacker’s token refresh activity appears only in non-interactive logs, which many SOCs do not routinely review. Post-compromise behavior follows a recognizable pattern: in some cases, within 10 minutes of the initial breach, threat actors registered new devices under the compromised account to generate a Primary Refresh Token — providing long-term, SSO-capable access that survives individual token revocations. Reconnaissance follows swiftly: using the stolen tokens, attackers queried the Microsoft Graph API to programmatically map internal organizational structures, user roles, and permission assignments.
Remediation: Why a Password Reset Isn’t Enough
The most critical forensic and operational pitfall concerns remediation itself. A user whose password is reset following a phishing incident retains an outstanding attacker-held refresh token that remains valid for its full window unless explicitly revoked — the most common first-line incident response action, credential reset, does not constitute remediation for device-code phishing compromise. What’s actually required is a targeted call to Microsoft’s identity platform: the revokeSignInSessions API endpoint invalidates all active refresh tokens for an account; its absence from standard credential-reset procedures likely represents a structural gap in incident response workflows at many organizations. Even that step isn’t instantly effective: observations from recent campaigns indicate that standard session revocation often only invalidates refresh tokens, leaving existing access tokens active for up to an hour — organizations should temporarily disable the compromised account to ensure immediate containment.
Automation on the attacker side raises the stakes further: EvilTokens integrates large language models — Meta’s Llama 3.1 and 3.3 series and OpenAI’s GPT-4o mini — to automate post-compromise email triage and business email compromise scenario generation, pairing token theft with AI-driven monetization at machine speed. For DFIR teams, the takeaway is unambiguous: playbooks must treat token forensics, non-interactive log review, and explicit token revocation as mandatory steps — otherwise the attacker simply keeps sitting in the mailbox, invisible to any conventional post-incident check.
← Back to overview