ConsentFix shows browser-native OAuth phishing bypasses MFA

At a glance

What this is: ConsentFix is a browser-native phishing technique that uses OAuth consent abuse plus copy-and-paste deception to hijack Microsoft accounts.

Why it matters: It matters because IAM teams must treat browser-mediated consent flows, first-party app trust, and session state as part of identity attack surface, not just passwords and MFA.

By the numbers:

• 4 in 5 ClickFix attacks intercepted by Push came via Google Search.

👉 Read Push Security's analysis of the ConsentFix browser-native phishing attack

Context

ConsentFix is a browser-native phishing pattern that turns OAuth consent abuse into a copy-and-paste trap. The identity problem is not just whether a user can be tricked, but whether a browser session can be converted into trusted authorisation without a password prompt or an MFA event.

For IAM and security teams, this shifts attention from login hardness to consent-path governance. First-party app trust, active sessions, and browser-mediated redirects can all become abuse paths even when phishing-resistant authentication is in place.

Key questions

Q: What breaks when OAuth phishing happens after a user already authenticated?

A: Traditional MFA and password protection stop helping once the attacker can operate inside an already authenticated browser session. The real control failure shifts to consent governance, redirect validation, and monitoring for suspicious OAuth grants. Teams need to treat post-login authorisation as a separate attack surface, not as a safe continuation of the sign-in flow.

Q: Why do browser-native phishing attacks complicate IAM controls?

A: They move the abuse path away from credential prompts and into the browser session, where legitimate logins can be repurposed into attacker-approved access. That weakens controls built around detecting failed logins, suspicious IPs, or MFA challenges. IAM teams need visibility into consent grants, session behaviour, and downstream token use, not only authentication outcomes.

Q: How can security teams reduce risk from first-party OAuth app abuse?

A: They should inventory high-trust first-party clients, restrict which scopes those apps can request, and review whether those permissions are still necessary. First-party status should not be treated as a blanket approval signal. The practical goal is to prevent trusted platform apps from becoming hidden consent channels for attacker access.

Q: Who should investigate suspicious OAuth consent events?

A: Identity, IAM, and cloud security teams should all review them because consent abuse can create account control, directory visibility, and downstream resource access in one chain. Investigators should compare the consent event with later non-interactive sign-ins and resource access patterns. A single suspicious grant can be the starting point for broader account compromise.

Technical breakdown

OAuth authorization code flow and consent abuse

OAuth authorization code flow is designed to let an app exchange a user-granted code for a token. In ConsentFix, the user is tricked into pasting a localhost URL that contains OAuth key material into a phishing page, which converts the browser interaction into an attacker-controlled consent event. The key weakness is not token cryptography itself, but the trust placed in a user-supplied redirect artifact. When the target app is a trusted first-party client, the abuse path becomes easier to hide inside normal browser behaviour.

Practical implication: review where your tenant trusts first-party OAuth clients and log consent-grant events separately from normal sign-in activity.

Why browser-native phishing bypasses MFA and passkeys

This attack stays inside the browser context and never forces the user through a fake credential prompt. If the user already has an active Microsoft session, the attack can proceed without any new login, which means MFA and passkeys do not get a chance to intervene. That makes the control failure structural rather than tactical: the protection is attached to authentication, while the abuse happens after authentication in the consent and redirect layer.

Practical implication: monitor browser-session-driven authorisation flows as a separate control surface, not as a solved authentication problem.

Why first-party app trust changes the risk model

Azure CLI is treated as a trusted Microsoft application in Entra ID, so the attacker does not need to rely on a suspicious third-party OAuth app. That matters because first-party clients often have broader default trust, fewer block options, and access to legacy or undocumented scopes. The result is a governance blind spot: a trusted client can become the delivery mechanism for an untrusted consent event, with little friction from tenant policy.

Practical implication: inventory first-party OAuth apps with privileged scopes and review whether their trust posture is actually justified.

Threat narrative

Attacker objective: The attacker aims to gain durable Microsoft account access by turning a legitimate browser session into an OAuth-authorised foothold.

1. Entry occurs when the victim reaches a compromised or malicious site through search and is conditioned by a fake verification step.
2. Credential access happens when the user signs in through a legitimate Microsoft flow and copies a localhost authorization URL containing the OAuth code into the attacker page.
3. Impact follows when the attacker exchanges the obtained consent path for effective Microsoft account control through Azure CLI without needing the password or MFA challenge.

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

