OAuth Consent Phishing Bypasses MFA: 340+ Organizations Compromised in Five Weeks

In February 2026, the EvilTokens phishing-as-a-service platform went operational. Within five weeks, it compromised more than 340 Microsoft 365 organizations across five countries. Victims entered a device code at microsoft.com/devicelogin, completed their normal MFA challenge, and walked away believing they had verified a routine sign-in. They had actually issued a valid refresh token scoped to mailbox, drive, calendar, and contacts—with a lifespan measured in weeks or months rather than hours.

The attacker never needed a password, never triggered an MFA prompt after initial authentication, and never produced a sign-in event that looked like an intrusion. Password resets did not invalidate the grant. Only explicit token revocation or a conditional access policy demanding re-consent closed the access. This is OAuth consent phishing, and it sits structurally below the identity controls most organizations still treat as their security perimeter.

Why MFA Cannot See the Attack

Traditional credential phishing hands over a username and password that must be replayed somewhere. Modern identity stacks demand a second factor at replay. Even adversary-in-the-middle toolkits produce session cookies tied to sign-in events that SIEMs correlate against geography, device fingerprints, and impossible travel patterns. The replay leaves a trail.

An OAuth grant produces no replayed credentials. The user authenticates on the legitimate identity provider, completes the MFA challenge on the legitimate domain, and clicks Accept. The token the attacker receives is the system working as designed. It is signed by the identity provider, scoped to whatever the user agreed to, and refreshable without further authentication. MFA cannot block it because MFA has already occurred. The token is structurally indistinguishable from legitimate application access.

How Consent Got Normalized

This attack vector has existed since OAuth became standard. What changed is the environment it operates in. Users now encounter consent screens at the rate they once saw cookie banners. Every AI agent, productivity integration, and browser extension that touches a SaaS account surfaces a consent prompt. The volume of legitimate consent requests 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 labeled 'Read your mail' sounds limited but 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 at the keyboard to monitor or revoke it. The gap between consent language and operational reach is exactly where attackers operate.

Toxic Combinations: Risk That No Application Owner Sanctioned

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 calendar and mailbox. The same user later grants a productivity assistant access to the company shared drive. A third grant connects a CRM enrichment tool to the customer database. Each was approved individually. 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. Security researchers call this a toxic combination: a permission breakdown across applications, bridged by an OAuth grant, integration, or AI agent, that no single application owner ever authorized as a combined risk surface. It cannot be seen in any one application's audit log because the bridge exists outside all of them.

The 2025 Salesloft-Drift incident demonstrated this at scale. A compromised downstream connector spread across more than 700 Salesforce tenants through OAuth tokens that customers had legitimately approved. Each customer authorized the integration. None authorized the cascade.

What Organizations Miss in Current Controls

Most identity security programs focus on authentication events. They monitor sign-ins, flag impossible travel, detect credential stuffing, and enforce MFA at the perimeter. These controls sit above the consent layer. An OAuth grant does not look like an authentication event—it looks like an application integration. The telemetry lives in a different log stream, uses different schemas, and rarely feeds the same correlation rules that detect credential compromise.

Conditional access policies typically re-evaluate on sign-in but not on consent. A user who clicks Accept on a malicious OAuth application may not trigger a policy that would have blocked a suspicious sign-in from the same context. The consent event bypasses the control plane entirely. The token that results is valid, refreshable, and invisible to tools built to detect session hijacking.

Detection and Response Framework

Closing this gap requires treating OAuth consent the same way your security program already treats authentication. Organizations need continuous visibility into OAuth application inventory—not a quarterly audit, but a live feed of every third-party app holding refresh tokens in the tenant. This includes application name, publisher, scopes granted, grant date, last refresh date, and the identities that issued consent.

Focus detection efforts on these high-risk indicators:

• Tokens issued more than 30 days ago without re-consent, surfaced as a work queue rather than a report
• Identities holding grants across three or more SaaS applications, flagged for toxic combination review
• AI agents and integrations bridging two systems no application owner sanctioned together
• Consent events from unmanaged devices or non-corporate networks
• Applications requesting scopes that exceed their stated function

Response playbooks must include token-level revocation procedures that do not require suspending the user account. When a suspicious OAuth grant is identified, the security team needs a process to revoke that specific token without disrupting the user's legitimate access to other applications. This is not the same workflow as a compromised password—it requires different tooling and different runbooks.

Conditional Access for Consent Events

Extend conditional access policies to trigger on consent events, not only sign-in events. If your policy blocks sign-ins from unmanaged devices, it should also block OAuth consent grants from unmanaged devices. If your policy requires privileged users to authenticate from specific networks, that same requirement should apply when those users click Accept on an application requesting mail or file access.

Implement consent age policies that force re-consent after a defined period. A token issued six months ago with broad scopes should not remain valid indefinitely. Requiring periodic re-consent creates a natural expiration mechanism and gives security teams a checkpoint to review whether the application still requires the access it was originally granted.

Operational Recommendations

Start with an OAuth application inventory pull today. Export every application with active refresh tokens in your M365, Google Workspace, or primary SaaS tenants. Sort by grant date and scope breadth. Flag any application you do not recognize or that has not been reviewed in the last 90 days. This is not a compliance exercise—it is threat hunting.

Build detection rules for consent events in your SIEM or identity security platform. Correlate consent grants with sign-in context, device posture, and user role. Alert on consent events that occur outside normal business hours, from high-risk locations, or from users who do not typically install integrations. Treat these alerts with the same urgency you give to impossible travel or credential spray attempts.

Review your incident response playbooks for OAuth compromise scenarios. Ensure your SOC knows how to revoke a token without locking the user account. Document the process for identifying all tokens issued by a compromised identity and the procedure for forcing re-consent across a department or tenant. Test the playbook before you need it under pressure.

The phishing click that mattered last decade handed over a password. The phishing click that matters now hands over a refresh token, and it sits structurally below the identity controls most organizations still treat as the perimeter. EvilTokens compromised 340 organizations in five weeks because those organizations had not extended their identity security posture to cover the consent layer. The question is not whether your environment is exposed—it is whether you can see the exposure before an attacker exploits it.