I've been fighting the initial compromise technique known as "ClickFix" for a few months now, and its success has been shocking to see.
So we're on the same page, this technique refers to coercing the user—usually with a security alert or fake CAPTCHA prompt—to click a button on a webpage that injects a command onto the user's clipboard. The user is then instructed to execute the pasted code via the Windows Run dialog (Win+R) or opening PowerShell directly. In my experience, the Run Dialog path is much more common. The copy/pasted command often has a comment at the end of the line like I am not a robot ✅ to sell the ruse as the user pastes the command.
When I first read about this technique, I was flabbergasted that it would work—but I shouldn't have been. My incredulity resulted from forgetting a core lesson from my time doing tech support for students and teachers: almost nobody has to understand how computers work at any level to use them. The barriers I see between the browser and the OS, the mental model I possess that makes this attack ridiculous, simply do not exist for most users. There is no distinction between the OS and the browser. Why would they be different? Why shouldn't they talk to each other?
What's more, we've trained users to expect onerous verification processes that make no sense to them anyway, so why would this be any more suspicious? In ClickFix, security has become the victims of our own inscrutability.
So it's working. Like, a lot.
Detecting this technique is pretty simple—especially the Run Dialog version of it, since each use of that dialog creates Registry entries for recently-run commands at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. But that's detection, not prevention. As I keep trying to explain to my peers (and I don't know why it's such a hard concept), I don't want to know why we lost; I want to win. And you can win against ClickFix! But hoo boy, the mitigations are bound to make somebody unhappy.
Here are the mitigations I've found, ranked on axes of annoyance and effectiveness, 1-5.
Most Cumbersome: Windows GPOs
Effectiveness: 3 | Annoyance: 5
This is the "official" fix from Microsoft, and relies on two Group Policy settings The first is located at User Configuration -> Policies -> Administrative Templates -> Windows Components-> File Explorer. The "Turn off Windows key hotkeys" policy will disable Win+R and all other Windows key shortcuts.
This doesn't prevent users from opening the Run dialog entirely; it just prevents the shortcut from working. Pair this with User Configuration -> Policies -> Administrative Templates -> Start Menu and Taskbar's "Remove Run from Start Menu" policy, and now we're cookin'.
Here's the thing: this works, but it is hella annoying. Ironically the people most impacted by this policy are the folks who would likely implement it: the IT staff. They looooove Win+R. Love. It. Won't be parted from it. That alone can make this mitigation a hard sell, but wait: there's more! This policy does more than it says on the tin.
In addition to disabling the Win+ shortcuts, that policy also disables other related Explorer features, such as using UNC paths in File Explorer, or the ability to launch PowerShell terminals from Explorer. Those power user features are must-haves for many IT folks. Implementing this policy may result in more, uh, "creative workarounds" than you'd prefer.
Most Direct: Targeted Registry Values
Effectiveness: 4 | Annoyance: 2
I'll come right out and say this is my preferred mitigation. Is it perfect? It is not. But it comes with the lowest amount of implementation pain of all the solutions.
I originally discovered HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\DisabledHotkeys the hardest way possible: by reversing Explorer looking for another way to solve this problem. But once I saw a check for this key and learned what it does, I knew it was the best way forward.
Geoff Chappell's article on shell restrictions tells us that there are two policy-based restrictions available: REST_NORUN and REST_NOWINKEYS. These are set in HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer with DWORD values of 0x00000001 set for NoRun and NoWinKeys Properties, respectively. These are what the GPOs listed above actually set! And as such, they come with the same pain points.
Conversely, Chappell's article on the user-level DisabledHotkeys value (note the different path—Explorer\Advanced instead of Policies\Explorer) tells us we have another, more granular option for Windows hotkeys. We can set this property to a String value comprising the Windows key shortcuts we want to disable. So RX disables Win+R and Win+X, both of which can lead to the Run dialog. A simple restart of Explorer enforces the setting.
I prefer this approach because it captures most of the attack surface with minimal collateral damage. IT pros who absolutely require Win+R have the know-how to change the reg setting (it's at user level after all), or use an alternative we'll discuss shortly. Either way, this prevents the unwitting user from accessing the Run dialog easily using the most common attack path.
Most Unhelpful: Disabling PowerShell
Effectiveness: 1 | Annoyance: 5
"Just disable PowerShell for most users" is a solution I hear from a lot of know-it-all IT admins. This sounds like an easy solution, but it's sophomoric. We'll include "just disable PowerShell outbound communication" for this one as well.
I'll say this plainly: if you think this is possible in most IT environments, you have no concept of all the things running dirty PowerShell under the user's context. PowerShell that phones out to network locations, PowerShell that's base64-encoded, PowerShell that Windows itself expects to work. Disabling PowerShell for most users breaks a whole lot more than you expect—especially now that VBScript has been deprecated and sysadmins the world over were told explicitly to make their logon hooks PowerShell-based.
I pressed a vendor on this recommendation and whether they'd seen anyone actually pull it off. The answer was: yes, but only in very airgapped, highly sensitive network segments. So for most environments, this is not a real answer.
Even worse: this barely addresses the ClickFix problem. Of the ClickFix attacks I've personally encountered, the payloads invoked cmd.exe, curl.exe, mshta.exe, and more. Hell, I even wrote up demos on how you'd use more exotic runtimes to bypass this kind of defense.
To recap: disabling PowerShell outright breaks tons of things and doesn't solve the problem at hand. Leave this one to the armchair sysadmins.
Most Off-the-Wall: PowerToys?!
Effectiveness: 3 | Annoyance: 2
PowerToys is an optional add-on of Windows utilities from Microsoft, installable from the Windows Store or winget. Surprisingly, PowerToys helps to solve our problem in two ways. First, the Keyboard Manager can remap shortcuts—yes, even Win+R—to some other purpose. Map it to Notepad and call it a day, or have some PowerShell script (see? SEE?!) pop a MessageBox that says "Hey, did a website tell you to do this? Contact Security!"
Second, PowerToys Run is like macOS's Spotlight, but for Windows. It's an all-in-one run-stuff/find-stuff/do-stuff prompt. For those who simply can't live without their precious Run dialog, providing them with PowerToys Run as an alternative could smoothe their ruffled feathers after applying one of the mitigations above.
Even better? You can deploy and configure PowerToys via GPO and other management tools.
But PowerToys is its own attack surface to manage, known vulnerable to DLL hijacking and overall just an unfamiliar entity to most IT shops. Still, worth exploring for its featureset. I've been a PowerToys user for some time, and can't imagine using Windows without it. It's how I remap Caps Lock to Escape and configure a 1080p window size for presenting on my ultrawide monitor.
"Just make them comply"
Some of you may be wondering why I'm bothering to think about what users will like when it comes to a security policy intended to prevent attacks. That confusion stems from two things: lack of experience and a misunderstanding of security's purpose. Take as much from either bucket as you like.
You, noble security professional, do not exist to make the most secure system imaginable. If you did, we'd all arrive at airgapped offices that got nothing accomplished. You exist to enable business. That's it. That's your whole job. And so, systems must walk a line between security and usability. The instant you step over the line and make a system unusable, I guarantee your users will find a workaround that fits their needs.
Therefore, it is wise to consider the reception of a security policy by your users. As Grand Moff Tarkin discovered, the tightest grip is not always the most secure. This is especially true for your IT staff that may or may not have local admin—even when they're not supposed to.
ClickFix isn't the first attack that preys on core system components we take for granted; it won't be the last. Mitigating these sorts of techniques is difficult because these systems' functionality is not optional for many. Indeed, they may be critical to users' workflows.
If you're in security, you fight for the user. You serve them. They do not, nor should they, serve you.