Summary

OAuth consent phishing bypasses the controls most organizations rely on to stop account takeover. The victim authenticates on real identity provider infrastructure, completes MFA legitimately, and hands an attacker-controlled application a token that survives a password reset. Over the past year, phishing-as-a-service operators have turned this into a subscription product, and the device code variant once reserved for state-aligned actors now ships as a turnkey kit. This post covers how the attack works, what changed to make it commodity-grade, and the detections and controls that catch it where MFA and password resets cannot.

How OAuth Consent Phishing Works

Specific campaigns differ in delivery and payload, but the attack chain follows a consistent pattern.

Step 1: Malicious App Registration

The threat actor registers an OAuth application in an identity provider they control (Entra ID tenant, Salesforce org, Google Cloud project). Naming and branding are chosen to look legitimate or unremarkable, such as “Document Viewer,” “Data Loader,” or “My Ticket Portal.” The actor sets a redirect URI pointing to attacker infrastructure and selects the scopes the app will request. A multi-tenant configuration lets the application solicit consent from users in any organization.

Step 2: Phishing

The actor distributes the consent link by email, Teams or Slack message, watering hole site, or voice phishing call. The lure frames the prompt as an expected authorization step for a document, meeting, helpdesk ticket, or security alert. The goal is simply to get the user onto the real identity provider’s consent screen, where the URL and branding will appear trustworthy.

Step 3: User Clicks OAuth URL

The user signs in on the legitimate identity provider and completes MFA if required. Because authentication happens against the real platform, MFA is satisfied without the attacker ever handling the credential.

Step 4: App Generates Authentic Consent Prompt

The identity provider renders a genuine consent screen listing the permissions the application requests. Nothing about the page is spoofed, which is what makes the technique effective against user awareness training focused on fake login pages.

Step 5: User Grants Data Permissions

The user clicks Accept. The identity provider creates a service principal for the application in the user’s tenant, binding the attacker’s app to the organization.

Step 6: Authorization Code Created and Sent

The identity provider issues an authorization code and sends it to the attacker-controlled redirect URI.

Step 7: Attacker Gains Persistent Access

The application exchanges the code for an access token and, if offline_access or an equivalent scope was granted, a refresh token. The actor now holds valid credentials and needs no further interaction with the victim. Those tokens are used to query APIs for email, files, contacts, CRM records, or whatever the granted scopes permit, with the refresh token minting fresh access tokens for roughly 90 days or until the grant is revoked. In more mature tradecraft, the actor uses the service principal to register additional backdoor applications, modify mail flow rules, or join devices to the tenant, extending access beyond the original grant.

Why OAuth Consent Phishing Is Different

Most phishing attacks target authentication. The attacker wants the password, the session cookie after MFA, or a refresh token from a reverse proxy. OAuth consent phishing targets the authorization layer instead. The user signs in on a legitimate Microsoft, Google, or Salesforce domain, satisfies every Conditional Access check, and is presented with a consent screen asking for permissions. If they approve, the identity provider issues a valid access token to the attacker’s application. No credentials are stolen. No sign-in is spoofed. The authentication system did what it was designed to do.

This changes the defensive problem in three ways. First, MFA provides no protection because the user completes MFA during the legitimate sign-in that precedes the consent grant. Phishing-resistant authenticators and passkeys are no different. Second, password resets do not revoke OAuth tokens. Refresh tokens remain valid by default for 90 days in Entra ID and can be used to mint new access tokens throughout that window. Third, the resulting access is legitimate by design. The application is using a token the identity provider issued to it, so malicious activity blends with normal API traffic from authorized integrations.

SRA covered one variant of this attack class in March 2025 with Purple Team PSA: Disable Device Code Flow, which demonstrated the technique offensively and provided the Conditional Access controls to block it.

Recent Threat Activity

Three Attack Patterns

The campaigns above fall into three distinct patterns. Each pattern has implications for which detections and controls are most effective.

Pattern 1: Direct consent phishing. The attacker sends a link that leads to an OAuth consent prompt. The user clicks through the prompt and authorizes the application. This is the classic pattern documented in Microsoft’s consent phishing guidance. Tycoon OAuth app impersonation, CoPhish, and OAuth redirection abuse all follow this shape, though each exploits different facets of the OAuth protocol or the identity provider’s UX. OAuth redirection abuse is particularly interesting because it does not even require a successful consent grant. The attacker triggers an intentional OAuth error through an invalid scope and prompt=none, and uses the error redirect path to bounce the victim to attacker-controlled infrastructure for phishing or malware delivery.

Pattern 2: Vishing-to-consent. The attacker uses voice phishing to walk the victim through the consent or authorization code flow in real time. UNC6040’s Salesforce campaign is the definitive example: operators impersonate IT support, guide the victim to the Salesforce Connected Apps setup page, and talk them through authorizing a malicious Data Loader application. The device code phishing variant covered in Purple Team PSA fits here as well, with the attacker generating an 8-character code and vishing the victim into entering it at microsoft.com/devicelogin. ConsentFix is a hybrid of this pattern and ClickFix, where the user is socially engineered into pasting an Azure CLI authorization URL into a phishing page. What unifies these attacks is that the victim is socially engineered through the authorization step in real time by an operator on the other end of a phone call or phishing page.

Pattern 3: OAuth token theft and SaaS-to-SaaS supply chain abuse. The attacker does not phish the victim directly. Instead, they compromise a third-party SaaS vendor and steal the OAuth tokens that vendor holds for its customers’ tenants. UNC6395’s compromise of Salesloft Drift is the textbook case: the attacker stole tokens Drift held for hundreds of customer Salesforce instances and used them to query support case data at scale, harvesting credentials embedded in case content. Midnight Blizzard’s post-access OAuth lateral movement is a related variant at the tenant level: once inside Microsoft’s corporate environment, the attackers used a legacy OAuth application with elevated privilege to create additional backdoor applications and grant them full_access_as_app to Exchange Online. The common thread is that the malicious access rides through tokens the identity provider considers legitimate, and the victim organization may have no relationship with the attacker at all.

