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.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “ConsentFix v3: Analyzing a new criminal toolkit”.
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.
Q: Why can OAuth-based phishing bypass MFA and passkeys in Microsoft environments?
A: Because those controls protect sign-in, not every post-authentication authorisation path.
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.
Practitioner guidance
- Audit OAuth consent paths for browser-native abuse Identify which apps can be authorised from a signed-in browser session without additional verification, then classify them by business criticality and privilege reach.
- Restrict high-risk application IDs and exclusions Review first-party and other high-utility applications that have conditional access exclusions, then limit which users can consent to them.
- Monitor token exchange and consent telemetry Correlate initial access IP, subsequent activity, and application IDs so a user-driven sign-in followed by attacker-driven actions stands out in logs.
Bottom line: ConsentFix shows that browser-native OAuth abuse can turn a legitimate Microsoft session into account takeover without relying on password theft.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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
ConsentFix exposes a browser-native trust boundary that most identity programmes still do not govern. Traditional IAM controls assume the risky event happens at credential entry or device enforcement. This technique shows that an authenticated browser session can be manipulated into issuing tokens that are far more powerful than the initial login event suggests. The practitioner conclusion is that browser-mediated authorisation must be treated as a first-class identity control surface.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: Should organisations block all OAuth device and consent flows to stop phishing?
A: Not automatically. The better decision is to narrow which applications can be consented to, restrict high-risk client IDs, and review where legitimate browser-based authorisation is actually required. Blanket blocking can disrupt business workflows, but ungoverned consent paths leave a large abuse surface.
👉 Read our full editorial: ConsentFix shows how OAuth phishing bypasses browser identity controls
This post was modified 1 day ago by NHI Mgmt Group