OAuth Consent Phishing in 2026: How EvilTokens & ConsentFix Slip Past IT — Audit, Revoke, Recover

Why this matters now

Throughout 2025–2026 security teams worldwide have seen a sharp rise in OAuth consent phishing: attacks that trick users into clicking “Allow” on legitimate identity provider screens or completing device‑code flows so attackers receive valid access and refresh tokens. These attacks bypass traditional defences such as passwords and many multi‑factor authentication (MFA) setups, and they are increasingly available as turnkey phishing‑as‑a‑service kits like EvilTokens and automated techniques known as ConsentFix.

This article explains the real attack patterns we’re seeing in 2026, why they often slip past IT, and gives a practical audit & response checklist you can run today to find, prioritize and revoke dangerous app consents before tokens are abused.

Real examples and attack anatomy (what slipped past IT)

Common consent‑phishing variants observed in incidents and research include:

• Device‑code phishing — the victim is asked to paste or enter a short verification code at a legitimate identity provider URL while the attacker’s client polls the token endpoint; when the user completes the flow, tokens are issued to the attacker. This technique powered the EvilTokens campaigns observed impacting hundreds of Microsoft 365 organizations.
• ConsentFix / ClickFix browser bait — a social‑engineering flow that captures an authorization code or redirects a legitimate first‑party authorization redirect to attacker‑controlled infrastructure; tokens are then exchanged server‑side and give delegated API access without stealing passwords. ConsentFix variants were documented in late 2025 and expanded in 2026.
• Hijacked automation/agents — malicious or over‑privileged agents (for example, Copilot Studio-like agents or abandoned apps) that request broad permissions and are used as supply‑chain pivots into developer consoles and customer data. These flows have resulted in lateral access and secret exfiltration.

Why IT teams miss these: consent grants are durable (tokens often outlive password changes), consent screens can look like first‑party prompts, and many monitoring stacks do not flag legitimate OAuth flows that later become malicious. Attackers exploit both user confusion and gaps in app‑inventory visibility.

Step‑by‑step: Audit, prioritize and revoke dangerous app consents

Use this concise playbook for Microsoft 365 / Entra environments and as a template for other identity providers (Google Workspace, Okta, etc.). Adapt the commands and UI paths to your platform.

1. Inventory granted consents: export your tenant’s OAuth grants and registered service principals. In Microsoft Entra / Azure AD, use the Enterprise Applications view and Graph API to list oAuth2PermissionGrants and delegated consent entries. Record app name, publisher, permissions, first‑seen date and users impacted.
2. Identify high‑risk permissions: prioritize delegated permissions that read mail, files, contacts, calendars, or can send mail as user (Mail.Read, Files.ReadWrite, Contacts.Read, Calendars.ReadWrite, Mail.Send, etc.). Even seemingly low‑risk delegated permissions can be abused at scale.
3. Search for anomalous API activity: hunt for unusual Microsoft Graph, Drive, Gmail, or Drive API calls from non‑standard user agents, large mailbox reads/exports, or mass file downloads. CSA and responder notes link token misuse to Graph enumeration and OneDrive exfiltration patterns.
4. Revoke and isolate: revoke the application’s consent grants immediately (portal or Graph API: DELETE /oauth2PermissionGrants/{id}). If tokens remain active, rotate credentials, disable the service principal, and block the app object. Microsoft Defender for Office 365 / Defender for Cloud Apps include guided workflows to revoke illicit grants.
5. Contain and remediate post‑compromise: reset affected user sessions, enforce conditional access re‑auth, remove attacker‑created mail rules, re‑scan for mail forwarding, and use eDiscovery to identify data accessed. Document timelines for each affected user and scope in your incident log.
6. Apply long‑term hardening: implement app consent policies that require admin approval for high‑risk scopes, restrict who can register apps, enforce OAuth grant restrictions, and whitelist approved third‑party apps. Monitor newly‑created app registrations and require just‑in‑time admin review for broad scopes.

Quick PowerShell / Graph tip: script an export of permission grants and service principals, then join with sign‑in logs to find first‑seen consent times and suspicious IPs or user agents. Use automation to revoke high‑risk grants when they appear outside approved app lists.