The New Phishing Click: How OAuth Consent Bypasses MFA

PhaaS Platform EvilTokens Bypasses MFA by Exploiting OAuth Consent Screens

TL;DR — EvilTokens, a phishing-as-a-service platform that went live in February 2026, compromised more than 340 Microsoft 365 organizations within five weeks by directing users to legitimate OAuth consent screens. Victims completed MFA on legitimate domains but unknowingly granted attackers refresh tokens valid for weeks or months—tokens that survived password resets and left no sign-in event that traditional defenses could detect. The attack exploits a structural gap: MFA protects authentication, but OAuth consent sits below it.

What happened

EvilTokens operationalized a consent-phishing attack at scale. The platform sent targets a message directing them to enter a short code at microsoft.com/devicelogin and complete their normal MFA challenge. Users authenticated on the legitimate Microsoft identity provider, completed the second factor on the legitimate domain, and clicked Accept on what appeared to be a routine device registration.

What they had actually done was grant the operator a valid OAuth refresh token scoped to their mailbox, drive, calendar, and contacts. The token carried the lifespan of a tenant policy—weeks or months depending on configuration—rather than a session. Critically, rotating the password afterward did not invalidate the grant.

The operator obtained this access without replaying credentials, without triggering an MFA prompt at any point, and without producing a sign-in event that a SIEM could flag as anomalous. From the identity infrastructure's perspective, the system worked as designed: a user authenticated, satisfied the second factor, and consented to a scope. The machinery that stops credential phishing—replay detection, anomalous sign-in correlation, MFA—cannot see this layer.

Why it matters

For defenders and engineers, this represents a fundamental inversion of the threat model. Credential phishing required an attacker to either replay stolen passwords (caught by MFA) or trick a user into handing over credentials in real time (difficult when MFA exists). OAuth grants bypass both because the user is authenticating on the real domain, completing real MFA, and the token issued afterward is legitimate.

The window for detection narrows further because refresh tokens are designed to persist across sessions and survive password rotations. An attacker with a valid refresh token can access mailbox, calendar, contacts, and drive data indefinitely—until an administrator explicitly revokes the grant or a conditional access policy forces re-consent.

The second-order risk emerges when users hold OAuth grants across multiple SaaS applications. A finance user who grants an AI meeting summarizer access to calendar and mailbox, then grants a productivity assistant access to shared drive, has created what researchers call a "toxic combination"—permission bridges that no single application owner sanctioned and that no individual audit log can see. If the meeting summarizer is compromised, the attacker walks a path through the same user identity to contract drafts and customer records.

This risk scales rapidly in environments where knowledge workers encounter dozens of consent screens monthly—AI agents, productivity integrations, browser extensions—each asking for overlapping scopes. The normalization of the consent click has inverted its threat profile from a rare, high-friction moment to a reflexive action.

Affected systems and CVEs

• Microsoft 365 (mailbox, drive, calendar, contacts scopes targeted)
• OAuth-based SaaS applications (scope and configuration dependent)
• Salesforce (referenced via 2025 Salesloft-Drift incident)
• Model Context Protocol (MCP) servers (emerging attack surface)

No CVE assigned at the time of publication.

What to do

• Maintain an inventory of all third-party OAuth applications holding refresh tokens in the tenant, refreshed continuously rather than at audit time.
• Implement conditional access policies that re-trigger re-consent on consent events, not only on sign-in events. This will invalidate long-lived tokens when a policy violation occurs.
• Flag identities holding grants across three or more SaaS applications for review to identify users who bridge multiple permission domains.
• Revoke individual OAuth tokens rather than suspending user accounts. Token-level revocation preserves user access while removing the compromised grant.
• Monitor for tokens issued more than 30 days ago without re-consent and surface them as an operational queue for review.
• Map AI agents and integrations bridging multiple systems to identify unauthorized toxic combinations that exist outside any single application owner's audit trail.
• Implement platforms that continuously discover and monitor OAuth grants and AI agents at the runtime layer where bridges actually form, rather than relying on periodic audits.

Open questions

• The specific countries affected by EvilTokens are not named in the source.
• No technical identifiers or CVE numbers have been assigned to the EvilTokens platform.
• The exact scope of social engineering techniques EvilTokens provided as part of its service is not detailed.
• Detection methods used by security researchers to identify EvilTokens activity are not specified.
• The source does not clarify whether Microsoft 365 released patches or policy updates in response to the campaign.
• The specific consent language or UI patterns used by EvilTokens to reduce victim suspicion are not described.
• The timeline for when organizations discovered the compromise and began remediation is not provided.

Source

The New Phishing Click: How OAuth Consent Bypasses MFA