Why ClickFix is so effective against security-aware users

ClickFix does not rely on users downloading an obviously suspicious attachment or ignoring a familiar browser warning. Instead, it presents an apparent technical problem and gives the user clear instructions to resolve it.

A fake CAPTCHA may claim that verification has failed. A document may appear unable to load. A website may report a browser error. The user is then instructed to copy a command, open the Windows Run dialog or terminal, paste the command, and execute it.

To a security-aware user, these extra steps can appear reassuring. The process feels deliberate, transparent, and more technical than clicking an unknown download. In reality, the user is being guided through the opening stages of an attack.

This inversion is what makes ClickFix so effective. It exploits the same cautious, problem-solving behavior that security awareness training often tries to encourage.

ClickFix is a social engineering technique that tricks users into executing malicious commands on their own devices.

The pasted text is not a verification code. It is typically an obfuscated command designed to download a payload, execute a script, or begin a longer infection chain.

ThreatLocker has observed ClickFix campaigns delivering information stealers, remote access tools, loaders, and rootkits. Some payloads execute in memory or abuse legitimate Windows utilities such as PowerShell, mshta.exe, rundll32.exe, and msbuild.exe, helping the attack blend into normal system activity.

ClickFix has also expanded beyond Windows with variations targeting macOS users by directing them to run commands in Terminal, sometimes prompting them to enter a system password before downloading and executing malware. The technique has become common and successful enough that in October 2026, Google Chrome added improved safeguards against ClickFix attacks when Enhanced Protection is enabled.

Most security awareness training teaches users to recognize familiar warning signs: unexpected attachments, urgent payment requests, suspicious links, spelling errors, or prompts for credentials.

ClickFix can avoid many of these signals.

The initial page may be hosted on a legitimate website that has been compromised. The prompt may imitate a familiar CAPTCHA or Cloudflare verification page. Instead of asking the user to download an executable, the attacker provides what appears to be a technical troubleshooting process.

That process exploits several characteristics of security-aware users.

Security-conscious users are often less likely to ignore a warning message. If a page reports that verification has failed, they may stop and carefully follow the displayed instructions.

ClickFix frames malicious activity as the cautious response and the user believes they are resolving a security check.

This creates a form of action bias. A clear problem has appeared, and the page offers an immediate, step-by-step solution. Each action seems small and understandable: Click a button, press two keys, paste a value, and press Enter.

The true intention stays hidden until the final command runs.

ClickFix inserts itself into familiar routines like CAPTCHAs, browser checks, or login verifications.

Attackers can imitate services such as Cloudflare, Google, Microsoft, Discord, or other recognizable platforms. The instructions may use professional formatting and plausible technical language. Because users regularly encounter genuine verification friction, another check may not immediately appear abnormal.

The attacker is not asking the user to suspend disbelief. They are reproducing an experience the user has encountered many times before.

Security training commonly advises users to inspect links before opening them. However, ClickFix campaigns may use compromised legitimate domains, trusted redirect services, or advertising infrastructure to reach the final landing page.

Microsoft documented one campaign in which a Google Ads redirect obscured the destination. This undermined the usual practice of hovering over a link to check where it led.

Even when a user follows established guidance, the visible indicators may not tell the entire story.

Many security products are designed to identify files delivered without the user’s knowledge or processes launched through an exploit. ClickFix changes that sequence.

The user manually opens a legitimate system interface and executes the command. From the operating system’s perspective, the activity may look intentional. No software vulnerability is required, and the initial stage may not include a conventional malicious attachment.

This user participation can help ClickFix get past automated defenses that expect malware to arrive and execute through more recognizable paths.

When a user selects the button on a fake verification page, malicious text may be copied to the clipboard automatically. The user then pastes it into the Run dialog without seeing or understanding the complete command.

Attackers use Base64 encoding, character escaping, string fragmentation, excessive whitespace, misleading comments, and multiple nested commands to conceal what will happen. File extensions may also be deceptive. A payload labeled as an image, audio file, or text file may contain executable instructions that a trusted system utility can interpret.

Security awareness cannot reasonably require every employee to de-obfuscate a PowerShell command before recognizing it as malicious.

The steps shown to the user may be simple, but the activity behind them can be highly sophisticated.

In August 2026, ThreatLocker MDR intercepted a ClickFix attack that began with a fake CAPTCHA on a compromised website belonging to a legitimate business. The user was directed to run an obfuscated command that invoked PowerShell and mshta.exe.

