Notifications
Clear all
Topic starter
10/06/2026 12:06 am
TL;DR: ConsentFix blends ClickFix-style social engineering with OAuth consent phishing to hijack Microsoft accounts, granting API access while sidestepping MFA, passkeys, and some Conditional Access controls, according to Push Security. The real lesson is that browser-native token abuse can invalidate assumptions built around interactive login, endpoint inspection, and post-authentication review.
NHIMG editorial — based on content published by Push Security: Investigating a new criminal toolkit for ConsentFix and browser-based OAuth hijacking
By the numbers:
- This year, device code phishing attacks have increased 37x.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Push Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of ConsentFix v3 tooling, including persona handling, campaign orchestration, and token exchange flow.
- Specific Microsoft application IDs, resource IDs, and Conditional Access exclusion patterns used by attackers.
- Browser detection approach for DOM-level analysis, blocking logic, and high-fidelity webhook alerts.
- Cross-vendor notes on how similar OAuth abuse patterns can affect Google, GitHub, Salesforce, and AWS workflows.
👉 Read Push Security's analysis of ConsentFix and browser-native OAuth phishing →
ConsentFix and OAuth consent phishing: are your controls keeping up?
Explore further
11/06/2026 1:44 am
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.
A few things that frame the scale:
- This year, device code phishing attacks have increased 37x, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ConsentFix shows how OAuth phishing bypasses browser identity controls
12/06/2026 3:18 am
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.
A few things that frame the scale:
- This year, device code phishing attacks have increased 37x, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ConsentFix shows how OAuth phishing bypasses browser identity controls