ConsentFix proves that browser trust is now part of identity trust. The attack does not need to break passwords, MFA, or passkeys if it can convert a legitimate browser session into an attacker-approved consent event. That makes browser-mediated authorisation a governance boundary, not a user-experience detail. Practitioners should treat the browser as an identity enforcement point, not only a presentation layer.

First-party OAuth trust creates a hidden privilege pathway. Azure CLI is more than a client label in this pattern. It is a trusted application path that can inherit permissions and reduce the friction normally used to stop third-party consent abuse. The governance lesson is that default trust in a platform-owned app can become a policy bypass if scope review is weak. Security teams should re-examine which trusted clients are allowed to request powerful scopes.

ConsentFix is a browser-native consent capture pattern, not a conventional phishing kit. The attack wins after authentication, in the redirect and consent layer, which means authentication-centric controls alone will miss it. That distinction matters for Entra ID, SSO, and browser security programmes that still assume the risky event is the login form. Practitioners need to think in terms of authorisation-path abuse, not just credential theft.

OAuth consent review is becoming a frontline identity control for human accounts. The same governance model that has long been used for service-to-service permissions now needs to be applied more aggressively to interactive user accounts and first-party clients. This is where NHI and human identity programmes start to converge: delegated access can be abused even when the subject is a person. IAM teams should expand review logic to consent grants, not only sign-ins.

Named concept: browser-native consent hijacking. ConsentFix is a clear example of a browser-native consent hijacking pattern, where a user’s authenticated session is converted into an attacker-controlled OAuth grant through copy-and-paste deception. The implication is that identity teams must model abuse inside the browser session lifecycle, not just around login events. That breaks the old assumption that successful authentication means the identity event is safe.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
• That visibility gap matters here because browser-native consent abuse turns trusted app paths into hidden identity channels, so readers should also review the Top 10 NHI Issues for the broader control model.

What this signals

Browser-native consent hijacking is the right concept to watch as phishing keeps moving past passwords and into post-authentication authorisation. The practical signal is that identity teams must monitor consent grants, trusted client behaviour, and browser-session artefacts with the same seriousness they already apply to authentication events.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to our State of Non-Human Identity Security research, the governance lesson is larger than one phishing kit. Teams should expect attacker tradecraft to keep exploiting trusted app paths until consent review becomes a routine control.

Programmes aligned to OWASP Top 10 for Agentic Applications 2026 and browser security should also account for delegated access abuse, because the identity boundary now extends beyond login to the grant itself.

For practitioners

• Separate consent logging from sign-in logging Create detections for OAuth grant events, new app consents, and scope changes so they are reviewed independently from interactive logins and MFA successes.
• Restrict trust in first-party OAuth clients Review which first-party applications can request high-value permissions, and require explicit approval for scopes that enable tenant-wide or directory-wide access.
• Hunt for browser-native lures Add detections for copy-and-paste redirect patterns, localhost authorization URLs, and search-delivered phishing pages that only activate for targeted domains.
• Validate post-consent activity immediately Correlate consent events with subsequent non-interactive logins, unusual resource access, and legacy scope usage to find abuse that begins after the initial browser interaction.

Key takeaways

• ConsentFix shows that a user can be compromised through a legitimate browser session without defeating password or MFA controls.
• The attack underscores a structural visibility gap in OAuth trust, especially where first-party apps and post-login consent flows are involved.
• Security teams should treat consent events, trusted clients, and browser-session artefacts as core identity controls, not secondary telemetry.

Key terms

• OAuth consent phishing: A phishing method that tricks a user into granting an application access through the normal consent flow instead of stealing a password directly. The danger is that the resulting token or grant can look legitimate, which makes detection and revocation harder than with failed login attempts.
• First-party OAuth client: An application published and trusted by the platform owner, often with broader default permissions and fewer tenant-side restrictions than third-party apps. In identity governance, these clients can become hidden privilege channels if their scopes, trust level, and usage are not continuously reviewed.
• Browser-native phishing: A phishing technique that completes its social engineering and authorisation steps entirely in the browser, often without touching the endpoint in an obvious way. This reduces the value of endpoint-centric detection and shifts the control burden toward session, consent, and web-layer monitoring.
• Consent grant: The authorisation event in which a user or administrator allows an application to access protected resources on their behalf. A consent grant can create durable access even when the original login was legitimate, so it must be treated as an identity event with its own review and alerting requirements.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: ConsentFix and browser-native OAuth phishing techniques. Read the original.