Phishing-as-a-Service and the Shift to the Authorization Layer

Phishing-as-a-service lowered the cost of authorization-layer attacks. Operators who once sold only reverse-proxy kits now sell consent-grant and device-code modules, and at least one platform now exists for the sole purpose of running device code phishing at scale. The barrier to entry for stealing an OAuth token is now a Telegram subscription rather than custom tooling.

Device Code Phishing Moves From APT to Commodity

The OAuth 2.0 device authorization grant is designed for input-constrained devices such as smart TVs and IoT hardware. The flow issues a short user code and directs the user to a sign-in page (microsoft.com/devicelogin) to authorize the device. Device code phishing abuses this by having the attacker generate the code, then socially engineering the victim into entering it and completing their own MFA on the real Microsoft page. The victim authorizes the attacker’s session. As with consent phishing, MFA is not bypassed. It is redirected. Phishing-resistant authenticators and passkeys provide no protection because the user completes a legitimate authentication ceremony on genuine infrastructure.

Storm-2372, assessed as Russia-aligned, ran the campaign that brought the technique to wide attention in February 2025, targeting government, NGO, defense, telecom, healthcare, higher education, and energy organizations. Volexity tracked multiple Russia-linked clusters using the same technique against government and defense targets in the same window, including activity that overlaps with APT29. EvilTokens, advertised on Telegram in February 2026 and analyzed by Sekoia in March 2026, is the first popularized turnkey device code phishing-as-a-service. It ships with AI-generated lures, SaaS-themed templates, and post-compromise business email compromise tooling. One campaign linked to the platform compromised more than 340 Microsoft 365 organizations across multiple countries and sectors. Kali365, flagged in an FBI public service announcement in May 2026, is a competing device code PhaaS distributed through Telegram with AI-generated lures, victim-tracking dashboards, and OAuth token capture. It offers both a device-code mode and an AiTM cookie mode in the same kit. After the March 2026 takedown of Tycoon 2FA infrastructure, the operators rebuilt and added a device-code module that impersonates the Microsoft Authentication Broker first-party application.

Over the past year the technique went from a handful of state-aligned operators to a subscription product, and that trajectory points one direction. Expect device code phishing to grow more common and more accessible as kits compete on price and ease of use.

Behavioral Detection and Threat Hunting

The detection logic below spans Microsoft 365 and Salesforce telemetry. Because OAuth consent phishing operates through legitimate authorization flows, most of these behaviors will overlap with normal activity. Hunt and baseline first, then tune for alerting.

Recommendations & Takeaways

The detections above surface activity after the grant has been made. The following controls reduce the attack surface before the user reaches the consent prompt.

• Restrict user consent to low-risk scopes and verified publishers. In Entra ID, configure custom app consent policies rather than relying solely on the Microsoft default. The microsoft-user-default-recommended policy rolled out in July 2025 blocks consent to site and file permissions for non-admin users, but it still permits several high-value permissions and does not protect admin-tier accounts. Configure policies to allow user consent only for apps requesting low-risk permissions with verified publishers, or apps registered within the tenant. In Salesforce, enable API Access Control, which flips the environment from “users may self-authorize any app” to “only admin-approved apps and pre-authorized users connect.” This control directly blocks the technique UNC6040 used in the Data Loader campaign
• Train users to recognize and treat consent prompts as credential prompts. Consent phishing succeeds because the prompt itself is legitimate; there is no spoofed login page for users to spot. Awareness content should teach users to read the requested permissions, check the publisher verification status, and report unexpected consent requests instead of clicking Accept. An unrecognized app asking to read mail or maintain access to data warrants the same suspicion as a password prompt on an unfamiliar domain.
• Route suspicious consent attempts through the admin consent workflow. When consent policies restrict what users can approve, the admin consent workflow in Entra ID gives them a sanctioned path forward instead of a dead end. Users request access, designated reviewers receive the request with the app’s publisher, requested scopes, and requesting user attached, and the security team makes the decision with full context. This converts a risky individual decision into a reviewable one. Requests expire after 30 days by default, and reviewers should be a small, trained group rather than all Global Administrators.
• Inventory and review third-party OAuth integrations continuously. The UNC6395 campaign affected customers of Salesloft Drift who had no way of knowing their vendor’s token vault had been compromised. Treat every OAuth integration as a piece of the attack surface. Maintain an inventory of connected applications, their granted scopes, and the business justification for each. Revoke unused integrations. For high-value tenants, consider periodic forced re-consent to flush dormant refresh tokens.
• Block or restrict OAuth flows that are rarely used legitimately. Device code flow is the clearest example. Purple Team PSA walks through the Conditional Access configuration to block it. Microsoft began rolling out a default policy limiting device code flow in February 2025, but organizations should verify the policy is active and scoped correctly. The same principle applies to legacy authentication flows across every SaaS platform.
• Build response playbooks around OAuth grant revocation. When an account compromise is suspected, password resets and MFA re-enrollment are not sufficient. Incident response procedures need to include revoking refresh tokens, removing consented applications, and revoking service principal credentials. Microsoft Defender for Cloud Apps provides built-in remediation actions for this; Salesforce exposes equivalent controls through the Connected Apps and session management interfaces. Enable Continuous Access Evaluation in Entra ID to reduce token revocation latency from roughly one hour to minutes.