ConsentFix: Analysing a browser-native ClickFix-style attack that hijacks OAuth consent grants

[Khushal]

Content source

https://pushsecurity.com/blog/consentfix#id-introducing-consentfix-a-new-kind-of-phishing-attack

Enter: ConsentFix. This attack shares a lot of similarities with ClickFix/FileFix, AiTM phishing, and OAuth Consent Phishing. You can think of this as a browser-native ClickFix attack that phishes an OAuth token on a target app by getting the victim to copy and paste a URL containing OAuth key material into a phishing page.

ConsentFix: Browser-native ClickFix hijacks OAuth grants

Analysing "ConsentFix", a new browser-native attack technique we've detected in the wild, combining OAuth consent phishing with a ClickFix-style user prompt.

pushsecurity.com

 

[Bot]

Enter: ConsentFix. This attack shares a lot of similarities with ClickFix/FileFix, AiTM phishing, and OAuth Consent Phishing. You can think of this as a browser-native ClickFix attack that phishes an OAuth token on a target app by getting the victim to copy and paste a URL containing OAuth key material into a phishing page.

ConsentFix: Browser-native ClickFix hijacks OAuth grants

Analysing "ConsentFix", a new browser-native attack technique we've detected in the wild, combining OAuth consent phishing with a ClickFix-style user prompt.

pushsecurity.com

View attachment 293674

This is a really interesting (and worrying) twist on OAuth abuse.

What “ConsentFix” is doing
In simple terms, the attacker is turning the redirect URL (which normally stays inside your own browser) into something the victim is tricked into manually handing over:

• Victim is told to “verify you are human / complete setup / enable SSO” etc.
• They’re asked to sign into Microsoft (or another IdP) in a legit browser window/tab.
• After login/consent, the IdP redirects to something like http://localhostort/callback?code=...&state=...
• The page or instructions then say: “Copy the full URL from the address bar and paste it here to continue.”
• That pasted URL contains the OAuth authorization code or token, which the attacker’s page harvests and exchanges for access/refresh tokens.

So instead of trying to:

• Steal session cookies (AiTM), or
• Abuse a normal OAuth consent screen directly (classic OAuth consent phishing),

they weaponize the user’s own hands to exfiltrate the sensitive part of the OAuth flow.

Why it’s effective

• Looks like a “normal” MFA / verification / support step.
• No scary domain in the actual sign‑in step (it really is login.microsoftonline.com, etc.).
• Defenses focused on cookies/session hijack might not trigger, because they’re just seeing a user log in as usual.
• Security‑aware users are often told “check the URL is legit when you sign in”; here, that condition is met.

What an attacker can gain
Depends on the app and granted scope, but typically:

• Access to email (read/send), contacts, files in OneDrive/SharePoint, Teams, etc.
• Persistent access via refresh tokens (until revoked or expired).
• Potential lateral movement inside M365 / Entra ID if high‑priv scopes are involved (e.g. mailbox access, app management).

How users can protect themselves

• Never paste redirect URLs or full address‑bar URLs into forms just because a page asks. That’s not normal for legitimate OAuth‑based apps.
• Be very suspicious of any page that says “after login, copy the URL from the address bar and paste it here/into the chat/into the form”.
• If something like this appears in a corporate flow, verify it separately (IT, internal portal, ticketing system).

What orgs / admins can do

• User awareness: explicitly teach “do NOT copy/paste redirect URLs after login or consent; that URL is sensitive.”
• Harden OAuth app consent:
  • Limit who can consent to new apps and risky scopes in Entra ID (Azure AD).
  • Use admin consent workflows and review 3rd‑party apps regularly.
  • Block or monitor high‑risk OAuth scopes (read/send mail, offline_access, Files.ReadWrite.All, etc.).
• Conditional Access & device trust: restrict access tokens to managed devices/locations where possible.
• Monitoring:
  • Watch for unusual OAuth app consents or new service principals.
  • Alert on anomalous sign‑in / token‑use patterns (new geo/IP, impossible travel, etc.).
• Security tooling: use identity protection / CASB / XDR that understands OAuth app abuse, not just passwords and cookies.

How this compares to other attacks

• ClickFix / FileFix: Similar “user interaction abuse” pattern, but ConsentFix is specifically stealing OAuth material via copy‑paste.
• AiTM phishing: Steals session cookies via reverse‑proxying login pages; here the attacker doesn’t need a proxy, just the redirect URL.
• Classic OAuth consent phishing: Relies on tricking you into granting a malicious app; ConsentFix can work even if the app seems legitimate or is your own app, by stealing the resulting code/token.

Bottom line
If a workflow ever asks you to copy and paste a post‑login URL, treat it as highly suspicious and stop there. From an org side, combining tight OAuth consent controls, identity monitoring, and user training is key to reducing the impact of this type of attack.

 

[Parkinsond]

If a domain not on the target list was provided, the victim was passed back to the original website and the attack did not progress to the next stage.

Entering rarely used email address, suck as of Zoho mail, may abort the attack?

Once logged into legit Microsoft or the account is selected from the dropdown, the user is redirected to localhost, which generates a URL containing a code associated with the user’s Microsoft account.

Could such settings in fort firewall help to stop rediction to localhost?

 

[Wrecker4923]

• Maybe you shouldn't give so much credit to Cloudflare symbols, especially when it's asking for unexpected things.
• I guess you shouldn't authorize with your account to gain access to something that shouldn't require authorization. This may be hard to resist, as the legitimate website is compromised.
• Why would authentication result in a redirect to localhost if you are not a developer?
• Why wouldn't the "legitimate" website grab the URL redirect directly instead of having you paste it?
• I guess you should not copy and paste things you don't understand into anything you don't understand.