In 2026, ClickFix (clipboard hijacking via fake CAPTCHAs or browser errors) continues to surge as a top initial-access method. Microsoft and multiple security firms report rapid growth in campaigns that deliver malicious local HTML files through phishing or malvertising. The page copies an obfuscated command to the clipboard and tricks the user into pasting it.

Two user-friendly shortcuts now dominate:

• Classic variant: Press Windows key + R (Win+R) to open the Run dialog and paste.
• Newer 2026 variant: Press Windows key + X then select I (Win+X → I) to launch Windows Terminal (wt.exe) and paste.

Both launch trusted LOLBins such as PowerShell, cmd.exe, or Windows Terminal itself. These processes stage and execute payloads like Lumma Stealer, RATs, or loaders — often fileless or using memory techniques to reach browsers. Detection tools keep missing them because the activity starts from legitimate system processes and looks like normal admin work.

The Detection Gap — And the Damage Window It Creates

Adversaries know detection-based tools (AV, EDR, XDR) need time to work. From the very first malicious action, these tools must observe enough behavior to recognize a pattern. Then they analyze it, decide on a response (sometimes checking the cloud or waiting for a human analyst), and finally act. That entire period — from the first bad action until the reaction finishes — is what we call the damage window. During this time, credential theft, persistence, and data exfiltration can already be complete. Even when detection eventually responds, credential resets and cleanup often remain outside any automated rollback.

This is exactly why ClickFix keeps making headlines. The user-initiated pivot from trusted parents (explorer.exe or Windows Terminal) plus simple obfuscation keeps the damage window wide open.

How AppGuard Closes the Damage Window Without Detection

AppGuard takes a completely different approach. It applies zero-trust principles directly inside the endpoint by compartmentalizing high-risk user-space folders (such as Temp, AppData, ProgramData, Downloads, and Desktop).

Launch controls restrict what can run from those high-risk folders — blocking unsigned executables and script/module loads by any process. Containment restricts what specified high-risk processes can do to the rest of the endpoint along multiple dimensions. Isolation protects select memory regions, registry keys, and file-system objects from unauthorized access by any process.

These controls are enabled by default on every deployment. Many have not needed updates since 2010 because they focus on paths and behaviors rather than specific malware. AppGuard’s patented auto-adapt technology is the reason: it automatically allows legitimate IT tools and processes to function without requiring dozens of extra rules or frequent policy changes, keeping the attack surface small while avoiding friction for users.

What Happens in Both ClickFix Variants

Staging writes often succeed because signed LOLBins like PowerShell and Windows Terminal are allowed to write to user-space folders (this keeps legitimate admin and scripting work friction-free).

But the next critical steps are stopped cold:

When the same PowerShell or Windows Terminal process tries to execute or load a script from a high-risk folder (for example, running a downloaded .bat or .ps1 file from Temp or AppData), launch controls immediately block it. No matter which parent started the process, execution from those folders is not permitted.

Fileless techniques die here too. When the process attempts memory operations such as allocating memory, writing to another process, and queuing execution (for example, targeting chrome.exe or msedge.exe memory to steal credentials), isolation prevents the entire sequence.

Persistence attempts — writing to Run keys or creating scheduled tasks — are blocked because isolation protects those critical registry locations from unauthorized changes.

The result is the same for both the classic Win+R variant and the newer Win+X → I Windows Terminal variant: the attack never reaches payload execution or credential theft. The damage window is closed before it can open.

Real-World Outcomes

Organizations running AppGuard at scale see exactly this protection in action. Large deployments have reported zero successful malware incidents for years, even against evolving social-engineering and living-off-the-land chains. The controls shrink the attack surface, reduce the volume of alerts that reach EDR/XDR teams, and let defenders focus on true unknowns instead of chasing down mundane or redundant alerts.

Detection layers remain valuable for visibility. AppGuard simply ensures that what they miss or detect too late never succeeds.

Fortify your Endpoints Against ClickFix Today 

Visit www.appguard.us to explore controls-based protection or reach out to sales@appguard.us.

AppGuard — Stops malware EDR/XDR miss.

Bonus: Protecting Your Defensive Settings Themselves

Many security-conscious organizations take an extra proactive step by using Group Policy or registry settings to disable the very UI elements attackers abuse in ClickFix attacks.

For the classic Run dialog, they set the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRun = 1 (or the equivalent GPO). This completely removes Win+R functionality for standard users.

The newer Windows Terminal (Win+X → I) shortcut is harder to fully disable with a single key, but teams often set the default terminal app to the legacy console or block wt.exe via application restrictions. AppGuard makes this even simpler: if Windows Terminal is not needed for your end-users, you can simply prohibit wt.exe from launching at all with a single launch control rule.

AppGuard adds a powerful extra layer here. These configuration keys (especially HKCU-based policy settings) are typically not isolated by default. However, you can easily add a custom isolation rule to protect the specific registry path HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer (and related Win+X keys if used).

Once isolated, no process — malicious or otherwise — can modify those defensive settings. This locks down the organization’s own hardening measures so future ClickFix variants (or any other attack) cannot simply re-enable the shortcuts.