TL;DR: ClickFix attacks blend social engineering with fake browser prompts to trick users into running malicious commands, and Proofpoint, Sekoia, and SentinelOne all describe rapid spread across 2024 and 2025 campaigns. The real governance gap is not detection alone but the user-execution trust model that still lets a prompt become code.
At a glance
What this is: This is an analysis of the rising ClickFix attack pattern, where social engineering pushes users to execute malicious commands or install malware.
Why it matters: It matters because the attack turns a human interaction step into execution, which stresses endpoint controls, user verification, and the identity trust assumptions behind delegated access and device-based authentication.
👉 Read Cybertrust Japan's analysis of the rising ClickFix attack pattern
Context
ClickFix is a social engineering technique that converts a fake support or verification prompt into an execution step. The user is persuaded to copy, paste, or run commands that install malware, steal data, or open a path for later access. For identity and security teams, the risk is not only endpoint compromise but the collapse of the trust boundary between user intent and code execution.
The pattern is relevant to IAM and NHI programmes because attackers increasingly use stolen sessions, browser-based prompts, and operator mistakes to reach accounts and downstream services. Once a user runs the payload, the attacker can pivot from endpoint compromise into credential theft, session abuse, or access to service consoles. That makes ClickFix a governance problem across human identity, device control, and privileged access workflows.
Key questions
Q: How should security teams stop ClickFix attacks before the user reaches the endpoint?
A: Teams should focus on browser-layer controls that detect suspicious paste events, fake verification pages, and malicious command prompts before execution begins. That approach reduces dependence on EDR alone and gives defenders a chance to intervene before the user runs code that the browser and endpoint may interpret as legitimate interaction.
Q: Why do email attacks remain effective even when organisations use MFA?
A: MFA protects the login step, but many email attacks exploit the trust placed in a compromised or impersonated mailbox after authentication. Once an attacker is inside, they can abuse forwarding, delegation, and social trust. Identity assurance has to extend beyond sign-in to message-driven business actions.
Q: What breaks when a fake CAPTCHA or browser prompt can trigger code execution?
A: When a fake prompt can trigger code execution, the organisation loses the boundary between verification and action. The user becomes an execution agent for the attacker, which means browser trust, endpoint hardening, and identity assurance all fail together. That is a governance failure because the control assumption was never valid enough for modern social engineering.
Q: How should teams respond when suspicious pasted commands are executed on a managed device?
A: Teams should treat the device as potentially compromised, revoke active browser and console sessions, and inspect identity logs for unusual access immediately after the execution event. They should also check whether privileged accounts, service accounts, or SaaS tokens were used from the same endpoint. Containment must include identity session reset, not only malware removal.
Technical breakdown
How ClickFix converts trust into code execution
ClickFix is a social engineering pattern, not a single malware family. The attacker presents a believable browser dialog, CAPTCHA, or support instruction that tells the user to perform a seemingly harmless action such as copying text or opening a shell. The key mechanism is user-mediated execution: the victim becomes the execution path, which bypasses many preventive controls that expect malicious payloads to arrive through files, links, or network downloads. Once the command runs, it can fetch a second-stage payload, alter browser state, or install persistence.
Practical implication: block or heavily constrain user-initiated shell execution paths on managed endpoints.
Why fake browser prompts defeat normal verification controls
ClickFix works because the prompt looks like a routine security or access step, so the user treats it as normal verification. CAPTCHA-style lures, fake error pages, and browser overlays exploit verification fatigue and habituated response. The attacker does not need to defeat MFA directly if they can trick the user into running a payload that captures tokens, injects code, or redirects the browser into a malicious workflow. This makes the attack especially effective where the organisation assumes that a user seen in a browser is a trusted actor.
Practical implication: treat browser-displayed prompts as untrusted content and inspect for scripted execution cues.
How ClickFix creates downstream identity and access risk
The endpoint is the first compromise point, but the real value for the attacker is what comes next. Malware installed through ClickFix can harvest browser cookies, session tokens, saved credentials, and authentication artifacts, then use them to reach email, SaaS consoles, cloud control planes, or identity providers. In an enterprise with broad delegated access, one successful user prompt can become a route into admin tooling or service accounts. That is why the attack is not just an endpoint problem but an access governance issue.
Practical implication: monitor for token theft, browser session abuse, and abnormal console access after user-driven execution.
Threat narrative
Attacker objective: The attacker aims to turn a user interaction into a foothold that yields credentials, session material, and follow-on access to enterprise systems.
- Entry occurs when the user is lured by a fake CAPTCHA, browser error, interview workflow, or support-style prompt that instructs them to copy or run code.
- Escalation follows when the pasted command downloads malware, opens a shell, or launches a second-stage payload that can access browser data and system resources.
- Impact occurs when the attacker uses stolen tokens, credentials, or remote access to move into accounts, SaaS tools, or other internal systems.
NHI Mgmt Group analysis
ClickFix is a trust-boundary attack on the user execution model. Organisations often assume the user can safely distinguish legitimate prompts from malicious ones, but this attack pattern proves that assumption is too weak. Once a prompt can cause code execution, the security model has already shifted from authentication to social engineering. Practitioners should treat this as a control design failure, not a user awareness nuisance.
Human identity controls are increasingly the first control plane attackers target. ClickFix does not need to break MFA if it can convert a person into the execution mechanism that seeds credential theft. That makes phishing-resistant authentication necessary but insufficient on its own, because the endpoint and browser still sit between identity proofing and session use. IAM teams should read this as a demand for tighter browser, device, and access-session governance.
Browser-mediated execution is now part of the access attack surface. The article’s examples show attackers using browser dialogs, fake errors, and verification pages as operational entry points. That expands the practical boundary of identity security beyond login and into session handling, download control, and script execution oversight. The security programme should therefore join IAM, endpoint, and SOC telemetry around a single incident view.
Verification fatigue is becoming a named exploitation pattern, not a side effect. When adversaries repeatedly use CAPTCHA and support-style prompts, the issue is no longer just deception but predictable operator compliance under repetitive friction. The specific governance problem is that organisations rely on human judgment at exactly the point where attackers are optimizing for impatience and routine. Practitioners should reduce the number of places where a user can be tricked into acting as the executor.
What this signals
ClickFix should change how programmes think about the boundary between endpoint protection and identity assurance. When the attacker can use a user prompt as the execution step, identity teams need stronger coordination with browser control, device policy, and session monitoring. Organisations that still treat phishing and endpoint compromise as separate problems will keep missing the handoff point where one becomes the other.
A stronger posture starts with assuming that any prompt asking for copy-paste action may be hostile until proven otherwise. That means tightening least-privilege on endpoints, watching for session reuse after suspicious execution, and aligning IAM operations with SOC triage so compromised browser activity can be contained before it reaches cloud consoles or service accounts.
For practitioners
- Restrict user-initiated command execution Disable or tightly control shell launch paths from browsers, documents, and chat tools on managed endpoints. Where full restriction is not possible, require alerting on first-time use of PowerShell, bash, or scripting interpreters launched from user sessions.
- Harden browser and session telemetry Collect browser, endpoint, and identity-provider logs into the same incident workflow so you can trace suspicious prompts through to token use or console access. Watch for unusual clipboard activity, new browser extensions, and sudden cookie or session reuse.
- Add controls for fake verification flows Train users to treat CAPTCHA, browser errors, and support prompts as untrusted until independently verified, and add URL filtering or browser isolation for pages that ask users to run commands. Pair this with rapid takedown handling for lookalike domains.
- Review privileged access after user execution events If a workstation executes suspicious pasted commands, assume browser sessions and cached credentials may be exposed. Force re-authentication for sensitive consoles, revoke active sessions, and inspect service account activity for follow-on abuse.
Key takeaways
- ClickFix turns a user interaction into a code execution path, which makes social engineering an endpoint and identity problem at the same time.
- The attack is effective because it exploits verification fatigue and browser trust, then uses the resulting foothold to reach credentials and sessions.
- Teams need tighter command-execution controls, browser telemetry, and identity session reset procedures to limit the blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001 Initial Access; TA0002 Execution; TA0006 Credential Access; TA0009 Collection | ClickFix chains social engineering into execution and credential theft. |
| NIST CSF 2.0 | PR.AC-1 | The attack exploits weak trust around user-triggered actions and access paths. |
| NIST SP 800-53 Rev 5 | SI-4 | Suspicious command execution and follow-on activity require strong monitoring. |
| CIS Controls v8 | CIS-5 , Account Management | Credential theft and session abuse make account governance central to containment. |
Map ClickFix detections to initial access, execution, and credential access techniques, then tune response around those stages.
Key terms
- ClickFix: A browser-delivered social engineering technique that persuades a user to paste and execute a malicious command, usually through clipboard manipulation and a fake instruction sequence. The key risk is that the endpoint may see a normal user action even though the payload originated from a hostile webpage.
- Approval Fatigue: The point at which repeated approval requests cause users to stop evaluating each one carefully. In agent governance, this is a control failure mode because the human reviewer becomes desensitised, making the oversight layer ineffective even though the workflow still appears compliant.
- Browser-contained execution: A control model that keeps an agent inside a managed web environment instead of letting it operate a full desktop. It limits the reachable surface, but it still requires strong policy, logging, and task scoping because web actions can expose credentials and sensitive workflows.
- Session token hijacking: The theft and reuse of an active authentication token so an attacker can enter an application without repeating the normal login process. It matters because a valid session can outlive the original password and bypass controls that only protect the sign-in step.
What's in the full article
Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:
- Campaign examples from 2024 and 2025 showing how ClickFix tactics evolved across different threat actors
- Specific lure formats used in the wild, including fake interview flows, CAPTCHA pages, and browser error pages
- Source-linked examples from Proofpoint, Sekoia, SentinelOne, and Kaspersky that map each campaign variant
- Representative screenshots and attack flow details that help analysts recognise the tactic during investigation
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org