Notifications
Clear all
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.
NHIMG editorial — based on content published by Push Security: ConsentFix and browser-native OAuth phishing techniques
By the numbers:
- 4 in 5 ClickFix attacks intercepted by Push came via Google Search.
Questions worth separating out
Q: What breaks when OAuth phishing happens after a user already authenticated?
A: Traditional MFA and password protection stop helping once the attacker can operate inside an already authenticated browser session.
Q: Why do browser-native phishing attacks complicate IAM controls?
A: They move the abuse path away from credential prompts and into the browser session, where legitimate logins can be repurposed into attacker-approved access.
Q: How can security teams reduce risk from first-party OAuth app abuse?
A: They should inventory high-trust first-party clients, restrict which scopes those apps can request, and review whether those permissions are still necessary.
Practitioner guidance
- Separate consent logging from sign-in logging Create detections for OAuth grant events, new app consents, and scope changes so they are reviewed independently from interactive logins and MFA successes.
- Restrict trust in first-party OAuth clients Review which first-party applications can request high-value permissions, and require explicit approval for scopes that enable tenant-wide or directory-wide access.
- Hunt for browser-native lures Add detections for copy-and-paste redirect patterns, localhost authorization URLs, and search-delivered phishing pages that only activate for targeted domains.
What's in the full article
Push Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step ConsentFix attack flow including the browser prompts, localhost redirect, and Azure CLI authorization path.
- Log indicators and GUIDs that can help investigators separate legitimate Azure CLI usage from suspicious consent-driven access.
- Detection heuristics for interactive versus non-interactive Microsoft sign-ins after compromise.
- Observed domains and IPs associated with the campaign for threat hunting and correlation.
👉 Read Push Security's analysis of the ConsentFix browser-native phishing attack →
ConsentFix and browser-native OAuth phishing: are controls keeping up?
Explore further
12/06/2026 7:13 am
ConsentFix proves that browser trust is now part of identity trust. The attack does not need to break passwords, MFA, or passkeys if it can convert a legitimate browser session into an attacker-approved consent event. That makes browser-mediated authorisation a governance boundary, not a user-experience detail. Practitioners should treat the browser as an identity enforcement point, not only a presentation layer.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A separate finding from the same research shows that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.
A question worth separating out:
Q: Who should investigate suspicious OAuth consent events?
A: Identity, IAM, and cloud security teams should all review them because consent abuse can create account control, directory visibility, and downstream resource access in one chain. Investigators should compare the consent event with later non-interactive sign-ins and resource access patterns. A single suspicious grant can be the starting point for broader account compromise.
👉 Read our full editorial: ConsentFix shows browser-native OAuth phishing bypasses MFA
