In February 2026 a phishing-as-a-service platform called EvilTokens went live; within five weeks it had compromised more than 340 Microsoft 365 organizations across five countries.
EvilTokens and the new phishing economy
EvilTokens introduced a simple but powerful shift: instead of stealing passwords, it tricks users into issuing an OAuth refresh token. Targets were prompted to enter a short code at microsoft.com/devicelogin and complete their usual MFA challenge, then left believing they had verified a routine sign-in. In reality the operator walked away with a refresh token scoped to mailbox, drive, calendar, and contacts tied to the tenant's policy lifetime rather than to a short session.
The result: the attacker did not need a password, did not trigger an anomalous MFA prompt, and did not generate a sign-in event that looked like an intrusion. Security researchers call this class of attack consent phishing or OAuth grant abuse.
How the OAuth consent click defeats MFA
OAuth grants differ fundamentally from credential replay. In the EvilTokens pattern the user authenticates on the legitimate identity provider, completes MFA on the legitimate domain, and clicks Accept. The token issued is signed by the identity provider, scoped to what the user approved, and refreshable. Because the MFA flow has already completed on the legitimate site, MFA protections cannot block the resulting grant.
Refresh tokens extend the window of compromise. The tokens issued by EvilTokens remained valid through password resets and persisted for weeks or months depending on tenant configuration. Rotating a password did not invalidate the grant; only explicit revocation or a conditional access policy that demanded re‑consent removed it.
Toxic combinations, MCP servers, and the Salesloft‑Drift precedent
OAuth consent has been normalized. Users click consent screens at rates comparable to past cookie‑banner behavior: AI agents, productivity integrations, and browser extensions routinely request access. Scope labels such as "Read your mail" or "Access files when you're not present" obscure operational reach—"Read your mail" can include every accessible message and attachment, while "Access files when you're not present" enables long‑lived, unattended access.
Risk amplifies when separate, legitimate grants bridge applications through a single human identity. The source describes a finance user who separately approved an AI meeting summarizer (calendar and mailbox), a productivity assistant (shared drive), and a CRM enrichment tool (customer database). Each approval was legitimate on its own; together they formed a "toxic combination" in which a compromise of one integration can cross into contracts, customer records, and other assets via the same identity.
Model Context Protocol (MCP) servers are identified as an emerging OAuth‑style attack surface, allowing agents to acquire scoped reach using the same trust‑once mechanism. The 2025 Salesloft‑Drift incident is cited as a concrete precedent: a compromised downstream connector spread across more than 700 Salesforce tenants using OAuth tokens that customers had legitimately approved. Each customer authorized the integration; none authorized the cascade.
Where AI security platforms such as Reco fit in
The source argues that visibility must move from periodic audits to continuous runtime discovery. A new class of platforms maps OAuth grants, AI agents, and third‑party integrations into an identity graph the moment they appear. One named example is Reco. According to the account, Reco combines AI agent security, identity governance, and threat detection in a single control plane and maintains an Identity Knowledge Graph that connects human and non‑human identities to applications, OAuth grants, and integrations across a SaaS estate.
These platforms claim to continuously discover AI agents and OAuth grants, map scopes back to the approving identity, monitor for policy deviations, and revoke access at the token level rather than by disabling a user account—giving security teams visibility into the runtime layer where trust relationships form.
What this means for security teams, procurement leaders, and end users
- Security teams: Treat OAuth consent like authentication. The source recommends continuous mapping of grants and agents into an identity graph, monitoring for "toxic combinations," and enabling token‑level revocation and conditional access policies that force re‑consent.
- Procurement and application owners: Beware of downstream cascades. The Salesloft‑Drift example shows that legitimate approvals can propagate risk across hundreds of tenants; procurement decisions should consider how connectors and agents chain through identities outside any single application's audit log.
- End users and knowledge workers: Consent screens have operational consequences. Scope labels can understate reach; the source emphasizes that users are effectively granting long‑lived, refreshable access when they accept certain permissions.
Consent phishing is not an edge case any longer. Years of investment in phishing‑resistant authentication have reduced password‑replay attacks, but the consent layer remains largely trust‑based. Closing the gap described here relies on parity between how organizations govern authentication and how they govern OAuth grants and AI‑agent connections: continuous discovery, mapped identity graphs, policy monitoring, and the ability to revoke at the token level or force re‑consent when risk rules change.
