The EvilTokens platform, operating under a “phishing as a service” (PhaaS) model, according to Cloud Security Alliance data, exploits the OAuth device code flow mechanism in Microsoft 365 to obtain long-lived refresh tokens. Victims complete legitimate MFA-backed authentication on the real Microsoft domain yet unknowingly hand the attacker a token with access to their email, files, calendar, and contacts. Multi-factor authentication cannot block this attack because, by the time the token is issued, MFA has already been successfully completed. Organizations using Microsoft 365 need to revisit their OAuth consent and token management policies.

Attack mechanism: device code flow as a vector

The attack abuses a standard Microsoft authentication mechanism — device code flow, designed for devices without a full-featured browser. The victim receives a message asking them to enter a short code on the microsoft.com/devicelogin page and pass the usual MFA check. From the user’s perspective, this looks like a routine sign-in verification.

However, after authentication is completed, the system issues the refresh token not to the user but to the operator of the EvilTokens platform. As stated in the CSA research note, this token:

• Is signed by Microsoft as a legitimate identity provider
• Covers access to the mailbox, OneDrive, calendar, and contacts
• Has a lifetime defined by the tenant policy rather than the session
• Is believed to remain valid even after a user password reset

The key issue is that the attacker does not intercept credentials or replay a session. The token is the result of normal system behavior. The sign-in event appears legitimate in the logs because authentication genuinely occurred on the real Microsoft domain with a valid second factor.

Why MFA does not provide protection

Traditional credential phishing requires reusing the password, and this is precisely where MFA creates a barrier. Even “adversary in the middle” (AiTM) attacks leave session cookies in the logs that SIEM systems can correlate with geography and device data.

In the case of OAuth consent phishing, the user themselves completes authentication with the legitimate provider. MFA triggers and is successfully passed before the token is issued. The token the attacker receives is not the result of a compromise — it is the result of consent granted by the user. According to the researchers, simply changing the password is not enough to revoke this access: you must explicitly revoke the token or enforce a conditional access policy that requires renewed consent.

Consent normalization as a risk factor

The OAuth consent attack vector has existed for some time, but its effectiveness has increased sharply due to changes in user behavior. Every AI agent, every productivity integration, every browser extension working with SaaS accounts requests OAuth consent. The volume of legitimate consent prompts an employee encounters in a month far exceeds what was assumed in the original OAuth threat models.

The wording of requested permissions makes the problem worse. The scope “Read your mail” in practice covers all messages, attachments, and shared threads. The scope “Access your files when you’re offline” means issuing a long-lived token that works without the user being present. The gap between the language of consent and the true breadth of access is exactly the space in which attackers operate.

Toxic combinations of permissions

A single OAuth grant gives an attacker a limited foothold in one application. Systemic risk arises when multiple grants intersect through a single user identity. For example: a finance department employee grants an AI assistant access to their calendar and email, another tool gets access to the corporate file store, and a third to the CRM customer database. Each consent is granted separately; no individual application owner has authorized the combination. Compromise of any one of these tools can potentially open access to contracts and customer data via the same identity.

This risk is not visible in any individual application audit log because the bridge between them exists at the identity level, outside each application’s perimeter. Analysts note that Model Context Protocol (MCP) servers create a similar attack surface, allowing AI agents to gain access via the same one-time consent mechanism.

Practical recommendations

To defend against OAuth consent phishing, control must be shifted from the authentication layer to the consent layer:

1. Restrict application registration in Entra ID: prevent users from independently granting applications access. Configure an administrative approval workflow for all OAuth grants requesting access to mail, files, and calendar.
2. Configure conditional access policies for tokens: shorten the lifetime of refresh tokens, require re-authentication for sensitive resources, and enable Continuous Access Evaluation policies.
3. Audit existing OAuth grants: in Entra ID, review the “Enterprise applications” → “Consents and permissions” section. Identify applications with broad scopes (Mail.Read, Files.ReadWrite.All, offline_access) and revoke unused or suspicious grants.
4. Disable device code flow: if this authentication mechanism is not required for business processes, block it via conditional access policies. This eliminates the specific vector used by EvilTokens.
5. Monitor consent events: configure SIEM alerts for OAuth grant events, especially for applications registered outside the tenant and for grants with broad scopes.
6. Inventory grant intersections: identify users whose combined OAuth consents create bridges between critical systems (mail + storage + CRM) and assess the aggregate risk.

OAuth consent phishing is not a theoretical threat but an active attack vector backed by commercial infrastructure. The most important action now is to forbid users from independently granting OAuth consents in Microsoft 365 and review all existing grants with broad scopes. Organizations that continue to rely solely on MFA as the boundary of identity protection are leaving exposed exactly the layer modern attacks are exploiting.