TL;DR: ConsentFix combines ClickFix-style social engineering with OAuth consent phishing to hijack Microsoft accounts by stealing authorization codes in the browser, bypassing passwords, MFA, and even passkeys, according to Push Security. The real issue is that identity controls built around authentication events do not protect the consent and token exchange path.
At a glance
What this is: ConsentFix is a browser-native OAuth consent phishing technique that hijacks Microsoft accounts by stealing authorization codes and completing the authorization handshake on an attacker-controlled device.
Why it matters: IAM and NHI teams need to treat consent, token exchange and browser telemetry as first-class controls, because strong authentication alone does not stop delegated access abuse.
Context
ConsentFix sits in the gap between user authentication and delegated authorization. The attacker does not need to break passwords, MFA or passkeys if they can steal the OAuth authorization code and finish the flow on another device.
For identity teams, the lesson is that browser-native abuse can turn a legitimate sign-in into a compromise without touching the usual authentication boundary. That shifts the control problem from login assurance to consent governance, logging coverage and browser-side detection.
Key questions
Q: What breaks when OAuth consent phishing happens inside the browser instead of at login?
A: Browser-native OAuth phishing breaks the assumption that authentication controls protect the whole identity transaction. The user may pass MFA or use passkeys, yet the attacker still wins by stealing the authorization code after login and redeeming it elsewhere. That shifts defence toward browser inspection, consent governance, and token-handling visibility, not just stronger sign-in methods.
Q: Why do pre-consented first-party apps increase the risk of OAuth-based account takeover?
A: Pre-consented apps reduce the friction that would normally force an admin approval step, so the attacker has fewer barriers to converting a stolen code into access. When those apps also sit behind logging gaps or Conditional Access exclusions, the abuse path becomes both easier to complete and harder to see. The problem is not the app alone, but the trust it inherits.
Q: How can security teams tell whether browser telemetry is covering consent phishing properly?
A: Look for visibility into the full browser interaction, including page load behavior, copy-paste activity, redirect chains and the handoff from login page to local callback. If your detections only start after a token exists, you are too late for browser-native abuse. The goal is to observe the authorization flow while it is still in progress.
Q: What is the difference between sign-in security and consent governance in Microsoft environments?
A: Sign-in security validates who the user is, while consent governance controls what the authenticated session is allowed to authorize. ConsentFix shows that a strong sign-in can still lead to compromise if delegated access, scopes and app trust are not governed separately. Identity teams need both layers, because one does not substitute for the other.
Technical breakdown
OAuth authorization codes as the control point
OAuth authorization codes are short-lived values used to complete an authorization handshake between a user, an identity provider and a client application. In ConsentFix, the victim is induced to paste the code into a phishing page, and the attacker redeems it on another device. The important detail is that the code is not a password or an MFA factor. It is proof that the browser session already approved access, which makes the browser the real trust boundary.
Practical implication: monitor where authorization codes are created, displayed and forwarded, not just where users authenticate.
Why default Microsoft controls miss first-party app abuse
The campaign targets first-party Microsoft applications that are pre-consented in every tenant, which narrows the opportunities for traditional app restrictions to block the flow. The article also notes use of legacy scopes and Conditional Access exclusions, which means the attack can sit outside the logging and policy assumptions many teams rely on. This is not a generic OAuth abuse problem. It is a control-path problem created by privileged defaults, scope selection and policy blind spots.
Practical implication: review first-party app permissions, legacy scope exposure and Conditional Access exclusions as a single governance surface.
Browser-native attacks need browser-native telemetry
ConsentFix runs entirely in the browser context, so endpoint-centric controls and IoC-driven detections have limited value if they only see the aftermath. Push Security describes using deep browser telemetry to observe page loading, user interaction and suspicious completion patterns in real time. That matters because the malicious act is the interaction itself, not a later malware drop or token file on disk. Detection has to inspect the web session while it is still active.
Practical implication: add browser-layer detection and response to identity monitoring so consent phishing can be interrupted mid-session.
Threat narrative
Attacker objective: The attacker wants to turn a legitimate browser consent flow into usable access tokens that let them control Microsoft account-linked applications.
- Entry begins with a compromised website or phishing page that serves a ClickFix-style lure and asks the user to paste a URL or sign in.
- Credential capture occurs when the victim completes a legitimate Microsoft login and receives an OAuth authorization code in the browser.
- Escalation happens when the attacker redeems that code on their own device, obtaining access tokens or refresh tokens for the targeted application.
- Impact is account takeover and delegated access abuse inside Microsoft environments, with detection complicated by pre-consented apps and logging blind spots.
Breaches seen in the wild
- 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.
- Cyberhaven Chrome extension breach 2024: A phished OAuth consent gave attackers Chrome Web Store publishing rights and a malicious Cyberhaven extension update reached about 400,000 users.
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
Consent phishing now operates as a browser control problem, not just an identity problem. ConsentFix works because the trust decision is made inside the browser session and then completed outside the user’s device. Passwords, MFA and passkeys are all bypassed because the attacker never needs to win the authentication contest. For practitioners, the key shift is to treat the browser as part of the identity perimeter, not merely the presentation layer.
Delegated authorization has become the weaker link in Microsoft account security. The article shows that pre-consented first-party apps, legacy scopes and Conditional Access exclusions can create a path that sits outside the assumptions of standard sign-in controls. That is a governance failure, not just a detection gap. Identity programmes need to understand that consent and token redemption can be abused even when authentication policy looks strong.
Browser-native phishing should be analysed as an identity attack surface in its own right. The attack succeeds without malware on disk, which means endpoint-only thinking leaves the real abuse path under-observed. This is where browser telemetry becomes identity telemetry. The practical conclusion is that teams should treat browser events, app consent and token issuance as one chain of control.
ConsentFix exposes an identity boundary mismatch between authentication events and authorization events. The control set was designed for logins that end at access, but this attack uses access approval itself as the exploit. That means the hard problem is not proving the user signed in, but proving the resulting authorization was expected, scoped and observable. Practitioners should re-evaluate whether their identity governance model still assumes authentication is the security event that matters most.
OAuth consent phishing is moving from opportunistic abuse to repeatable tradecraft. The article describes a fast community response, rapid iteration and a campaign style that is easy for both red teams and criminals to reuse. That is the hallmark of a technique that will outlive any single payload. Security teams should expect ConsentFix-style patterns to become part of the normal browser-based attack set.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Consent boundary drift: teams that still frame OAuth abuse as an authentication problem will miss the place where the compromise actually happens. The browser session approves access, the attacker redeems it elsewhere, and the identity stack often records the event too late to matter.
Browser telemetry is becoming identity telemetry. That shift matters because modern phishing can unfold entirely before a traditional security stack sees a token, a process spawn or a malware artifact. Identity programmes should align browser monitoring, consent review and token governance as one operating model.
For practitioners
- Tighten first-party app governance Review Microsoft first-party applications, pre-consent settings and scope exposure together so that default trust does not silently expand the attack surface.
- Enable browser-layer detection Use browser telemetry to spot pasted URLs, suspicious local redirect behavior and unusual consent completion patterns before token issuance finishes.
- Harden Conditional Access exclusions Audit exclusions for CLI tools and other vulnerable clients, then remove any exception that creates an alternate authorization path for phishing.
- Turn on deprecated OAuth logging Enable AADGraphActivityLogs and hunt for the application IDs and resource IDs associated with the vulnerable flows described in the article.
- Restrict authorized users for exposed service principals Create service principals for vulnerable apps only where needed, then limit who can access them to reduce the number of accounts exposed to this technique.
Key takeaways
- ConsentFix shows that browser-native OAuth abuse can bypass passwords, MFA and passkeys because the exploit lives in the authorization flow, not the login flow.
- The article points to pre-consented first-party apps, legacy scopes and Conditional Access exclusions as the conditions that make the technique viable and hard to detect.
- Teams that want to limit this attack need visibility into browser activity, consent events and token issuance, not just sign-in success or failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack steals OAuth authorization codes and token material through browser-mediated leakage. |
| NHI-04 — Insecure Authentication | The technique bypasses normal sign-in assurance by abusing the authorization flow after login. | |
| NHI-10 — Human Use of NHI | A human is manipulated into handling machine authorization material, creating the abuse path. | |
| Recommendation — Treat leaked OAuth codes as compromised secrets and revoke the resulting session immediately. Separate authentication assurance from consent governance so code theft cannot complete access on another device. Remove user workflows that ask people to copy or relay authorization codes by hand. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The token exchange depends on abusing a trusted authorization sequence and redirect handling. |
| Recommendation — Validate OAuth token issuance paths and restrict trust in redirect-based credential handoffs. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about delegated access that remains authorized after the sign-in event. |
| Recommendation — Review entitlements and authorization paths separately from user authentication outcomes. | ||
Key terms
- 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.
- 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.
- Browser-native Attack: A browser-native attack is an attack that runs through normal browser behavior instead of obvious malware. It uses web pages, scripts, extensions, session cookies, or browser APIs to steal data, hijack sessions, or trigger actions. Because it blends into legitimate browsing, detection often depends on identity, session, and content controls.
- Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
Deepen your knowledge
NHI governance, identity lifecycle, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org