ConsentFix exposes browser-native OAuth gaps in Microsoft account security

At a glance

What this is: ConsentFix is a browser-native OAuth hijacking technique that uses copy-pasted authorization codes to take over Microsoft accounts while sidestepping traditional identity-layer defences.

Why it matters: It matters because IAM teams have to protect the browser, the consent flow, and the logging surface, not just login screens, across Microsoft estates and adjacent NHI governance.

By the numbers:

• In total, there are 11 apps vulnerable to ConsentFix that also have known Conditional Access exclusions.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and a further 47% having only partial visibility.

👉 Read Push Security's analysis of the ConsentFix OAuth hijacking technique

Context

ConsentFix shows how OAuth consent phishing has moved beyond a simple login scam. The attack uses a legitimate Microsoft sign-in flow, but the victim is manipulated into copying an authorization code into a phishing page, which lets the attacker complete the handshake on a separate device.

For Microsoft environments, that creates an identity gap that sits between authentication and authorization. Passwords, MFA, and even passkeys can all be present and still fail to stop the abuse, because the malicious action happens after the user is already inside a normal browser session.

That is a familiar pattern in NHI governance as well: controls often focus on the moment a credential is issued, not on how it is later reused, redirected, or exchanged. The article's starting position is typical for modern browser-native abuse, where the weak point is the workflow around trust, not the login ceremony itself.

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 Microsoft first-party apps create extra risk in consent phishing attacks?

A: First-party apps can be pre-consented in every tenant and may not be restrictable in the same way as third-party apps. When attackers target those apps, the usual consent policy and approval controls lose much of their value. Teams need to treat app exceptions, scopes, and Conditional Access exclusions as live attack surface, not static configuration.

Q: How do security teams know if OAuth abuse is slipping past detection?

A: The warning signs are gaps between user activity and identity telemetry. If sign-in logs look normal but browser behaviour shows unusual copy-paste, redirect, or code transfer patterns, the attack may already be in progress. Monitoring must include browser events, deprecated identity logs, and the specific application and resource IDs associated with suspicious consent activity.

Q: Who is accountable when OAuth consent abuse succeeds in a Microsoft environment?

A: Accountability sits with the identity, SaaS, and browser control owners together, because the attack crosses all three domains. If pre-consented apps, logging gaps, or Conditional Access exclusions were left unreviewed, that is a governance failure rather than a user mistake. The right response is to assign ownership for consent policy, detection engineering, and exception management.

Technical breakdown

OAuth authorization code theft in the browser

ConsentFix abuses the OAuth authorization code flow by moving the code out of the legitimate callback context and into a phishing page. The victim is not asked for a password or a second factor. Instead, they are tricked into pasting a code that the attacker can redeem against the target application. Because the attacker completes the exchange on their own device, the control point is not the login screen but the trust boundary around the authorization code itself. That makes browser telemetry and page-behaviour inspection more relevant than endpoint-only or IdP-only monitoring.

Practical implication: monitor the browser as a security control surface, not just the identity provider.

Why first-party Microsoft apps are harder to block

The campaign specifically targeted first-party Microsoft applications that are pre-consented in every tenant and cannot be restricted like ordinary third-party apps. That matters because the normal assumption is that suspicious app consent can be contained by app policy and admin approval. In this case, the app is already trusted by design, and some scopes also sit outside default logging or ride through Conditional Access exclusions. The result is a control blind spot where the abuse path stays inside otherwise legitimate Microsoft behaviour.

Practical implication: review first-party app permissions and Conditional Access exclusions as part of OAuth governance.

Legacy scopes and logging gaps in Microsoft identity monitoring

ConsentFix also depends on scope choices that evade routine detection, including legacy telemetry gaps and scopes that are not always logged by default. In practice, that means the attacker can generate a valid token flow without leaving the artifacts many teams expect to see in standard identity logs. The article's key lesson is that detection engineering for OAuth abuse must include application IDs, resource IDs, and browser-side behavioural indicators, not only sign-in events. Without that, a successful grant can look like normal user activity.

Practical implication: enable deprecated AADGraphActivityLogs and hunt for the specific application and resource IDs involved.

Threat narrative

Attacker objective: The attacker wants to bypass authentication controls and obtain usable OAuth tokens for Microsoft account access.

1. Entry occurs when the victim is pushed through a fake human-verification step and asked to paste a Microsoft authorization URL into the phishing page.
2. Credential access happens when the attacker receives the OAuth authorization code and redeems it against the targeted Microsoft application on their own device.
3. Impact follows when the attacker gains tokens for the targeted app and can operate inside the Microsoft environment as the victim.

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 is a browser-native identity attack, not a login attack. Passwords, MFA, and passkeys all defend the authentication event, but the attacker is operating after that point by hijacking the consent and code exchange path. That means traditional identity programmes that stop at sign-in coverage miss the real trust boundary. Practitioners should treat browser-mediated authorization as part of identity governance, not as an edge case.

