OAuth Device Code Phishing: How Attackers Bypass Microsoft 365 MFA at Scale

Since February 19, 2026, a structured phishing campaign has targeted over 340 Microsoft 365 organizations across the United States, Canada, Australia, New Zealand, and Germany. The campaign was documented and attributed by Huntress researchers, who identified it as being powered by EvilTokens, a phishing-as-a-service platform that debuted on Telegram in early February 2026. The sectors targeted read like a list of organizations that believe they are secure: manufacturing, financial services, healthcare, legal firms, real estate, construction, nonprofits, and government agencies.

The reason the campaign succeeded at scale is that victims were never sent to a fake login page. They authenticated on the real Microsoft login domain, completed legitimate multi-factor authentication, and still handed attackers persistent access to their accounts. The attack exploited a legitimate OAuth authentication mechanism called the Device Authorization Grant flow, defined in RFC 8628. Understanding this protocol is the first step to understanding why standard MFA defenses did not prevent the compromise.

The Device Authorization Grant flow was designed for devices that cannot display a browser or accept keyboard input, such as smart TVs, printers, or IoT devices. The device requests a short-lived user_code and device_code from Microsoft's authorization server. The user is then told to visit https://aka.ms/devicelogin, enter the code, and authenticate normally, including MFA. Once authentication completes, the device polls the authorization server and receives access and refresh tokens tied to the user's session.

The critical security property is that this flow grants tokens to whoever controls the device_code, not necessarily the device the user thinks they are authorizing. If an attacker generates the device_code, sends the user_code to a victim through a phishing email, and the victim completes authentication — including MFA — the attacker receives valid OAuth access tokens scoped to the victim's Microsoft 365 session. The access token grants immediate API access. The refresh token, which has a much longer lifetime, allows the attacker to request new access tokens continuously, even after the victim changes their password. Password reset alone does not invalidate refresh tokens issued through this flow unless the organization has implemented explicit token revocation policies or conditional access controls.

EvilTokens is sold as a service on Telegram. The platform provides customers with phishing email templates, open redirect links to legitimate but vulnerable domains to obscure the phishing URL, and a dashboard that displays captured session tokens. The infrastructure used in the campaign routed victims through Cloudflare Workers redirects before landing on the real aka.ms/devicelogin page. Collected sessions were exfiltrated to Railway, a platform-as-a-service offering used as a command-and-control backend, which gave the campaign operational longevity and made takedowns harder.

From the victim's perspective, the sequence is: receive an email referencing a legitimate document or notification, click a link that passes through a Cloudflare-hosted redirect, arrive on the authentic Microsoft login page at aka.ms/devicelogin, enter the user code from the email, complete normal sign-in including MFA, and unknowingly authorize the attacker's device session. The phishing detection problem this creates is significant. There is no spoofed domain, no credential-harvesting page, and no obvious malicious redirect in the final step. Many email security and endpoint detection controls are not configured to flag device code phishing patterns, because the technology was historically low-volume and not associated with large-scale credential theft.

Microsoft Entra ID (formerly Azure Active Directory) logs device code authentication events under the sign-in log category. The relevant authenticationProtocol field will show deviceCode. Security teams should create detection rules that alert on device code sign-ins from unfamiliar locations, device code sign-ins that are followed by API access from a different IP than the one used for authentication, and unusual volume of device code authentication attempts across the tenant. Microsoft Sentinel and Defender for Identity both support building these detections through UEBA baseline deviations and custom KQL queries.

If a compromise is suspected, the investigation priorities are: audit OAuth application consents granted by affected accounts, check for forwarding rules or inbox rules created shortly after the suspicious sign-in, review Entra ID audit logs for changes to authentication policies or MFA registrations, and enumerate all active refresh tokens issued to the account. Token revocation can be performed with Revoke-MgUserSignInSession in Microsoft Graph PowerShell or through the Entra portal's user session management view. Note that revocation affects all active sessions, so coordinate with the user and their team before executing in production environments.

The most direct mitigation is to block the device authorization grant flow entirely through Entra ID Conditional Access policies. A policy set to block authentication flows where Authentication flow is Device code flow will prevent this attack vector for covered users. The policy can be scoped to specific groups if certain users legitimately require device code auth for approved devices, though this is uncommon in most enterprise environments. Microsoft's own documentation recommends blocking the flow for all users unless there is a specific operational justification.

Beyond blocking the protocol, the incident pattern highlights a broader exposure problem. Manufacturing, financial services, and healthcare organizations in Germany and across DACH make extensive use of Microsoft 365, and many have phishing simulation and security awareness programs that focus exclusively on credential harvesting via fake login pages. Device code phishing bypasses the detection model those programs train employees to use. Realistic phishing simulation that includes device code phishing scenarios gives security teams visibility into whether employees recognize the attack and whether detection infrastructure responds correctly. Combined with continuous monitoring of external-facing authentication endpoints and periodic review of OAuth application permissions across the tenant, this reduces the probability that a successful token theft goes undetected for weeks. The attacker dwell time in this campaign was, in several cases, measured in weeks before discovery — a window long enough to cause material business harm.