EvilTokens PhaaS Platform Exploits OAuth Consent, Bypassing MFA Protections
A new phishing-as-a-service (PhaaS) platform, **EvilTokens**, has emerged, successfully compromising over 340 **Microsoft 365** organizations in just five weeks. The platform leverages OAuth consent abuse, bypassing traditional Multi-Factor Authentication (MFA) and leaving organizations vulnerable.

In February 2026, the **EvilTokens** platform went live, quickly demonstrating the dangers of unchecked OAuth consent. Targets were tricked into entering a code at `microsoft.com/devicelogin` and completing an MFA challenge, unknowingly granting attackers a refresh token with broad permissions, including access to mailboxes, drives, calendars, and contacts. This token persisted according to tenant policy, far exceeding the lifespan of a typical session.
This attack sidesteps traditional security measures as it doesn't involve stolen passwords or suspicious sign-in events. Instead, it exploits the normalization of OAuth consent screens, where users often instinctively click 'Accept' without fully understanding the permissions granted.
## Why MFA Fails Against OAuth Grant Abuse
Traditional credential phishing relies on replaying stolen usernames and passwords, triggering MFA prompts and leaving a trail for Security Information and Event Management (SIEM) systems to detect. However, OAuth grant abuse produces no such replay. The user authenticates on the legitimate identity provider, completes MFA, and grants consent. The resulting token is valid, signed by the identity provider, and refreshable, rendering MFA ineffective in blocking the attack.
<table><tbody><tr><td></td></tr><tr><td>Figure 1: Credential phishing leaves a sign-in trail the SIEM can correlate.</td></tr></tbody></table>
<table><tbody><tr><td></td></tr><tr><td>Figure 2: An OAuth grant leaves no replay, just a refreshable token.</td></tr></tbody></table>
Furthermore, refresh tokens issued by **EvilTokens** remained valid even after password resets, persisting for weeks or months based on tenant configuration. Only explicit revocation or conditional access policies requiring re-consent could terminate the grant.
## The Normalization of Consent
The OAuth consent attack vector isn't new, but its effectiveness has increased due to user desensitization. Users are bombarded with consent screens from AI agents, productivity integrations, and browser extensions, leading to a click-through mentality similar to cookie banners.
The language used in consent scopes often masks the true extent of the permissions granted. For example, "Read your mail" can encompass every message, attachment, and shared thread. This discrepancy between consent language and operational reach is exploited by attackers.
## Toxic Combinations: Cross-Application Risk
The real danger lies in the combination of multiple OAuth consents across different applications, creating what researchers call "toxic combinations." For example, a finance user granting access to their calendar and mailbox to an AI meeting summarizer, and then granting access to the company's shared drive to a productivity assistant, creates a risk surface where a compromise in one application can cascade to others.
<table><tbody><tr><td></td></tr><tr><td>Figure 3: A toxic combination between two SaaS apps no owner sanctioned together.</td></tr></tbody></table>
The **Salesloft**-**Drift** incident in 2025 highlighted this risk at scale. A compromised downstream connector spread across over 700 **Salesforce** tenants via legitimate OAuth tokens, demonstrating the cascading effect of compromised integrations.
## Proactive Measures to Mitigate OAuth Risks
Organizations need to treat OAuth consent with the same rigor as authentication. Key areas to review include:
* **OAuth Application Inventory:** Continuously monitor all third-party apps holding refresh tokens.
* **Grant Age and Re-Consent:** Flag tokens issued long ago without re-consent.
* **Cross-Application Identities:** Identify identities holding grants across multiple SaaS applications.
* **Agent and Integration Bridges:** Detect AI agents and integrations bridging systems without explicit authorization.
* **Conditional Access on Consent:** Implement policies triggered by consent events, not just sign-in events.
* **Token-Level Revocation:** Establish playbooks for revoking individual OAuth tokens.
These measures require a platform capable of continuously monitoring the runtime layer where these bridges form, as procedural discipline alone cannot scale to address the speed at which these risks emerge.
## AI Security Platforms
A new class of platforms is emerging to automate much of this process, mapping OAuth grants, AI agents, and third-party integrations to provide comprehensive visibility and control over the OAuth landscape.