Your endpoint detection just blocked another phishing email. Your web proxy flagged a suspicious download. But ClickFix attacks don't look like traditional malware delivery—they mimic legitimate troubleshooting steps. ESET measured a 517% jump in ClickFix usage from late 2024 into the first half of 2025. Recent analysis of 3,000 live payloads reveals why: these attacks use API-driven servers to generate unique payloads on demand, bypassing signature-based detection entirely.
This checklist covers the specific controls you need to detect and prevent ClickFix attacks, which now have their own MITRE ATT&CK designation (T1204.004). Each item maps to either behavioral detection capabilities or policy enforcement that blocks the attack chain before execution.
Prerequisites
Before implementing these controls, verify your environment meets these baseline requirements:
- Endpoint visibility: Monitor PowerShell execution, script execution policy changes, and clipboard operations across all endpoints.
- Network inspection: Ensure your proxy or firewall can decrypt and inspect HTTPS traffic from internal networks.
- Logging infrastructure: Retain endpoint and network logs for at least 90 days (SOC 2 Type II CC7.2).
- User awareness baseline: Ensure your team has completed basic phishing training within the last 12 months.
Detection and Prevention Controls
1. Monitor PowerShell Execution Context
Action: Configure your EDR to alert on PowerShell commands launched from browser processes or clipboard operations.
Why it matters: ClickFix payloads instruct users to paste commands into PowerShell. The attack chain starts with a browser, not a file download.
Requirement reference: NIST 800-53 Rev 5 SI-4 (Information System Monitoring)
What good looks like: Your EDR generates an alert within 30 seconds when chrome.exe, firefox.exe, or msedge.exe spawns powershell.exe as a child process. You receive a second alert if PowerShell executes with -EncodedCommand or -ExecutionPolicy Bypass flags.
2. Block Base64-Encoded PowerShell Commands
Action: Set Group Policy to prevent PowerShell from accepting -EncodedCommand parameters on standard user workstations.
Why it matters: ClickFix payloads frequently use Base64 encoding to hide malicious commands from casual inspection.
Requirement reference: PCI DSS v4.0.1 Requirement 6.4.3 (scripts are protected from tampering)
What good looks like: When a user attempts to run powershell.exe -EncodedCommand [payload], the command fails immediately with an access denied error. Your security team can still execute encoded commands on approved admin workstations using privileged accounts.
3. Implement Clipboard Content Inspection
Action: Deploy DLP rules that scan clipboard contents for PowerShell cmdlets, Base64 strings longer than 100 characters, and encoded command patterns.
Why it matters: Users copy malicious commands from fake error pages before pasting them into terminals. The clipboard is your last inspection point before execution.
Requirement reference: NIST CSF v2.0 DE.CM-7 (Monitoring for unauthorized activity)
What good looks like: Your DLP tool blocks clipboard paste operations containing Invoke-WebRequest, IEX, Start-Process, or DownloadString when the destination is PowerShell or Command Prompt. Users receive a warning explaining why the operation was blocked.
4. Restrict Script Execution to Signed Scripts Only
Action: Configure PowerShell execution policy to AllSigned on all endpoints. Maintain an internal code-signing certificate for legitimate administrative scripts.
Why it matters: ClickFix payloads are unsigned. This control breaks the attack chain even if users successfully paste commands.
Requirement reference: ISO 27001 Control 8.23 (Web filtering)
What good looks like: Unsigned PowerShell scripts fail to execute regardless of how they were launched. Your IT team signs approved scripts with your organization's code-signing certificate, and only those scripts run successfully.
5. Monitor for API-Driven Payload Generation Patterns
Action: Configure your web proxy to flag HTTP requests where the same domain serves dramatically different content to sequential requests from your network.
Why it matters: Research shows ClickFix servers generate unique payloads per request, making each attack look different. The API behavior pattern is more consistent than the payloads themselves.
Requirement reference: NIST 800-53 Rev 5 SI-4(4) (Inbound and outbound communications traffic)
What good looks like: Your proxy generates an alert when a domain returns responses with high entropy variation (indicating dynamically generated content) and those responses contain PowerShell or JavaScript commands. You investigate these domains within 24 hours.
6. Block Clipboard Access from Web Content
Action: Deploy browser policies that prevent websites from reading clipboard contents without explicit user permission per operation.
Why it matters: Some ClickFix variants attempt to pre-populate the clipboard through JavaScript, reducing the steps users must take to execute malicious commands.
Requirement reference: OWASP ASVS v4.0.3 Section 8.3.4 (Context-aware output encoding)
What good looks like: When a website attempts to access clipboard contents, the browser displays a permission prompt that expires after the current tab loses focus. Users must explicitly approve each clipboard operation.
7. Deploy Behavioral Analysis for Script Execution
Action: Configure your EDR to analyze script behavior during execution, not just at launch. Block scripts that download additional payloads, modify security settings, or establish persistence mechanisms.
Why it matters: Signature-based detection fails against ClickFix's API-driven payload variation. Behavioral detection catches the attack during execution.
Requirement reference: NIST CSF v2.0 DE.AE-2 (Potentially adverse events are analyzed)
What good looks like: Your EDR allows PowerShell to launch but monitors its behavior. If the script attempts to download files from external domains, modify registry keys related to security settings, or create scheduled tasks, the EDR terminates the process and quarantines the endpoint.
Common Mistakes
- Relying on email filtering alone: ClickFix attacks often start with compromised legitimate websites, not phishing emails. Users encounter fake error messages on sites they trust.
- Blocking PowerShell entirely: You need PowerShell for legitimate administration. The goal is to control execution context and monitor behavior, not eliminate the tool.
- Ignoring browser-based execution: Teams focus on downloaded files but miss commands executed directly from web content. ClickFix attacks never touch disk until after initial execution.
- Training users to "never paste commands": This isn't realistic. Train users to recognize social engineering patterns (fake error messages, urgent troubleshooting instructions) instead.
Next Steps
Implement these controls in order of your risk profile:
- High-value targets (finance, HR, executives): Deploy clipboard inspection and PowerShell monitoring within 30 days.
- Standard endpoints: Roll out signed script requirements and browser clipboard policies within 90 days.
- Network perimeter: Configure API behavior detection on your web proxy within 60 days.
Review your EDR behavioral detection rules quarterly. As ClickFix techniques evolve, your behavioral signatures must adapt faster than static signatures ever could.
Test these controls by simulating the attack chain in a lab environment. Have a team member visit a fake error page and attempt to paste a benign PowerShell command. Each control should trigger an alert or block the operation at a different stage of the attack.
