ClickFix attacks use fake CAPTCHA or verification pages to persuade users to open Run, PowerShell, or Terminal and paste commands themselves. That makes traditional advice about avoiding suspicious attachments or executables less effective, especially since copy-paste shell commands have become common in legitimate troubleshooting and software installation guides. For business environments, what controls are you using—security awareness training, EDR detections, application control, PowerShell restrictions, disabling Run, clipboard monitoring, email protections, or something else?
4 Answers
Training needs to explicitly say that a website asking someone to open Run, Terminal, or PowerShell and paste a command is a red flag—even if the page looks like a CAPTCHA or comes from a familiar brand. It is also worth reviewing internal documentation and software-install instructions so legitimate teams are not normalizing blind one-line downloads and execution. Give users a safe process for reporting these pages instead of expecting them to judge every command themselves.
Email defenses can reduce how often users see these lures. Enforce SPF, DKIM, and DMARC for your own domains, preferably with a reject policy once reporting confirms legitimate senders are aligned. Add lookalike-domain and impersonation detection plus clear external-sender banners. That will not stop a user from pasting a command on a malicious website, but it removes many convincing fake internal-IT messages.
We had an incident where both our EDR and Defender detected the payload and quarantined the machine. We rebuilt the endpoint afterward to return it to a known-good state. Disabling Run for standard users helped remove one common delivery path, although it does not address unmanaged devices or users launching PowerShell through other means.
Use layered controls rather than relying on one restriction. We use EDR, application control, user training that specifically covers fake verification pages, and policies limiting PowerShell and script execution where practical. Some organizations also disable or restrict Windows+R through Group Policy, Intune, keyboard-filter policies, or registry settings. Test those changes carefully because management and support tools may depend on shell access.
Blocking PowerShell outright can break endpoint management, so scoped allowlisting or constrained execution is usually safer than a blanket block.
Rebuilding was not excessive in our case either—it gave us confidence that the system was back to a vetted image.