OAuth consent phishing exposes a trust model that assumes the user sees the whole transaction. ConsentFix works because the victim is asked to move security material between two contexts, then trusts the second context to be legitimate. That assumption was designed for a user who can reliably distinguish a normal callback from a hostile one. The implication is that browser-native workflows need their own control and monitoring model, because user recognition is not a dependable security control.

First-party app consent creates a standing-trust problem that many enterprises have not modelled explicitly. The article shows that pre-consented Microsoft applications and conditional access exclusions can turn policy exceptions into an attack surface. Standing consent exposure: this is the failure mode where a trusted application remains broadly reachable even when the governance model assumes granular restriction. The practitioner conclusion is that trust in first-party apps must be continuously re-validated, not assumed from platform ownership.

Browser behaviour has become an identity signal, not just a fraud signal. ConsentFix can only be detected reliably when teams inspect what the page does, how the user interacts, and what code is being moved through the browser. That pushes identity security toward unified browser, SaaS, and identity telemetry. For security leaders, the relevant question is no longer whether the IdP is protected, but whether the browser can be governed as part of the identity plane.

The campaign demonstrates how fast a niche technique can become mainstream tradecraft. The community response, the rapid iteration, and the breadth of affected Microsoft apps all point to quick operational adoption by both defenders and attackers. That means governance for OAuth abuse cannot wait for a mature incident pattern. Practitioners should assume rapid variant drift and build detection and policy response accordingly.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and a further 47% having only partial visibility, according to The State of Non-Human Identity Security.
• That same study found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which helps explain why browser-mediated identity abuse keeps slipping through.
• For a broader control model, compare that visibility gap with Top 10 NHI Issues, where unmanaged access and weak lifecycle oversight recur across identity types.

What this signals

ConsentFix is a warning that identity telemetry has to move closer to the browser. When a user can be tricked into moving an OAuth code between windows, the browser becomes part of the identity attack surface. Teams that still centre their monitoring on the IdP alone will keep missing the actual abuse path.

Standing consent exposure is becoming a useful concept for Microsoft governance teams. It describes the gap between a trusted first-party application and the real-world controls around scopes, exclusions, and delegated access. The more broadly an app is pre-consented, the more governance has to focus on exception review and browser-side detection rather than login assurance.

The posture shift is clear: modern identity defence now spans human session behaviour, SaaS permissions, and non-human access patterns. For practitioners, that means reviewing OAuth governance alongside the same lifecycle and visibility controls already used for service accounts and other NHIs.

For practitioners

• Treat the browser as an identity control surface Instrument browser telemetry for paste events, unexpected redirect chains, and unusual OAuth code handling so malicious consent flows can be blocked before token redemption.
• Harden Microsoft app consent and exclusions Review first-party app permissions, legacy scopes, and Conditional Access exclusions, then restrict access to vulnerable apps only for approved users and groups.
• Enable the missing identity logs Turn on deprecated AADGraphActivityLogs and hunt for the application IDs and resource IDs associated with browser-native OAuth abuse.
• Separate legitimate CLI access from general user access Create service principals for vulnerable apps and narrow who can use them, so common CLI and management tools are not broadly phishable through consent abuse.

Key takeaways

• ConsentFix shows that authentication strength does not protect against authorization-code theft once the browser is part of the attack path.
• The campaign exploited pre-consented first-party Microsoft apps, legacy scopes, and logging gaps, which widened the detection and response blind spot.
• Teams need browser telemetry, app-consent governance, and tighter exception control if they want to limit OAuth abuse in Microsoft estates.

Key terms

• OAuth Authorization Code: A short-lived code issued during an OAuth sign-in flow that can be exchanged for tokens. In abuse cases, the code becomes the handoff point between the victim's browser session and the attacker's token redemption flow, so it must be treated as sensitive identity material.
• First-party application consent: A trust model where a platform's own applications are pre-authorised or broadly trusted inside the tenant. That convenience can create standing exposure when attackers target the application itself rather than the login session, especially if scopes and exclusions are not tightly governed.
• Browser-native attack: An attack that completes entirely inside the browser, using web flow manipulation rather than endpoint compromise or malware installation. These attacks often bypass traditional tooling because they look like ordinary user interaction unless browser telemetry and page behaviour are monitored directly.
• Conditional Access exclusion: A policy exception that allows a user, app, or scope to bypass normal access controls. Exclusions are necessary in some environments, but they also create governance debt when they are not reviewed as part of the live attack surface.

Deepen your knowledge

OAuth abuse and browser-native identity attacks are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for Microsoft environments that already depend on app consent and delegated access, it is worth exploring.

This post draws on content published by Push Security: ConsentFix and OAuth consent phishing analysis. Read the original.