EvilTokens PhaaS: Bypassing MFA via OAuth Device Code Flow

EvilTokens: The Rise of MFA-Bypassing Phishing

A new phishing-as-a-service (PhaaS) platform named EvilTokens has emerged, signaling a sophisticated shift in how attackers target enterprise environments. According to The Hacker News, the platform became active in February 2026 and managed to compromise more than 340 Microsoft 365 organizations across five countries within its first five weeks of operation.

Unlike traditional Phishing campaigns that attempt to harvest usernames and passwords, EvilTokens utilizes the OAuth 2.0 Device Code Flow to hijack legitimate user sessions. This TTP is particularly dangerous because it effectively bypasses multi-factor authentication (MFA). Since the victim authenticates directly through a legitimate Microsoft domain, traditional security filters and even eagle-eyed users may fail to recognize the malicious intent until the session is already compromised.

Microsoft 365 Device Code Flow exploitation via EvilTokens

The technical foundation of this attack relies on the Device Code Flow, an OAuth 2.0 protocol designed for devices that lack a browser or have limited input capabilities, such as smart TVs or IoT devices. In the EvilTokens workflow, the attacker initiates an authentication request for a specific resource, which generates a unique user code. This code is then sent to the victim via a deceptive message.

The victim is directed to enter this short code at the official microsoft.com/devicelogin portal. Once the code is entered, the victim proceeds through their standard organizational login process, including any required MFA challenges. Because the victim is interacting with a legitimate Microsoft-owned URL, the authentication is successful. However, once completed, the access token is issued to the attacker’s client rather than the victim’s device. This allows the attacker to establish a persistent session and gain unauthorized access to the victim’s email, files, and administrative portals.

This method of Microsoft 365 Device Code Flow exploitation is highly effective because it avoids the need for a proxy-based C2 infrastructure that traditional AiTM (Adversary-in-the-Middle) phishing kits require. By leveraging Microsoft’s own infrastructure to handle the authentication, the attacker stays under the radar of many reputation-based security tools.

Impact Analysis and Campaign Scope

The rapid adoption of EvilTokens suggests a significant demand for automated tools capable of subverting modern identity protections. While the specific names of the five affected countries were not disclosed, the volume of 340 organizations in a five-week window indicates a high-velocity operation. Organizations in these regions are seeing tokens harvested in real-time, often leading to subsequent data exfiltration or business email compromise (BEC) incidents.

For the SOC, the primary challenge lies in the nature of the logs. The authentication events appear as legitimate logins from the user’s perspective, and the token issuance is a standard protocol response. Without granular monitoring of device registration and the context of the login request, these sessions can remain active for long durations, providing attackers with ample time for reconnaissance and data theft.

Detection and Mitigation Strategies

Security teams must understand how to detect EvilTokens OAuth phishing within their identity logs to prevent widespread compromise. Detecting these attacks requires monitoring for sign-in logs where the “Authentication Method” is recorded as “Device Code Flow,” particularly when the request originates from unexpected IP addresses or geographic locations.

To harden defenses, organizations should implement the following mitigations:

• Disable Device Code Flow: If your organization does not utilize legacy devices or IoT hardware that requires this protocol, disable it globally within Microsoft Entra ID (formerly Azure AD).
• Conditional Access Policies: Implement strict Conditional Access policies that require a “Compliant Device” or “Microsoft Entra joined device” for all logins. This prevents attackers from using harvested tokens on non-managed systems.
• Audit OAuth Permissions: Regularly review enterprise applications and user-consented permissions within the SIEM to identify and revoke any suspicious or unauthorized applications.
• User Training: Educate users specifically on the risks of entering codes into the /devicelogin page unless they are physically setting up a company-approved device.

Implementing mitigating OAuth consent phishing attacks requires a multi-layered approach to identity security. Relying solely on MFA is no longer sufficient when attackers can manipulate the protocols that manage the authentication tokens themselves.