That command initiated a multi-stage chain involving an MP3 file containing an embedded script, scheduled task creation, Base64-encoded PowerShell, in-memory execution, and a steganographic loader that extracted additional code from an image.

The final stages attempted to deliver ACR Stealer and a secondary payload designed to steal Google credentials, potentially including MFA information.

This gap between the visible instruction and the underlying activity is central to ClickFix. The user sees a short troubleshooting process. The endpoint receives a chain of scripts, downloads, native-tool executions, persistence attempts, and outbound connections.

Employees should be trained to treat any website instruction to open Run, PowerShell, Command Prompt, or Terminal as suspicious. Legitimate CAPTCHA systems do not require users to paste commands into operating system tools.

Users should also know how to stop and report the incident if they have followed part of the process. Rapid reporting can help security teams isolate the endpoint and investigate before the attacker progresses further.

However, organizations should not make employee judgment the only barrier between a deceptive prompt and code execution.

ClickFix campaigns are designed to change their branding, wording, domains, and payloads. Even experienced users can make a mistake when a prompt appears in the right context. Effective security architecture must assume that someone will eventually follow the instructions.

The goal is not to eliminate human error. It is to prevent one error from becoming an organizational compromise.

ClickFix depends on the endpoint being allowed to carry out the user’s instructions. A Zero Trust approach can interrupt the attack even after the social engineering succeeds.

In the aforementioned ClickFix attack intercepted by ThreatLocker MDR, Application Allowlisting blocked the malicious code from executing, stopping the attack.

If a ClickFix command attempts to launch an unapproved script or execute a newly downloaded payload, a deny-by-default allowlisting policy can block it. This removes the assumption that code should be trusted simply because a user initiated it.

ClickFix frequently abuses tools that organizations cannot simply remove. PowerShell and other native utilities may be required by administrators and business applications.

ThreatLocker Ringfencing™ controls what approved applications are allowed to access, launch, modify, and connect to. Organizations can apply policies that prevent PowerShell from accessing the internet, restrict suspicious child processes, or stop trusted applications from interacting in ways that enable an attack.

This is particularly important for ClickFix because allowing PowerShell to run does not mean it should have unrestricted permission to download and execute content.

Privileged Access Management helps remove standing administrative rights and provides controlled elevation when legitimate tasks require it.

If a ClickFix command attempts to modify protected system areas or perform privileged actions, limiting the user’s administrative access creates another barrier between initial execution and a successful compromise.

Preventive controls should be supported by monitoring and response. ThreatLocker MDR can investigate suspicious process chains, script activity, downloads, and network connections while containment controls restrict how far the activity can progress.

This combination gives security teams time to respond without depending on an alert arriving before the attacker completes the next stage.

ClickFix is effective because it does not treat security-aware users as careless. It gives them a plausible problem, familiar visual cues, and a structured process that appears to reward caution.

Training can help users recognize the pattern, but attackers will continue changing how the prompt looks and where it appears. Organizations must therefore prepare for the moment when a convincing lure succeeds.

With default-deny execution policies, application containment, least-privilege access, and active monitoring, a copied command does not have to become a compromise.

Book a demo with ThreatLocker to see how Zero Trust controls can prevent ClickFix and other social engineering attacks from progressing beyond the initial mistake.

A ClickFix attack is a social engineering technique that tricks users into copying, pasting, and executing a malicious command under the guise of fixing an error or completing a verification check.

ClickFix attacks imitate familiar CAPTCHAs, browser errors, and troubleshooting prompts. They exploit users’ instinct to resolve technical problems and can make malicious actions appear legitimate and intentional.

How does ClickFix trick users into running malware?

A fake prompt instructs the user to open the Windows Run dialog, PowerShell, Command Prompt, or Terminal and paste a command copied from the webpage. Executing it can download malware, run malicious scripts, or begin a multi-stage attack.

Does ClickFix require a software vulnerability to work?

No. ClickFix primarily exploits user trust and legitimate system tools rather than a software vulnerability. The user is socially engineered into initiating the malicious command themselves.

How can organizations prevent ClickFix attacks?

Organizations should combine security awareness training with deny-by-default application control, script restrictions, application containment, least-privilege access, and endpoint monitoring. These controls can block unauthorized execution and restrict tools such as PowerShell if a user follows a malicious prompt.