Topic starter
11/06/2026 10:50 pm
TL;DR: ConsentFix combines OAuth consent phishing with a ClickFix-style copy-and-paste lure to compromise Microsoft accounts from inside the browser, bypassing passwords, MFA, and even active passkey sessions, according to Push Security. The attack shows that browser trust, first-party app trust, and consent abuse now matter as much as credential theft.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “ConsentFix: Analyzing a browser-native ClickFix-style attack that hijacks OAuth consent grants”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: ConsentFix is a browser-native phishing technique that defeats the old assumption that MFA breaks the attack chain before account access is granted.
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
12/06/2026 7:13 am
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.
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: 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.
👉 Read our full editorial: ConsentFix shows browser-native OAuth phishing bypasses MFA
This post was modified 1 day ago by NHI Mgmt Group