ConsentFix: Hardening Microsoft 365 + Entra ID Against OAuth Consent Hijacks
A new twist on ClickFix: stealing identities instead of endpoints
Classic ClickFix lures trick users into running malware after clicking an "I'm not a robot" challenge. ConsentFix takes the same social engineering pattern and points it at identity instead of endpoints. A compromised or malicious webpage injects a fake Cloudflare Turnstile-style challenge that requests a work email address. If the address matches the target list, the victim is handed a real Microsoft login flow.
Because most users already have active Microsoft 365 sessions, there is often no password prompt or MFA challenge. A single click signs them in and silently redirects to localhost with an OAuth authorization code that the attacker wants back.
How the ConsentFix chain works
- The lure page validates the victim’s email and opens a trusted Microsoft login window.
- The OAuth request is pre-seeded with the Azure CLI client ID, so the user consents to a first-party Microsoft app that cannot be blocked or removed by default.
- After the click, Microsoft redirects to
http://localhost:{port}with the OAuth code. The attacker convinces the victim to copy, paste, or even drag that URL back into the lure page. - The attacker exchanges the code for refresh and access tokens, gaining Microsoft 365 and Entra ID access without ever handling a password.
The result: inboxes, Teams, SharePoint, OneDrive, and Entra ID administration are reachable with almost no friction—two to three clicks in a browser are enough.
Why this bypass feels "invisible"
- Trusted first-party app: Azure CLI is implicitly trusted across tenants and does not require admin consent prompts.
- Minimal user friction: existing cookies allow a one-click redirect to
localhost; no malware touches the endpoint. - Browser-only artifact trail: the only visible clues are the Microsoft login entry in browser history and a short-lived localhost error page.
In the proof-of-concept demo, the attacker even smooths over copy/paste friction by letting the user drag the localhost URL into a text box—keeping the ruse alive while the tokens are captured in the background.
🔧 Technical Reality Check: Hardening steps that matter right now
OAuth governance
- Require admin consent for first-party apps where policy allows.
- Disable user consent for multi-tenant apps; pre-approve only what business workflows need.
- Monitor sign-ins and token exchanges from the Microsoft Azure CLI app ID for anomalies.
Conditional Access
- Block OAuth authorization code flows from unfamiliar locations or devices.
- Require phishing-resistant MFA for all admin roles and break-glass accounts.
- Apply token protection and sign-in risk policies to reduce stolen token utility.
Detection and response
- Alert on new service principals and unexpected refresh token issuances.
- Hunt for sign-ins showing Application: Microsoft Azure CLI / Azure Resource Manager.
- Review browser history or EDR telemetry when users report odd localhost pop-ups.
SecureStepPartner perspective
Identity attacks are increasingly browser-native and invisible to endpoint defenses. Treat OAuth governance and Conditional Access tuning as first-class security projects—not afterthoughts.
Related Insights
Request an Identity Hardening Review
Validate your defenses against ConsentFix-style OAuth hijacks before attackers validate them for you.