ConsentFix shows browser-native OAuth phishing bypasses MFA

At a glance

What this is: ConsentFix is a browser-native OAuth phishing technique that uses copy-and-paste deception to grant attackers access to Microsoft accounts without passwords or an MFA challenge.

Why it matters: It matters because IAM teams cannot treat phishing resistance as a solved problem if browser session trust, OAuth app trust, and consent handling still let attackers bypass interactive controls.

Context

ConsentFix is a browser-native phishing pattern that turns the browser itself into the attack surface. Instead of stealing a password or forcing a classic login prompt, the lure walks the victim through an OAuth authorization flow and then captures the resulting code or consent path.

For identity teams, the important issue is not just phishing success. It is that first-party app trust, active browser sessions, and consent-based authorization can bypass controls that are built around credential entry and MFA prompts, even when the user is already signed in.

That makes this a governance problem across SaaS app approvals, browser-session trust, and OAuth app scope control, not just a detection problem at the endpoint.

Key questions

Q: What breaks when browser-native OAuth phishing uses a first-party app like Azure CLI?

A: Traditional phishing controls break because they assume the attacker must steal a password, trigger a suspicious login, or use a third-party app that can be blocked. When a first-party client is implicitly trusted, the abuse happens through legitimate OAuth paths that inherit tenant trust and bypass many approval gates.

Q: Why do phishing attacks still succeed even when spam filters and MFA are in place?

A: Phishing succeeds because it targets human judgment and can bypass technical controls through deception, urgency, and credential theft. Spam filters are not perfect, so malicious messages can slip through. MFA reduces risk, but it is not a complete defense if attackers use advanced social engineering or session theft. The practical answer is layered controls, not faith in a single control.

Q: What are the signs that browser-native OAuth abuse is underway?

A: Look for consent events tied to native client apps, logins from account types that should not normally use those apps, and follow-on non-interactive activity that appears immediately after a browser-based sign-in. A consent grant followed by unusual resource access is a stronger warning than an IP anomaly alone.

Q: How should security teams govern OAuth apps that have access to developer systems?

A: Security teams should treat OAuth apps as privileged NHIs and inventory them continuously, not just at approval time. Each app needs an owner, a business justification, a scope review, and a revocation path. The key test is downstream reach, because a single delegated identity can expose source code, secrets, or deployment workflows if it is overprivileged or forgotten.

Technical breakdown

Browser-native OAuth phishing in the consent flow

ConsentFix works by keeping the victim inside the browser and using a copy-and-paste lure to move OAuth material into an attacker-controlled page. The victim is first steered into a legitimate Microsoft login or already-authenticated session, then redirected to a localhost URL that exposes an authorization code. In some OAuth flows, that code is enough to mint a token for apps that cannot safely protect a client secret, which makes the code itself the prize. The attack therefore abuses the browser as the delivery layer, the consent flow as the access path, and the OAuth token exchange as the compromise point.

Practical implication: Treat browser-mediated OAuth consent as a control boundary and monitor it as carefully as direct credential use.

Why first-party app trust changes the access model

The campaign specifically targets Azure CLI because first-party Microsoft applications are implicitly trusted in Entra ID and can bypass many of the restrictions applied to third-party apps. That trust can allow permission requests without the same approval gates, and it changes the governance problem from app reputation to app class. When a platform treats a native client as inherently trusted, an attacker no longer needs to persuade the user to install an unknown app. The abuse happens through a legitimate-looking Microsoft workflow that inherits the platform’s own trust posture.

Practical implication: Review how first-party OAuth apps inherit permissions and whether those assumptions still fit your approval model.

Consent phishing is evolving beyond email and endpoint controls

This technique combines elements of consent phishing, ClickFix-style social engineering, and browser-only execution. The lure is often delivered through search, not email, and the attacker layers conditional loading, IP checks, and synchronized blocking to frustrate analysis. That means many traditional detections miss the campaign because there is no malicious attachment, no obvious malware dropper, and sometimes no suspicious login location at the point of interactive compromise. The result is a phishing path that lives inside ordinary browsing behaviour and is much harder to separate from legitimate user activity.

Practical implication: Extend phishing detection to browser behaviour, search-delivered lures, and consent events, not just inbox and endpoint signals.

Threat narrative

Attacker objective: The attacker wants persistent Microsoft account access through a trusted OAuth connection that bypasses credential and MFA prompts.

