EvilTokens PhaaS Platform Compromises 340+ Microsoft 365 Orgs via OAuth Consent Abuse
The EvilTokens phishing-as-a-service platform compromised over 340 Microsoft 365 organizations in five weeks by abusing OAuth device code authentication, bypassing MFA entirely.
In February 2026, a new phishing-as-a-service (PhaaS) platform called EvilTokens went live. Within five weeks, it had compromised more than 340 Microsoft 365 organizations across five countries, according to researchers tracking the campaign.
The attack chain is deceptively simple. Victims receive a message asking them to enter a short code at microsoft.com/devicelogin and complete their normal MFA challenge. After doing so, they walk away believing they have verified a routine sign-in. In reality, they have handed the attacker a valid refresh token scoped to their mailbox, drive, calendar, and contacts — with the lifespan of a tenant policy rather than a session.
The operator never needs a password, never trips an MFA prompt, and never produces a sign-in event that looks like an intrusion. The attack succeeds because the OAuth consent screen has become an instinctive click, and the controls built to stop credential phishing do not look at the consent layer. Security researchers call this condition consent phishing or OAuth grant abuse.
A credential phish hands over a username and password that must be replayed somewhere, and most identity stacks now demand a second factor at the replay. Even adversary-in-the-middle (AiTM) kits produce a session cookie tied to a sign-in event that the SIEM correlates against geography, device, and travel patterns. An OAuth grant produces no replayed credentials. The user authenticates on the legitimate identity provider, finishes the MFA challenge on the legitimate domain, and clicks Accept. The token the attacker walks away with is the system working as designed. It is signed by the identity provider, scoped to whatever the user agreed to, and refreshable. MFA cannot block it because MFA has already happened.
The other problem is that refresh tokens extend the window. The tokens EvilTokens issued survived password resets and remained valid for weeks or months, depending on the tenant configuration. Rotating the password did not invalidate the grant. Only explicit revocation, or a conditional access policy that demanded re-consent, closed it.
This attack vector has existed since OAuth became standard. What changed is the environment it operates in. Users have been trained to click through consent screens at the rate they once clicked through cookie banners. Every AI agent installs Surface One. Every productivity integration surfaces one. Every browser extension that touches a SaaS account surfaces one. The volume of legitimate consent that a knowledge worker sees in a month exceeds anything that existed when the original OAuth threat models were written. The scopes themselves use language that does not map cleanly to risk. A scope called "Read your mail" sounds limited, but in practice it covers every message, attachment, and shared thread the user can access. A scope called "Access files when you're not present" means a long-lived token issued without the user being in front of a screen to revoke it.
A single OAuth consent gives an attacker a scoped foothold inside one application. The deeper risk forms when those footholds bridge. A finance user grants an AI meeting summarizer access to their calendar and mailbox. The same user later grants a productivity assistant access to the company's shared drive. A third grant connects a CRM enrichment tool to the customer database. Each was approved one at a time. No application owner sanctioned the combination. The risk surface is now three scopes intersecting through one human identity, where the meeting summarizer's compromise can reach contract drafts and customer records through the same person. This is called a toxic combination — a permission breakdown across applications, bridged by an OAuth grant, an integration, or an AI agent, that no single application owner ever authorized as its own risk surface.
Closing this gap calls for treating OAuth consent the same way the security program already treats authentication. Organizations should maintain an OAuth application inventory of every third-party app holding refresh tokens in the tenant, refreshed continuously rather than at audit time. Tokens issued more than 30 days ago without re-consent should be surfaced as a queue. Identities holding grants across three or more SaaS applications should be flagged for review. The 2025 Salesloft-Drift incident showed what this looks like at scale: a compromised downstream connector spread across more than 700 Salesforce tenants through OAuth tokens that the customers had legitimately approved. Each customer authorized the integration. None authorized the cascade.