Key Insights
In a September 2025 public service announcement, the FBI's Internet Crime Complaint Center warned that attackers have been targeting prominent victims, their family members, and personal acquaintances since late 2025 using OAuth consent phishing, a technique that produces persistent account access without ever capturing a password.
OAuth consent phishing exploits the OAuth 2.0 authorization flow to trick users into granting a malicious app delegated permissions to read mail, download files, and send messages on their behalf. Because the request appears on the identity provider's genuine sign-in surface, familiar cues like mismatched domains or broken certificates do not appear.
This guide traces the attack from registration through API-level persistence, explains why it sidesteps multi-factor authentication (MFA) and password resets. It also covers the main variants, documented campaigns, detection signals, and a containment sequence. The result is a working framework for finding risky grants, revoking them cleanly, and tightening consent policy before the next lure arrives.
Key Takeaways
Teams need separate playbooks for malicious grants, intercepted codes, and replayed tokens.
Containment must remove authorization and invalidate tokens before normal access resumes.
Prevention works best when administrators review high-impact permissions and block unnecessary device flows.
Audit records must connect the user, app, scopes, token activity, and downstream API actions.
What Is OAuth Consent Phishing?
OAuth consent phishing tricks a user into granting a malicious app delegated access through a legitimate OAuth authorization framework. Unlike password spraying, a single consent grant does not depend on the password and can last until someone revokes it.
Legitimate Consent as the Attack Surface
The provider hosts the sign-in prompt and consent screen, which is why users accept. Attackers add trusted branding: one threat group named its apps after the email provider's own protection services.
Credentials, Consent Grants, and Tokens
Credential phishing campaigns, consent phishing, and token theft require different responses because the victim gives up a different form of access in each attack:
Attribute | Credential Phishing | Consent Phishing | Token Theft |
|---|---|---|---|
What the victim gives up | Username and password | Approval for an app to act on their data | An existing token or session cookie, usually without knowing it |
Where the victim lands | Usually a fake login page | The provider's genuine sign-in and consent page | A proxy page, malware, or a compromised integration |
What the attacker holds | A reusable credential | The attacker's own app receives tokens | A stolen token from another session or app |
What ends the access | A password reset | Disabling the app and removing its grant | Revoking the stolen token or session |
Confusing these attacks causes a familiar failure: a team resets the password and closes the ticket, and the attacker's app keeps its grant regardless.
How OAuth Consent Phishing Works
An attacker registers an app, steers a user to approve it, and converts that approval into tokens that keep working through the API.
Registering the Malicious Application
The attacker registers an app branded like a popular product, points its redirect uniform resource identifier (URI) at their own infrastructure, and requests mail, file, and contact permissions. At this stage the user has approved nothing and the attacker holds no token. Consent policies and risk-based step-up consent, which sends requests from newly registered, unverified apps to an administrator, stop many of these apps before a user can approve them.
Delivering the Authorization Request
The lure, often an email link, opens the provider's real authorization endpoint with the attacker's app ID and scopes. Others come from callers posing as IT support or code injected into a trusted site. Because the provider hosts the page, the usual cues of a wrong domain or broken certificate are absent, leaving the app name and permission list as the main clues. Admin-only consent prevents users from approving the request.
Granting Scopes and Exchanging the Code
Once the user clicks Accept, delegated permissions let the app act as that user within the approved scopes. The attacker's server receives an authorization code at its redirect URI and swaps it for access and refresh tokens. The offline-access permission, shown as "Maintain access to data you have given it access to," produces that refresh token, and one compromised admin's approval covers every user in the tenant. Consent policies and blocking high-impact scopes for user consent stop the grant.
Maintaining Access Through APIs
If a finance employee approves an "invoice viewer" requesting permission to read mail, send mail, read files, and maintain access, the attacker's server can search the mailbox for payment threads, download invoices from cloud storage, and send convincing messages to vendors as the employee. Every call goes through an API using the app's tokens, so the attacker never signs in interactively. Grant reviews, token revocation, and API-activity detection limit the damage after approval. Abnormal's behavioral AI is designed to help flag this kind of post-grant activity, such as an unusual spike in outbound mail or a new mailbox rule the employee never created.
Why OAuth Consent Phishing Can Bypass MFA
MFA confirms who is signing in. The consent prompt asks what an app may do with that person's data. The user passes multi-factor authentication controls before the consent prompt appears because the provider must first identify the user. No MFA method evaluates the later authorization decision, so a genuine sign-in can still end with a malicious app receiving approved access.
Authentication Before Authorization
Authentication establishes the user's identity. Authorization defines what the approved app can read, change, or send. Consent phishing exploits the second decision after the user has completed the first.
Persistent Access After Password Changes
The FBI consent phishing advisory states that a password change does not remediate the attack. The grant sits outside the credential, so the app keeps using its refresh token to get new access tokens after a password reset. That access continues until the relevant grant and tokens are revoked.
5 Common Types of OAuth Consent Phishing and Adjacent Attacks
The variants differ in how the attacker obtains authorization or tokens: by winning a consent decision, intercepting a fresh code, or reusing an existing token.
1. Classic Illicit Consent Grants
Classic illicit consent grants rely on an attacker-registered app and a phishing link. A consent event for an unfamiliar app provides the clearest signal, and because the grant and any refresh token issued under it persist, responders must disable the app and remove the grant.
2. Device-Code Phishing
Device-code phishing abuses the device authorization grant, which lets devices without a keyboard or browser sign in with a code that users enter elsewhere. Attackers start the flow and send the victim the code, often framing it as a verification step. When the victim completes a normal sign-in and MFA prompt, the flow sends the resulting tokens to the attacker's session. Blocking the flow wherever users do not need it interrupts the attack.
3. Authorization-Code and Redirect Abuse
Authorization-code and redirect abuse lets attackers divert a code that the authorization server has just issued for a legitimate client. The OAuth 2.0 Security Best Current Practice (RFC 9700) describes open redirectors inside redirect patterns that a legitimate client registered: the manipulated address still matches the pattern, so the authorization server delivers codes or tokens to attackers. Suspicious redirect URI registrations are one signal; strict redirect URI validation prevents the abuse.
Newer campaigns ask targets to copy and paste a full URL or "verification code" after a genuine login. That information may carry the authorization code from the live flow.
4. Token Theft and Replay
Token theft bypasses consent entirely. Adversary-in-the-middle proxy attacks, malware, or a breached integration capture existing tokens or cookies for replay, so no consent event appears. Mail or file API access without a preceding interactive sign-in suggests a stolen token; here, responders revoke the token or session because there is no attacker app to disable.
5. SaaS-to-SaaS Integration Abuse
Connected software-as-a-service (SaaS) integrations extend OAuth risk across platforms, whether access starts with a consent grant or a stolen token. One compromised integration can reach every platform it connects to, and because that activity looks like normal traffic, responders revoke every token it holds.
Real-World Examples of OAuth Consent Phishing and Its Impact
Documented incidents show how malicious grants and connected SaaS apps create persistent, damaging access.
Malicious Apps for Email Access and Persistence
Attackers who have already compromised accounts through password spraying attacks or phishing can create OAuth apps with mail-sending and mail-reading permissions for mass phishing and business email compromise (BEC): post-compromise app abuse rather than consent phishing. These apps often request the same mail-read and mail-send scopes a legitimate add-in would use, so reviewing granted permissions matters as much as reviewing the sign-in.
Device-Code Campaigns Against High-Value Targets
A suspected Russia-aligned actor sent device-code lures to government, nongovernmental organizations, defense, and energy targets. In another campaign, attackers set up short-lived servers on automation platforms that repeatedly checked whether victims had entered the code, then set inbox rules.
Connected-App Abuse Across SaaS Platforms
An FBI FLASH alert on SaaS described callers talking victims into authorizing a modified data-loading tool as a connected app before extortion. The same advisory separately covered a different campaign: stolen tokens from a third-party sales integration used to pull customer data; vendors then revoked every active token.
How to Detect OAuth Consent Phishing
Defenders detect OAuth consent phishing by connecting the lure, consent event, app identity, token issuance, and API activity.
Consent and Application Signals
In practice, a single signal can be benign. An unverified multitenant app requesting mail access that several users approved within a short period deserves a closer look than any one fact alone.
Consent signals include:
Unfamiliar Apps: A new, unverified multitenant app requests more than basic sign-in.
Suspicious Names: The display name is misspelled, bland, or hacker-sounding.
Broad Consent: The grant applies to every user in the organization, not just the person who clicked.
High-Impact Scopes: The app holds mail, file, or "root" permissions spanning a whole resource.
Clustered Approvals: Many users approve one unknown app.
Taken together, these signals help distinguish a risky grant from an ordinary business integration.
Token and API Signals
In the invoice-viewer case, a consent event records the employee approving the app, refresh-token issuance follows, and mail API calls begin without an interactive sign-in. A new inbox forwarding rule or a new app secret might follow. The app ID, granting user, scopes, and timestamp tie these records together across logs. Abnormal's behavioral AI can help tie these signals together automatically, connecting the consent event, token issuance, and later mailbox activity instead of piecing the logs together by hand.
Identity-Platform Audit Evidence
Useful records include consent-to-application events carrying the consent type, permissions, and admin-consent flag; token authorization logs with app ID and scopes; and app credential-change events. Organizations must enable mailbox and activity auditing before an attack, since licensing determines retention.
User-Visible Warning Signs
Users can spot broad mail or file permissions for a simple tool, an unverified publisher or missing logo, "Maintain access" wording, and unrequested device codes. That wording appears on many consent screens, so the scopes listed beside it reveal more.
How to Prevent OAuth Consent Phishing
Prevention takes app approval away from individual users or narrows it to low-risk apps.
User Consent and Admin Approval Policies
Administrators can block user consent, allow it only for verified publishers requesting low-impact permissions, or allow it broadly. A CISA admin consent workflow routes blocked requests to reviewers.
Publisher, Scope, and App Access Controls
Publisher verification confirms who registered an app, not whether it is safe. Administrators can classify a short list of permissions as low impact, letting users approve only those, and route high-impact scopes such as mail and file access to admin review. Allowlists limit access to approved apps.
Device-Code and Workload Controls
Blocking the device-code flow for users who do not need it reduces risk, but workload identities require separate controls. User-scoped access policies do not stop a service principal, the app's own directory identity, from making calls, so workload-identity policies and credential monitoring cover that gap. On some platforms those policies cover only single-tenant apps. Many consent-phishing apps are multitenant, which leaves this gap uncovered.
Identity-Platform Policy Differences
One enterprise directory platform manages sign-in and app consent for an organization's directory. Its risk-based step-up consent is on by default, but it works only while user consent remains enabled. One productivity-suite platform bundles mail, documents, and storage with its own app-access controls. By default, its users can reach third-party apps. Unverified apps requesting sensitive scopes face additional limits.
Administrators on the productivity-suite platform can mark apps as trusted, specific data, limited, or blocked; a block overrides allowlisting. Marking mail or storage as restricted revokes existing tokens held by untrusted apps, and administrators can choose to trust internal apps. On the directory platform, removing user-consented grants and revoking refresh tokens are separate scripted actions, not portal actions; the productivity-suite platform revokes access per app.
User Education for Legitimate-Looking Prompts
Domain-checking lessons do little here because the domain is real. Better lessons explain common permissions plainly and treat an unexpected device code or app-approval call as a reason to stop.
Standards and Security Baselines for OAuth Consent
Standards call for reviewed, minimal, administrator-controlled consent.
OAuth Security Principles
The original OAuth 2.0 standard (RFC 6749) has the resource owner review the client and requested scope before approving. RFC 9700 says token privileges should stay minimal and refresh tokens should follow a risk decision, with public clients' tokens bound to the receiving client or rotated on each use. The OAuth Device Authorization Grant (RFC 8628) tells services to warn users that they are authorizing a device and to confirm it is in their possession.
Identity and Cloud Governance Baselines
National Institute of Standards and Technology (NIST) NIST federation guidance separates authorization to one resource from authorization to another and calls for a runtime decision when a relying party is not allowlisted. Threat frameworks distinguish consent phishing, replayed tokens, and session-cookie theft because each leaves different evidence. A CISA cloud security directive limits covered federal agencies' app registration to administrators, restricts user consent, and requires an admin consent workflow.
How to Respond to a Malicious Consent Grant
The response removes the app's authorization first, then investigates downstream activity and hardens the environment.
1. Disable the Application and Removing Grants
Responders can use this app-first containment sequence:
Responders disable the invoice viewer so it cannot obtain new tokens or accept new sign-ins and consents. The team exports audit evidence and the full grant list at the same time.
They revoke its delegated permissions and role assignments.
They delete the app object after the investigation.
The team reviews the tenant's other third-party grants.
Removing the grant ends the app's authorization, but responders must separately handle tokens already in circulation.
2. Revoke Tokens and Active Sessions
Responders revoke refresh tokens and session cookies for every consenting user, which forces each of them to sign in again everywhere, creating expected disruption during containment. Session cookies matter most in the token-theft variant, where no attacker app exists. Access tokens already in circulation can remain valid until they expire, so responders monitor API activity afterward.
3. Investigate Downstream Activity
Check whether consent was per-user or tenant-wide to identify which accounts need revocation. For instance, grant-window API activity shows what the app read or sent, and forwarding rules need a separate check.
To do this, pull the consent-grant record to confirm its scope, then query mail, file, and admin audit logs filtered by the app ID across the grant window to reconstruct what the app touched. Review each affected mailbox for new forwarding rules, inbox rules, and app-password creations, since those often outlive the grant itself.
4. Recover and Harden the Environment
Once tokens are revoked and the account shows no residual rules or secrets, restore the employee through a fresh sign-in with MFA re-enrolled where needed. Then harden the tenant by moving consent for high-impact scopes to admin approval, scheduling recurring reviews of third-party grants, and confirming mailbox and activity auditing are on.
You should also convert indicators from this incident, such as the app's display name pattern, redirect URI, or scope combination, into standing detection rules so the next attempt surfaces earlier.
Safer Authorization Starts with Better Consent
Signing in and approving an app are separate security decisions. Organizations that keep app approval administrator-owned, tightly scoped, logged, and revocable can interrupt many malicious grants before the first token is issued. Blocking unnecessary device flows and maintaining a tested revocation process limit the remaining variants. A useful measure of readiness is whether defenders can identify every app holding mail access and remove one quickly.
Abnormal's behavioral AI extends this discipline to the inbox. By modeling normal mailbox and identity behavior for each employee, it is designed to help surface the account and app activity that follows a bad consent decision, from a new forwarding rule to an unusual mail-sending pattern.
Abnormal was also recently named a Customers' Choice in the 2026 Gartner® Peer Insights™ Voice of the Customer for Email Security, the only platform to do so for three years in a row. Book a demo to see how it can help surface the account and app activity that follows a risky OAuth approval.
Frequently Asked Questions
Can Removing an OAuth App Delete Data It Already Accessed?
No. Removal stops future access, but downloaded or forwarded data cannot be recalled. Teams should treat that data as exposed, assess its contents, and complete any required notification.
Does Publisher Verification Prove an OAuth App Is Safe?
No. Verification confirms the publisher's identity through a partner program, but it does not imply quality or compliance. Reviewers still need to assess the app's requested permissions and business need.
Are Internal OAuth Apps Automatically Trustworthy?
No. Internal apps can be over-permissioned or compromised. Ownership does not replace least-privilege review, and organizations benefit from periodically reviewing internal app permissions and removing access that no longer has a business use.