Modern Threat Guards: ClickFix, Consent Phishing and Password Reuse

Phishing pages are no longer the only way into an organisation through the browser. Three techniques now lead the initial-access statistics and none of them involves a malicious download or a fake login form: a page that tricks the person into running a command, a genuine sign-in page that grants a malicious app lasting access, and a proxy that relays the real login page and steals the session after MFA. Browser Security has a guard for each. All three are workspace policy under Policies → Security.

1. ClickFix and fake-CAPTCHA guard#

The page shows a fake Cloudflare check, a broken-video or “fix this error” prompt, and a button that copies a PowerShell, mshta, or curl-pipe-shell command to the clipboard with instructions to open Run (Win+R) or a terminal and paste. The person installs the malware themselves; no file is downloaded and no credential is typed, so nothing else fires.

What the guard does#

1. Every programmatic clipboard write and every copy event on a page is examined. A text that looks like a command (PowerShell, mshta, cmd, certutil, curl or wget piped to a shell, encoded commands, UNC paths, script downloads) is flagged.
2. When the page also carries the lure (“verify you are human”, “press Win+R”, “paste and press Enter”, “to fix this error”), the clipboard is overwritten with a harmless note, a notice explains what just happened and shows the command, and a critical incident CLICKFIX_ATTEMPT is recorded.
3. A command copied without the lure gets a quiet banner and a low-severity COMMAND_COPIED incident, except on developer sites (GitHub, package registries, vendor documentation) where copying install commands is normal.
4. A page that shows the lure before anything is copied gets a warning banner and a medium CLICKFIX_LURE incident.

Settings: ClickFix / fake-CAPTCHA guard (on by default) and the action on a caught page: Warn keeps a “stay” button, Block leaves only Close page. Sites the person has paused or trusted are left alone.

2. OAuth consent guard#

Consent phishing does not fake the sign-in page: the person signs in to the real login.microsoftonline.com or accounts.google.com, passes MFA, and is asked to grant an app permissions. Accept, and the app holds a token for the mailbox or files that survives a password reset. The phishing engine sees a legitimate page.

What the guard does#

1. On Microsoft and Google consent screens the guard reads the app name, whether the publisher is verified, the client ID, and the permissions requested, grouped as mailbox, files, contacts, calendar, directory, offline access and sign-in on your behalf.
2. In a managed workspace, any app not on the Approved apps list that asks for one of those groups is risky. For personal users only unverified publishers are.
3. Warn shows a notice naming the app and the permissions with Cancel this request and Continue anyway; Block disables the Accept button and leaves Cancel. Either way a high-severity OAUTH_CONSENT_RISKY incident is recorded, and OAUTH_CONSENT_ACCEPTED if the person continues.

Settings: OAuth consent guard (on by default), the action, and Approved apps: comma-separated app names or client IDs. Build the list from the consent incidents of the first weeks, then switch to Block. Apps granted admin consent in your tenant never show a consent screen and are not affected.

3. Password Alert#

Adversary-in-the-middle kits proxy the genuine login page: the person sees the real branding, the real MFA prompt, and the attacker gets the session. Look-alike detection catches the hostname sometimes; Password Alert catches the password every time, and also ends reuse of the work password on personal sites.

What the guard does#

1. When someone signs in on one of the identity-provider hosts, the extension computes a salted, iterated SHA-256 fingerprint of the password on that device and keeps the last three. Defaults cover Microsoft, Google and Okta; add your own single sign-on host.
2. On any other site, when a password field is submitted (Enter, Submit, or a sign-in button), the submit is held for a few milliseconds while the fingerprint is compared. A match means the work password is being typed somewhere that is not your identity provider.
3. Warn shows the notice with Clear the password field and Continue anyway; Block refuses the submit. A high-severity PASSWORD_REUSE incident names the site, and PASSWORD_REUSE_ACCEPTED records a continue. The person is told to change the work password if they already submitted it.

Settings: Password Alert (off by default; switch it on per workspace), the action, Identity provider hosts, and Hosts allowed to take the work password for internal applications backed by the same directory. Fingerprints are removed from the device when the policy is switched off.

4. Password logins report#

Every password submitted to a site that is not one of the identity-provider hosts is counted, per site and per member, on the Password logins page under Security. That is the inventory of applications people use without single sign-on: the candidates for onboarding to your identity provider, the accounts nobody knew about, and, cross-referenced with Password Alert, the sites where the work password was reused. Embedded login frames and popup sign-in windows are covered as well as ordinary pages; the site recorded is the one that actually took the password. Two password fields on the page count as a new account. Hosts and counts only, with a CSV export; usernames and passwords are never collected. Switch it off with Password logins report under Policies → Security.

5. What the SOC sees#

All of them flow through alert emails, webhooks, the SIEM pull and response rules like any other incident. Two rules worth creating on day one: a Teams or Slack message on CLICKFIX_ATTEMPT, and on PASSWORD_REUSE a sign-out-everywhere and password-change action against the member in Entra ID, Okta or Google Workspace.

6. Troubleshooting#