The OAuth Consent Trap: How EvilTokens Phishing Bypassed MFA

In early 2026, a new phishing-as-a-service (PhaaS) platform named EvilTokens emerged, quickly compromising over 340 Microsoft 365 organizations across five countries within just five weeks. Unlike traditional credential phishing, this attack exploited a legitimate Microsoft feature—the device login flow—and combined it with OAuth consent to bypass multifactor authentication (MFA). Victims were tricked into entering a short code at microsoft.com/devicelogin, completing their normal MFA challenge, and unknowingly granting access to a malicious app. This Q&A explains how the attack works, why MFA alone isn't enough, and what you can do to stay protected.

What Is EvilTokens and How Did It Operate?

EvilTokens is a phishing-as-a-service (PhaaS) platform that launched in February 2026. It targeted Microsoft 365 tenants by tricking users into completing an OAuth consent prompt instead of a simple login. The platform sent convincing messages—often via email or Microsoft Teams—asking recipients to enter a short code at the legitimate Microsoft URL microsoft.com/devicelogin. After entering the code, users were prompted to authenticate with their MFA method. If they complied, they inadvertently granted consent to an OAuth application controlled by the attacker. Within five weeks, EvilTokens had breached more than 340 organizations across five countries, demonstrating the speed and scale of modern phishing operations.

How Does OAuth Consent Bypass MFA?

The attack exploits a design gap in the OAuth flow. When a user completes MFA during a device login request, they are proving identity—but the subsequent consent step is often treated as a post-authentication action. The user sees a standard MFA challenge (e.g., a code from an authenticator app or SMS) and assumes that successfully passing it is sufficient. However, after MFA, they are still prompted to approve OAuth permissions for an app. Many users, conditioned to click “Accept” without reading, grant an attacker's app access to mail, files, or other resources. This consent is persistent: the attacker holds a valid refresh token that works even after the user changes their password or resets MFA, because the token was obtained via an OAuth grant, not a password.

Why Is the Device Login Flow Vulnerable?

The device login flow (microsoft.com/devicelogin) is a legitimate feature designed for devices without full browsers—like smart TVs, game consoles, or command-line tools. It requires the user to enter a short code on a separate device to authenticate. Because the URL is official and users trust Microsoft's domain, the technique feels safe. Attackers weaponize this trust: they send a message directing the victim to the real Microsoft site, which increases the likelihood of compliance. The victim completes MFA on that trusted page, but the OAuth consent prompt that follows is presented as a legitimate second step. Users rarely realize that by clicking “Accept,” they are giving the attacker an app permission, not simply finishing their login. The combination of a trusted URL and the MFA success blinds users to the true danger.

What Are the Risks to Organizations After Compromise?

Once an attacker obtains OAuth consent, they gain persistent access to the user’s data and applications. Because the granted access is token-based, it doesn't rely on the user's password. This means even if the organization forces a password reset or changes MFA settings, the attacker’s token remains valid. Common risks include:

• Data exfiltration: Attackers can silently download emails, files from SharePoint, OneDrive, or Teams.
• Lateral movement: With access to a user’s mailbox or cloud apps, attackers can launch further phishing campaigns from within the organization.
• Credential theft: OAuth tokens can be used to request more permissions or to access other services the user has access to.
• Long-term persistence: The token may not expire for months or even years, giving attackers a stealthy foothold.

How Can Organizations Defend Against OAuth Consent Phishing?

Defending against this threat requires a layered approach. Key strategies include:

1. Restrict OAuth app consent: Use Microsoft Entra ID policies to block all OAuth apps that aren't pre-approved by IT or that require high-risk permissions.
2. Educate users: Teach users to treat any OAuth consent prompt—especially after already completing MFA—with extreme suspicion. They should never approve permissions they don't fully understand.
3. Monitor OAuth activity: Regularly audit authorized OAuth applications using cloud security tools. Look for apps with suspicious names, unknown publishers, or permissions to read mail or files.
4. Enable conditional access policies: Require device compliance or location-based checks before granting tokens.
5. Use anti-phishing protections: Deploy solutions that detect phishing attempts targeting device login flows.

What Should Users Do If They Suspect They've Been Phished?

If a user realizes they may have fallen for an OAuth consent phishing attack, they should act immediately:

• Revoke the OAuth consent: Go to myapps.microsoft.com, remove the suspicious application from “Enterprise Applications” or “App Registrations.”
• Change password and re-enforce MFA: Even though the token may still work, changing credentials limits further misuse. Also reset MFA methods.
• Contact your security or IT team: Report the incident so that the organization can revoke tokens at the admin level and check for any data breach.
• Review recent activity: Look for unusual logins, email forwarding rules, or file downloads in your account activity logs.
• Monitor for follow-up attacks: Attackers often use compromised accounts to target others in the organization.