1. Entry occurs when a user reaches a malicious or compromised webpage through search and is prompted to follow a copy-and-paste workflow inside the browser.
2. Credential or token access is obtained when the victim completes the Microsoft sign-in path and pastes the localhost URL containing OAuth code material into the attacker page.
3. Escalation happens when the attacker’s Azure CLI instance converts that code into an OAuth connection that grants account access without a password or MFA challenge.
4. Impact is effective control of the victim’s Microsoft account and the ability to act through the trusted app relationship rather than through stolen credentials.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ConsentFix shows that browser trust has become an identity control surface, not just a delivery channel. The attack never leaves the browser context, so controls that assume the malicious step will be visible at the endpoint or in email telemetry are already behind the threat. For identity programmes, that means the security boundary now includes search, session state, and in-browser consent behaviour. The practitioner conclusion is simple: browser-mediated access paths need governance equal to interactive sign-in paths.

First-party app trust is now an attack primitive. Azure CLI is dangerous here not because it is obscure, but because it inherits trust that third-party apps do not get. That assumption was designed for legitimate platform integration, not for adversaries abusing native client privileges to sidestep consent friction. The implication is that platform-native app classes need explicit governance, not inherited innocence.

OAuth consent abuse has moved from a permission problem to a token-broker problem. The campaign proves that the high-value object is not the login event itself but the authorization code and the downstream token exchange. Consent governance that focuses only on app registration or email phishing misses where the actual trust transfer occurs. Practitioners should treat consent events as token issuance decisions, because that is where account compromise is completed.

Browser-native phishing collapses the old separation between user action and security event. The victim performs apparently benign clicks and paste actions inside a trusted browser session, yet those actions produce a durable access grant. That means classic assumptions about “user intent” and “interactive authentication” are no longer sufficient signals of legitimacy. The practitioner takeaway is to validate the app class, the consent scope, and the browser context together.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Browser-native consent abuse is now a governance problem for identity teams. The old model assumed phishing would surface through email, password theft, or suspicious interactive logins. ConsentFix shows that the decisive event can be a browser-side OAuth grant inside a trusted session, which means consent review, app trust policy, and session context belong in the same control plane.

Consent events deserve the same scrutiny as authentication events. If a browser session can mint a durable OAuth connection without a password or MFA challenge, then token issuance is the real control point. Identity programmes should therefore watch for privilege grants, native client usage, and post-consent activity as a single chain, not as isolated logs.

OAuth app governance is becoming a core phishing control. As attackers shift from email lures to search-delivered browser lures, the practical boundary moves to app class, consent scope, and browser behaviour. Teams that still separate phishing defence from SaaS and OAuth governance will miss the path that this campaign exploits.

For practitioners

• Tighten first-party OAuth app governance Inventory which first-party applications are allowed to request sensitive permissions and confirm whether they can be constrained by tenant policy, not just by user choice.
• Monitor browser-native consent events Alert on consent grants that originate from browser sessions rather than approved admin workflows, especially when the app is Microsoft Azure CLI or another native client.
• Separate legitimate admin use from user-driven OAuth abuse Build detection logic around account role, app ID, resource ID, and login pattern so ordinary employee sessions do not look identical to Azure CLI exploitation.
• Review search-delivered phishing exposure Assume the lure may arrive through compromised websites and search results rather than email, and tune web-layer controls accordingly.
• Hunt for unusual post-consent activity Correlate interactive consent events with non-interactive logins, legacy scope use, and unfamiliar resource access immediately after the token grant.

Key takeaways

• ConsentFix is a browser-native phishing technique that defeats the old assumption that MFA breaks the attack chain before account access is granted.
• The campaign matters because the compromise happens through OAuth consent and trusted app behaviour, not through credential theft alone.
• Identity teams need to treat browser context, first-party app trust, and consent governance as part of phishing defence.

Key terms

• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• 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-based phishing: Browser-based phishing is phishing that executes through the web browser rather than the inbox, often using redirects, malicious sites, consent prompts, or extensions. It matters because the browser is where identity, application access, and session state intersect.
• OAuth Authorization Code Flow: An OAuth pattern that exchanges a temporary code for tokens instead of sending tokens directly through the browser redirect. The design reduces exposure during the authentication step and is widely used because it separates the front-channel interaction from token issuance.

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.