A phishing-as-a-service operation dubbed “EvilTokens” is using Microsoft’s legitimate OAuth device code flow to hijack accounts, underscoring how attackers can bypass multi-factor authentication (MFA) by harvesting consent tokens instead of passwords. According to researchers cited by The Hacker News, the service went live in February 2026 and, within weeks, was linked to compromises at more than 340 Microsoft 365 organizations across several countries.
In the EvilTokens playbook, victims receive a message urging them to enter a short code at the legitimate microsoft.com/devicelogin URL and complete their usual MFA challenge. That interaction takes place entirely on Microsoft’s own infrastructure, and the user walks away believing they have verified a security check or fixed an account issue. Behind the scenes, the code they entered is bound to an attacker-controlled application. By completing the flow, the user authorizes that app and effectively hands over OAuth tokens that can be exchanged for access and refresh tokens, granting API-level access to email, files, and other Microsoft 365 resources without ever exposing credentials. This pattern mirrors “device code phishing” and consent-based attacks described by defenders at Hoxhunt and Valence Security, where MFA is rendered moot once a trusted app has been approved.
OAuth consent phishing is not a new technique, but campaigns like EvilTokens highlight how it has matured into a turnkey service model. Rather than spoofing login pages, attackers increasingly lean on legitimate identity provider flows to obtain powerful, long-lived tokens that can be reused via APIs and automation. Microsoft has detailed how abuse of OAuth redirection and authorization flows can fuel both phishing and malware delivery campaigns against Microsoft 365 tenants in its own research on OAuth redirection abuse. Security firms including Obsidian Security warn that once a malicious or compromised app is granted scopes such as mailbox read/write or file access, attackers can persist quietly with API calls that rarely trigger user-facing security prompts.
Attackers are also innovating beyond device codes. Researchers at Push Security recently documented a browser-native technique they call “ConsentFix,” where users are manipulated into copying a localhost URL containing an OAuth authorization code and pasting it into a phishing site that targets Microsoft accounts via the Azure CLI application. In this flow, described in detail by Push Security and Mitiga, the attacker redeems that code at Microsoft’s token endpoint to obtain access and refresh tokens, again without ever stealing a password or defeating MFA directly. Both ConsentFix and EvilTokens show how the attack surface has shifted from passwords to browser sessions and token flows, enabling adversaries to sidestep even phishing-resistant methods like passkeys by targeting the layer above them.
These operations are difficult to spot because they abuse “by-the-book” protocol behavior and trusted domains. From a logging perspective, the sign-in often appears as a normal, interactive or device-code login to a first-party app such as Azure CLI or Microsoft Graph, followed by non-interactive API activity that may originate from cloud infrastructure controlled by the attacker. Mitiga notes that the OAuth authorization codes used in such attacks are short-lived but redeemed for refresh tokens that can remain valid for extended periods, allowing persistent access unless explicitly revoked. Obsidian and other SaaS security providers stress that traditional perimeter tools and credential-centric detections will miss this activity if organizations lack visibility into OAuth grants, app consents, and anomalous API usage across Microsoft 365 and Azure.
Defenders cannot “patch” these campaigns away, since they hinge on legitimate OAuth behavior rather than a discrete vulnerability. Instead, Microsoft and independent researchers recommend tightening control over app consent and token use. That includes limiting user ability to consent to new OAuth applications and requiring admin approval for high-impact scopes, as outlined in guidance on OAuth phishing from Hoxhunt and Valence; enforcing Conditional Access policies in Entra ID that restrict use of sensitive first-party apps like Azure CLI to compliant devices or managed locations, as suggested by Mitiga; and enabling emerging protections such as Entra ID’s token protection features where supported. On the human side, security teams are urging users to treat unsolicited requests to enter device codes or share localhost URLs as highly suspicious, to verify the application name and requested permissions on any consent screen, and to report unexpected login flows—even when they occur entirely on trusted Microsoft URLs.
