Phishing consent: the new vector that steals tokens OAuth and expands access

In February 2026 a service emerged that summarizes the evolution of the phishing: EvilTokens. In less than five weeks this phishing- as- service platform committed more than 340 organizations that use Microsoft 365 in five countries, not stealing passwords but asking for an apparently harmless OAuth consent on microsoft.com / devilentin. The user completed his legitimate MFA, click on "OK" and went back to his task with the feeling of having checked a routine login; instead, the attacker was taking a valid and renewable refresh token with access to mail, calendar, unit and contacts, which lasted as long as the tenant's policy allowed.

The mechanics of the attack reveals a conceptual break: the OAuth consent layer is kept outside the perimeter that many organizations rigorously protect. While the theft of credentials causes recognizable signals - reattempts, session correlations, requests from abnormal locations - a legitimate OAuth grant is indistinguishable from the normal operation of the identity provider; it is signed, it carries scopes that the user accepted and does not generate the type of event that traditional SIEMs consider suspicious. The result is what the community calls consent phishing u OAuth grant abuse, a vector that exploits user confidence and protocol design. To understand your technical basis, you should review the standard: OAuth 2.0 (RFC 6749).

Two properties make this abuse particularly powerful: the first, that authentication and MFA occur in the legitimate domain, so the anti-phishing controls focused on credentials fail; the second, that the refresh tokens extend the exposure window and often survive password changes. The practical consequence: an attacker does not need to reproduce a human session or draw MFA, because he has obtained an access device with the same validity that the rest of the ecosystem is confident to use automatically.

The current ecosystem amplifies the problem. Workers receive a monthly avalanche of consent requests: IA agents that integrate with calendars, browser extensions that demand access to SaaS accounts, connectors that link third-party applications. The language of the scopes - "Read your mail," "Access files when you are not present" - hides a wide operational scope: each scope is usually translated into access to all messages, attachments, shared files and resources that the user can reach. That gap between label and capacity is the gap where attackers like EvilTokens operators move.

The real risk is not only isolated access to an account, but the toxic combinations that emerge when apparently benign permits are interconnected through a human identity. A user gives a meeting assistant access to the calendar and mail, then authorizes another agent to the shared driver and a third service to the CRM; none of these approvals were designed to interoperate, but together create a bridge that allows an attacker to pivote between confidential information, contracts and customer data. These "toxic combinations" do not appear in the log of a single application because the connection occurs outside the domain of any application owner.

A new emerging front is the Model Context Protocol (MCP) and equivalent servers that make it easier for IA agents to acquire reach through the same unique confidence mechanism that the consent screens exploit. We already saw scale events by similar mechanisms: in 2025 a chain of legitimate concessions allowed a committed connector to spread among hundreds of Salesforce tenants, showing that the OAuth waterfall can turn an isolated concession into a massive infection.

Closing this gap requires changing the way consent is governed: we must treat the OAuth grants and the connections of IA agents with the same discipline that applies to authentication. This means policies that limit automatic delegation, agile revocation of tokens at application level, continuous monitoring of the graph of identities and concessions, and technical measures that reduce the longevity of the refresh tokens. Microsoft and other suppliers publish guidelines on flows such as the Device Code and how tokens should be handled correctly; it helps them understand the configuration options: Azure AD - OAuth 2.0 Device Code.

In addition to adjusting configurations, organizations should incorporate real-time detection and visibility on the consent runtime. Tools that map a graph of identities and concessions at the time of their creation make it easier to see unexpected bridges, unused tokens or policy deviations before they become an incident. The integration between identity governance, threat detection and control of IA agents becomes a priority to reduce the exposure window and automate mediation: from revoking a committed grant to firing re- forced consent or implementing risk-conditioned policies.

In operational terms, security teams should require administrative approval for high-speed applications, apply less privileged principles in default approvals, limit the duration of refresh tokens where the supplier allows and enable the monitoring of unusual application activities (e.g. mass exports or off-schedule access). Training is still necessary, but it will no longer be enough to instruct users not to click: it is necessary for the technological environment to make it difficult to allow extensive permits by mistake.

Finally, the phenomenon requires rethinking responsibility: the risk area is a graph that no individual application controls completely. Therefore effective mitigation combines platform controls (tenant configurations, conditional access policies), tools that observe real-time consent graph and organizational processes that reduce the speed at which bridges can be created (provision of agents, approval processes, vendor verification). The reaction time should be shortened from weeks and regular audits to minutes and operational queues next to the issue of the grant.

The threat model has evolved: we no longer only defend credentials, we defend the act of granting permits. Treating consent as a critical resource and applying visibility, limitation and revocation with the same priority as access control and MFA is the line of defense that prevents services like EvilTokens from becoming the exception and become routine.