ConsentFix shows how OAuth phishing bypasses browser identity controls

At a glance

What this is: ConsentFix is a browser-native OAuth phishing technique that turns a legitimate Microsoft URL into account takeover and API access.

Why it matters: It matters because IAM teams cannot treat browser sign-in as a safe boundary when tokens, consent grants, and first-party apps can bypass normal authentication controls.

By the numbers:

• This year, device code phishing attacks have increased 37x.

👉 Read Push Security's analysis of ConsentFix and browser-native OAuth phishing

Context

ConsentFix is a browser-native account takeover technique that abuses OAuth consent and authorization code handling rather than password theft. The primary identity problem is not just phishing, but the misuse of post-authentication trust in Microsoft Entra and related OAuth flows.

For IAM and NHI programmes, the issue is that access is being granted through a legitimate browser session, then converted into API reach through tokens and app-specific permissions. That means the control boundary has shifted from login success to token issuance, application scope, and downstream consent governance.

Key questions

Q: What breaks when OAuth consent phishing bypasses MFA and passkeys?

A: MFA and passkeys protect the login ceremony, but they do not stop an attacker who can capture an authorization code or consent grant from a legitimate browser session. The broken assumption is that interactive authentication equals safe access. In practice, token issuance, application scope, and consent governance become the real control points.

Q: Why do browser-native OAuth attacks increase the risk for Microsoft 365 environments?

A: They exploit the same browser trust users rely on for Microsoft sign-ins, then pivot into APIs and collaboration services through granted scopes. That makes the risk broader than account takeover alone. It can reach Outlook, Teams, OneDrive, SharePoint, and other connected services through a single compromised token path.

Q: How should security teams reduce the impact of malicious OAuth consent grants?

A: They should restrict which apps and users can complete high-risk consent paths, remove unnecessary Conditional Access exclusions, and review token reuse across app families. The goal is to shrink the blast radius of any single browser interaction so that one successful consent does not become broad platform access.

Q: Who is accountable when an attacker uses a legitimate Microsoft URL to steal tokens?

A: Accountability sits with identity governance, application owners, and security teams together, because the failure spans consent policy, app scope, and monitoring. The relevant question is not only who clicked, but which apps were allowed to exchange a legitimate browser event for durable access.

Technical breakdown

OAuth authorization code abuse in the browser

ConsentFix tricks a signed-in user into copying a legitimate Microsoft URL into a phishing page. That URL carries OAuth authorization code material that the attacker can exchange for tokens, turning a browser interaction into API access without password capture. Because the flow is browser-native, the attacker does not need endpoint compromise to complete the exchange. The technical risk sits in the gap between user interaction and token issuance, especially where localhost redirects, native app flows, or pre-consented application paths are allowed.

Practical implication: restrict which apps can complete OAuth flows and monitor authorization code use against expected application IDs and redirect patterns.

Conditional Access exclusions and first-party app scope

The technique targets Microsoft applications with known Conditional Access exclusions, which weakens the assumption that first-party apps inherit the same protection as interactive sign-ins. Once the attacker obtains a token for a targeted app, the actual permissions are defined by the app's scopes and the victim's rights, not by the original phishing step. That makes the application inventory itself part of the attack surface. FOCI apps increase the blast radius because a token issued for one client can often be exchanged for access to others in the family.

Practical implication: inventory first-party and FOCI apps, then remove unnecessary exclusions and pre-consented paths that expand token reuse.

From token theft to session and refresh token persistence

ConsentFix v3 automates the handoff from captured OAuth material to session and refresh tokens, which creates durable access beyond the initial browser event. That persistence matters because the victim's visible login action is only the entry point, while the attacker continues from the back channel. In practice, the post-authentication chain can evolve into broad Microsoft 365 API access, and with further escalation, into seamless SSO across connected services. This is why browser telemetry and token-issuer telemetry need to be correlated.

Practical implication: correlate browser activity, app IDs, and token issuance logs so that a benign-looking sign-in can still be tied to attacker-controlled follow-on actions.

Threat narrative

Attacker objective: The attacker aims to convert a normal browser sign-in into persistent Microsoft account and API access without triggering MFA or device compliance checks.

1. Entry occurs when the victim is persuaded to paste a legitimate Microsoft URL containing OAuth authorization code material into a phishing page.
2. Credential access occurs when the attacker exchanges the captured OAuth material for session and refresh tokens, then uses those tokens against a targeted Microsoft application.
3. Impact follows when the attacker pivots through token scopes and application permissions to access Outlook, Teams, OneDrive, SharePoint, or other connected services via API.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-native OAuth phishing turns identity controls into after-the-fact evidence. ConsentFix shows that MFA, passkeys, and device compliance are not reliable stopping points when the attacker never needs to win a password prompt in the first place. The governance problem is that authentication telemetry can look legitimate while the token exchange and app consent are already hostile. Practitioners should treat browser session behaviour as part of identity assurance, not as a separate endpoint problem.

