ClickFix hardening for Windows fleets - the honest version
First, the part most vendors bury: RFF is not EDR. We do not detect ClickFix and we do not block it - that’s your endpoint security’s job, and if anyone sells you a config tool that “stops ClickFix,” close the tab. Here’s the specific, real thing RFF does: it hardens and drift-tracks the Windows configuration surfaces ClickFix abuses, across your whole fleet, and it turns on the logging that shows you exactly what ran if a box gets hit.
That’s a narrower claim than “protection.” It’s also one we can actually keep.
Start free → · No credit card · Up in minutes
What ClickFix actually is
It’s social engineering, not an exploit. A user hits a fake CAPTCHA (“verify you’re human”), a fake “fix this error” page, or a booby-trapped document. The page tells them to press Win+R, paste (Ctrl+V), and hit Enter. What’s sitting in their clipboard is a command - usually powershell -w hidden ..., an mshta call, or a curl-to-iex one-liner - and the user runs it themselves, on their own box, with their own token. No CVE. No dropper for the perimeter to catch on the way in. The human is the delivery mechanism.
Because the user runs it, your firewall and your email gateway never saw a payload. That’s what makes ClickFix effective, and it’s exactly why the answer is layers, not one magic box.
Where EDR ends and config hygiene begins
Blocking the payload once it fires is EDR/AV’s job - keep it, tune it, trust it for that. But the vectors ClickFix leans on are configuration surfaces you can harden in advance, and prove you hardened. That’s a different layer, and it’s the one most teams have never actually locked down or audited across a whole fleet. That layer is RFF’s lane.
Two honest truths at once: hardening these surfaces will not stop a determined attack on its own, and turning them on fleet-wide - then knowing they stay on - is real, measurable risk reduction you can put in front of an auditor.
What RFF hardens - and keeps hardened
RFF ships these as named Conformance baselines (its Group-Policy-as-readable-config engine). You seed one in a click, review it, assign it to a group, and RFF diffs the fleet against it - in plain English, down to which GPO set each value.
1. PowerShell script-block logging - turn it on. (Do this one first.) This is the honest hero, because it claims to stop nothing - it records. With script-block logging on, Windows writes every executed script block, de-obfuscated, to the event log (event 4104). So if a box does get hit, you pull the exact PowerShell that ran - through RFF - and you know what happened instead of guessing. Near-zero user disruption, safe to roll out fleet-wide. “We turned on the logging that shows what ran” is a complete, true, useful sentence - and squarely in RFF’s lane of see what happened, not stop it.
2. Disable the Run dialog (Win+R) - the #1 vector, for the groups that can take it.
NoRun kills the Run box, which is ClickFix’s primary lure. It is also high-disruption, and we flag it loudly: every admin who lives in Win+R (mmc, regedit, UNC paths) will feel it, and it only covers the Run-dialog vector - not the Start-menu-search or address-bar variants. So it ships as a separate, opt-in baseline, meant to be scoped to a group and run report-first. We will not slip a fleet-wide Run-dialog kill inside a friendly “one-click hardening” button.
On the roadmap (honest status: not shipped yet): disabling Windows Script Host to kill the wscript/cscript payload path, and blocking mshta.exe. They need an agent update, and we’d rather ship them right than list them as done.
It’s a baseline, not a run-once script
This is what separates hardening from a PowerShell snippet someone ran in 2023 and forgot. In RFF these settings are a versioned desired-state baseline, so:
- RFF tells you when a machine drifts off the hardened state - a re-image, a rogue GPO, someone who “temporarily” turned logging off.
- Fixing drift is approval-gated and one-click rollback-able - nothing writes to a box blind, and the undo script is captured before the change runs.
- If an active GPO already owns a value, RFF reports it instead of fighting it - because Group Policy would just reimpose it and you’d have a box flapping every couple hours forever.
That last point matters here. A lot of “ClickFix hardening” advice is a GPO you set once. RFF is how you know it’s still set, on every box, next quarter.
What it covers - and what it does NOT
- Covers: turning on the forensic logging that shows what ran; hardening plus drift-tracking the Run-dialog vector (and, soon, WSH/mshta); proving fleet-wide that the hardening is actually in place and staying in place.
- Does NOT: detect the attack, block the payload, inspect content, or quarantine anything. It is not EDR, not AV, not a sandbox. If a user is determined to paste and run, config hardening shrinks the surface - it does not remove the human.
No config tool can promise complete ClickFix protection. What RFF covers is the layer you probably haven’t audited - and we’re specific about exactly where its edges are.
What’s free, what’s Pro
- Free - the read-only effective-policy view: see what’s set on a box, and which GPO set it.
- Every plan, including Free - the Conformance engine that powers these baselines: seed the ClickFix templates, version them, diff the fleet for drift, and enforce with approval + rollback.
Seeing is free. Hardening-and-keeping-it-hardened is the paid part - the same line we draw everywhere.
Point RFF at your fleet, seed the ClickFix forensics baseline, and in five minutes you’ll know which machines already log what runs and which don’t. That’s the honest starting line - not “you’re protected,” but “now you can see it, and prove it stays that way.”