Back to Insights

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

  1. The lure page validates the victim’s email and opens a trusted Microsoft login window.
  2. 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.
  3. 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.
  4. 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.