OAuth consent governance has become a privilege-management problem, not just an authentication problem. The real control surface is the combination of app registration, granted scopes, Conditional Access exclusions, and token exchange rules. When first-party apps and FOCI clients are involved, access can widen far beyond the initial victim context. IAM teams need to evaluate consent paths the same way PAM teams evaluate standing privilege, because the token can become a delegated privilege container.

ConsentFix exposes an identity blast radius created by family-of-client token reuse. A token for one Microsoft app can be repurposed across related apps without re-authentication, which means the original user action no longer maps cleanly to the final access outcome. That weakens the assumption that app boundaries contain scope. The practitioner takeaway is that application families, not just individual apps, now define the attack surface.

Post-authentication abuse now sits inside the normal path of enterprise collaboration. The technique succeeds because users are trained to trust legitimate Microsoft URLs and browser prompts. That trust becomes a governance blind spot when the same interaction can carry authorization code material and feed attacker-controlled token exchange. Security programmes that only reason about phishing as credential theft are already behind the attack model.

ConsentFix is a named example of browser-mediated token laundering. The attacker launders legitimacy through a real Microsoft sign-in session, then converts that legitimacy into API access and persistence. This is not a broken login screen. It is a failure to govern how trusted browser actions become durable identity power. The field should read this as a control-plane issue, not a user-awareness issue.

From our research:

• This year, device code phishing attacks have increased 37x, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Browser-native token abuse now deserves the same operational attention as endpoint intrusion because attacker workflow and dwell time have collapsed across identity boundaries.

What this signals

ConsentFix strengthens the case for browser-session monitoring as a core identity control, not a niche detection layer. If a user can unintentionally deliver authorization code material through a trusted web page, then the security programme has to observe what happens after authentication, not just whether authentication succeeded. The practical shift is toward app-level telemetry, consent governance, and tighter control of redirect behaviour.

Identity blast radius: when a single browser interaction can unlock multiple Microsoft services through token reuse, the unit of governance is no longer the account alone. Practitioners should evaluate application families, consent surfaces, and exception lists as one combined exposure path. That is where the control model needs to move next.

The lesson for IAM and NHI teams is that token-bearing browser flows are now part of the same control plane as privileged access. This is where resources like The 52 NHI breaches Report help teams compare token abuse patterns with prior credential compromise cases and align detection, offboarding, and review workflows.

For practitioners

• Tighten OAuth app consent paths Review first-party and third-party app registrations, remove unnecessary pre-consented paths, and restrict which users can authorise high-risk clients or family-of-client apps.
• Monitor browser-to-token mismatches Correlate browser session origin, application ID, resource ID, and subsequent API activity so that a legitimate-looking login can still be flagged when follow-on actions diverge.
• Hunt for Conditional Access exclusions Identify apps that can complete OAuth flows outside standard Conditional Access enforcement, then prioritise those clients for tighter access scoping and exception removal.
• Block token exchange from suspicious redirect patterns Detect authorization codes appearing in browser-visible locations, especially localhost redirect flows and copy-paste workflows that should not be used for routine access.
• Treat browser telemetry as identity evidence Use in-browser detections and web-session logging to capture the initial consent event, because the attacker may already be operating through tokens by the time endpoint tools react.

Key takeaways

• ConsentFix shows that OAuth consent phishing can bypass MFA, passkeys, and some Conditional Access controls by abusing legitimate browser sessions.
• The attack matters because token scope, app family reuse, and post-authentication access can turn one interaction into Microsoft 365 API reach.
• Teams should tighten consent paths, reduce exception exposure, and monitor browser-to-token mismatches as identity signals, not endpoint afterthoughts.

Key terms

• OAuth Consent Phishing: OAuth consent phishing is a technique that tricks a user into approving access for a malicious or misused application. The attacker does not need the password if the user grants the app a token or permission set that can be exchanged for API access.
• Authorization Code Grant: The authorization code grant is an OAuth flow that exchanges a temporary code for tokens after user authentication. In abuse cases, the code can be captured from a browser-visible redirect or copied URL and converted into persistent access by an attacker.
• Family Of Client IDs: Family Of Client IDs is a Microsoft mechanism that allows related applications to share token utility across a client family. In abuse scenarios, it can widen the impact of a stolen token because one app's approval may unlock access to others without re-authentication.
• Browser-native Attack: A browser-native attack is an intrusion path that stays inside the web session instead of relying on endpoint compromise. It uses legitimate pages, redirects, prompts, and user interaction to move from trust to token abuse, which makes detection harder for traditional endpoint-centric controls.

Deepen your knowledge

OAuth consent phishing and browser-native token abuse are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with Microsoft identity sprawl or delegated app access, it is a practical place to start.

This post draws on content published by Push Security: Investigating a new criminal toolkit for ConsentFix and browser-based OAuth hijacking. Read the original.