There was no phishing email. The attack came from a site they trusted

In early July, a user at a globally distributed trust company we look after visited the website of a professional firm they deal with regularly. It was a site they had every reason to visit and no reason to doubt. The site had been compromised, and it served them a page that asked them to prove they were human.

Nothing arrived by email. Nothing was attached. No credential was requested, no login page was imitated, and no link was clicked in a message from a stranger. Every instinct the user had been trained to apply was pointed somewhere else entirely.

The lure

The technique is called ClickFix, and it works by inverting the thing that makes phishing detectable. Instead of persuading a user to open something dangerous, it persuades them to type something themselves.

The page presents as a routine verification step, a CAPTCHA or a “your browser needs to be checked” notice, and then supplies the fix: copy this, press these keys, paste it, hit enter. The user performs every step personally. From the machine’s point of view, an authenticated human at the keyboard deliberately ran a command. There is no attachment to scan, no sender to check, and no link in an inbox for a mail gateway to see.

Before we escalated anything, we replicated the page on an isolated sandbox device to confirm it was genuinely live rather than a false positive. It was. The instructions on the page fetched and ran an executable.

What the command actually did

The command was built to be difficult to read and difficult to catch. It launched in a hidden window and bypassed the local execution policy. It assembled the domain it was calling at runtime rather than carrying it in plain text, then downloaded an executable and saved it into the user’s temporary folder under a different name.

Then it did the interesting part. It stripped the Zone Identifier from the downloaded file and set an environment variable to suppress zone checking, which is the mechanism Windows uses to remember that a file came from the internet and to warn you about it. The command was not only fetching a payload, it was deleting the file’s own memory of where it came from.

Microsoft Defender detected and removed the activity before the payload executed. Our monitoring platform then isolated the host from the network, while the SOC was still writing its preliminary findings.

Why we rebuilt the machine anyway

The payload never ran, and the endpoint had done its job. We wiped the laptop regardless.

ClickFix families lean heavily on in-memory execution, which means the absence of evidence on disk is not evidence of absence. You can confirm what was blocked. You cannot confirm what a technique designed to leave nothing behind did not leave behind. Reset from a known-good build is the only answer that does not depend on being right about something unverifiable.

The full remediation was credential reset, Microsoft 365 session revocation, account access review, directory and file audit, host wipe and rebuild, and a validation pass before the machine went back to the user. The user was called and then written to, so that the explanation existed in a form they could return to later.

The part that is not in the runbook

The technically complete response ends there. The client’s machine was clean, their identity was secure, and the incident was closed.

But the compromised website was still serving the same page to everyone else who visited it, including other counterparties of the same firm who had no monitoring in place to catch what our client’s monitoring had caught.

So we passed it upstream. Our client notified the firm whose website it was, with the technical detail attached, and offered a security contact to coordinate with. That firm took it seriously, escalated it to their web technicians, and issued their own incident report within days.

None of that was billable and none of it was required. It is simply what the situation asked for. A watering hole works precisely because it sits on a site nobody thinks to question, and the only thing that shortens its life is somebody telling the site owner.

What we would take from it

Your counterparties’ websites are part of your attack surface. You cannot audit them, you cannot patch them, and your staff have entirely legitimate reasons to visit them. A trusted domain is not a safety property.

Email security does not see this. No message, no attachment, no sender. Controls that sit on the mail flow are simply not in the path.

Awareness training needs to name the specific behaviour. “Do not click suspicious links” does not cover this, because the user did not think they were clicking anything suspicious. The rule that covers it is narrow and easy to remember: no legitimate website will ever ask you to copy a command and run it on your computer. Not to verify you are human, not to fix your browser, not for any reason at all. If a page asks, the page is the attack.

Detection has to be paired with a decision. Defender blocked the payload, which is the outcome you want. The harder judgement was what to do about a machine that was probably fine. Tooling produces a verdict. Someone still has to decide what the verdict is worth.