TL;DR: ClickFix attacks are surging, with reports cited by Push Security showing a 400% year-over-year rise in email-based attacks and a 517% jump over six months, while public breaches at Kettering Health, DaVita, City of St. Paul, and Texas Tech have been linked to the tactic. The real issue is that browser-driven social engineering is outpacing endpoint-first detection assumptions.
At a glance
What this is: This is an analysis of how ClickFix and FileFix attacks abuse the browser to trick users into running malicious commands, and why traditional email, proxy, and endpoint controls miss too much of the chain.
Why it matters: It matters because identity and access teams increasingly have to defend the browser as an attack surface where user action, session theft, and credential exposure can bypass controls built for older phishing patterns.
By the numbers:
- 400% year-over-year.
- another study highlighted a 517% increase in the past 6 months.
👉 Read Push Security's analysis of ClickFix and browser-based malware delivery
Context
ClickFix is a browser-mediated social engineering technique that gets users to copy and run malicious commands on their own device, often under the cover of a fake CAPTCHA or error message. The primary keyword here is ClickFix, and the governance problem is that identity controls built around email or endpoint inspection do not reliably see the user action that actually starts the compromise.
For IAM, NHI, and access security teams, the issue is not just malware delivery. It is that stolen sessions, saved browser credentials, and trusted browser profiles can turn one successful browser interaction into broader identity compromise across business apps and SaaS environments.
That makes the browser a front line identity control point, not just a delivery channel. Organisations that still treat browser-mediated execution as an endpoint-only problem are leaving a gap that threat actors are already exploiting at scale.
Key questions
Q: How should security teams detect ClickFix-style browser attacks before endpoint execution?
A: They should monitor the browser interaction that precedes execution, especially copy-and-paste into command prompts, fake CAPTCHA pages, and verification lures. Endpoint alerts are still useful, but they often fire after the key decision has already happened. The best detection strategy combines browser telemetry, process chaining, and identity context so the control triggers before local script execution.
Q: Why do ClickFix attacks evade traditional phishing and EDR controls?
A: They evade many controls because the malicious payload is often a command string, not a downloaded executable, and the user runs it through trusted system tools. Email and proxy tools may never see a stable payload, while EDR sees what looks like ordinary user-initiated scripting. That creates a blind spot between delivery and execution.
Q: What do security teams get wrong about browser-based social engineering?
A: They often treat the browser as a delivery layer rather than a control surface. In ClickFix attacks, the browser is where the attacker wins the interaction by inducing the user to copy malicious code. If teams only inspect mail, network, or endpoint events, they miss the human action that actually starts the compromise.
Q: Who should own response when a browser lure leads to credential or session theft?
A: Ownership should sit across IAM, security operations, and endpoint teams because the incident crosses identity and device boundaries. The right response is to invalidate sessions, review saved browser credentials, and investigate whether the same corporate account is active on unmanaged devices. That is how teams limit reuse of stolen access.
Technical breakdown
How ClickFix delivery bypasses email and proxy controls
ClickFix campaigns often arrive through channels that are harder to normalize than classic phishing, including social platforms, direct messages, ads, and in-app notifications. The lure is frequently a page that looks like a CAPTCHA, a Cloudflare challenge, or an error prompt, and the page content may be dynamically obfuscated or protected with runtime anti-analysis features. That makes network and email security less effective because those layers may never see a clean, stable payload. Proxy tools also struggle when the visible page context in the browser is missing and the JavaScript is intentionally fragmented or hidden.
Practical implication: detect browser-delivered social engineering at the page interaction layer, not only at mail or network ingress.
Why endpoint detection misses ClickFix and FileFix execution
ClickFix and FileFix are effective because the attacker does not need to drop a classic executable first. The user runs a command string through trusted utilities such as Run dialog, Terminal, PowerShell, or File Explorer, which means there may be no obvious file to quarantine and no Mark of the Web to inspect. The payload can be loaded in memory or injected into trusted processes, and the telemetry may look like ordinary user-driven administration unless the command sequence or parent process chain is deeply inspected. That creates a detection gap between user action and malware execution.
Practical implication: tune detections for user-level command execution and script staging, not just file-based malware events.
Why browser-level copy-and-paste is now a security signal
The strongest control point in a ClickFix attack is not the final payload but the attacker-required behavior in the browser. Every variant described here depends on the victim copying malicious script from a page before execution. That makes browser monitoring of copy-and-paste behavior valuable because it is a generic attacker action that cannot easily be removed without breaking the attack itself. The article’s core technical point is that browser-based detection can see the risky interaction earlier than endpoint tools that only observe execution after the fact.
Practical implication: instrument the browser for suspicious copy-and-run patterns and block on the interaction, not the payload.
Threat narrative
Attacker objective: The attacker wants initial code execution that becomes credential theft, session compromise, and ultimately access to business applications, data exfiltration, and ransom leverage.
- Entry begins when the victim reaches a malicious page through email, social media, messaging, ads, or in-app notifications, where the lure impersonates a CAPTCHA, error, or verification workflow.
- Escalation occurs when the page persuades the user to copy and execute a script in Run, PowerShell, Terminal, or File Explorer, turning a browser interaction into local code execution.
- Impact follows when the payload delivers remote access software or infostealer malware, steals session cookies and credentials, and can lead to ransomware or extortion.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
ClickFix exposes a browser-era identity gap, not just a malware gap. The article shows that attackers do not need to defeat every layer of the stack when the user can be manipulated into executing the payload for them. That makes the browser part of the identity attack surface because session theft, credential exposure, and SaaS compromise are downstream of the same interaction. Practitioners should treat browser-mediated execution as a governance boundary, not a nuisance alert.
Browser interaction telemetry is becoming a missing control plane for identity security. Traditional anti-phishing and endpoint controls are still useful, but they are too late when the attacker’s leverage point is the user’s copy action inside the browser. The security model here is no longer just detection of known-bad infrastructure. It is recognition of a generic attacker behavior that survives lure variation, delivery channel changes, and payload changes. Practitioners need controls that operate before the endpoint executes the pasted command.
Copy-and-run abuse is a distinct named concept: browser-mediated execution debt. The debt is the accumulation of trust in user-driven browser actions that security tooling does not consistently inspect as a control point. That matters because the attack succeeds by converting attention, convenience, and legitimacy into code execution. The implication is that organisations must stop treating copy-paste as harmless context and start treating it as an identity-sensitive action when it can trigger local execution.
ClickFix confirms that the identity blast radius now starts in the browser session. Once the browser is the place where users are induced to act, identity protections have to account for saved credentials, synced profiles, and stolen sessions as part of the same threat chain. This is not a call for heavier-handed user restriction. It is a signal that the control architecture has to see the same user action the attacker is exploiting, in real time.
Attackers are industrialising browser abuse faster than point solutions can adapt. The article’s discussion of ClickFix builders, rotating lure channels, and anti-analysis features shows a mature market for commoditised delivery. That means bespoke detections aimed at one payload family will age quickly. Practitioners should expect browser abuse to keep expanding across identity, ransomware, and infostealer operations, and they should plan accordingly.
From our research:
- Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to the same research.
- For deeper lifecycle context, see the NHI Lifecycle Management Guide for how visibility, rotation, and offboarding interact across identity programmes.
What this signals
Browser-mediated malware delivery is becoming an identity governance problem because the browser now sits upstream of credentials, sessions, and SaaS access. Teams that still separate phishing defence from identity controls will keep discovering the breach only after tokens or cookies have already been abused. As browser lures diversify, the governance question is no longer whether to block one more payload family, but whether the programme can see risky user action before execution.
The broader signal is that identity teams need to treat unmanaged browser activity as a policy boundary. Once a user can be tricked into executing code from a page, the next question is whether the same device holds synced business sessions, saved passwords, or federated access into critical apps. That makes browser telemetry, conditional access, and session invalidation part of one control set rather than separate tools.
Browser-mediated execution debt: the longer organisations rely on post-execution detection for browser-delivered attacks, the more they accumulate control debt that attackers can cash in through any lure channel. With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is moving toward broader identity visibility as a baseline expectation rather than an advanced capability.
For practitioners
- Monitor browser copy-and-paste to command execution paths Correlate suspicious copy events with subsequent execution in Run, PowerShell, Terminal, or File Explorer so the alert fires before the payload has a chance to stage or persist.
- Treat browser-delivered lures as identity attack indicators Add detections for fake CAPTCHA pages, verification prompts, and error-page lures that precede credential theft or session hijack, especially when they arrive outside email.
- Review BYOD and personal-device exposure paths Look for cases where corporate email accounts or browser profiles are used on unmanaged devices, because saved credentials and synced sessions can widen the blast radius of a browser compromise.
- Harden detections for user-driven script staging Build rules that look for obfuscated PowerShell, trusted parent process launches, and command strings executed without a downloaded file, since those patterns often bypass file-centric controls.
Key takeaways
- ClickFix shifts compromise into the browser, where user action can trigger execution before email, proxy, or endpoint tools have enough context to stop it.
- The article links ClickFix to multiple public breaches and shows why command-string execution, not file dropping, is the control gap defenders keep missing.
- Teams should move detection earlier into the browser, then tie that telemetry to session invalidation, credential review, and unmanaged-device exposure paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Browser-delivered credential theft and session abuse affect NHI trust boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Phishing and session theft are access-control problems that CSF addresses directly. |
| NIST Zero Trust (SP 800-207) | AC-7 | ClickFix exploits trust assumptions that zero trust is meant to reduce. |
Use continuous verification and session-aware controls to reduce trust in browser-originated actions.
Key terms
- ClickFix: A browser-based social engineering technique that persuades a user to copy and run malicious commands locally. The lure often looks like a CAPTCHA, error message, or verification step, but the actual objective is to turn a normal browser interaction into code execution on the victim device.
- FileFix: A ClickFix variant that uses the File Explorer address bar instead of a terminal or Run dialog to execute commands. It matters because it shifts malicious execution into another trusted user workflow, which can make detection harder for controls focused on classic shell or script launch patterns.
- Browser-based malicious copy and paste: A tactic where an attacker relies on the victim copying a script or command from a web page and pasting it into a local execution interface. The control weakness is not the payload itself but the user action, which can bypass file-centric scanning and arrive as trusted text.
- Identity attack surface: The set of user, session, credential, and access paths that attackers can use to reach business systems. In browser attack scenarios, it includes saved passwords, synced sessions, federated logins, and account reuse across unmanaged devices, all of which can expand the blast radius after a compromise.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.
This post draws on content published by Push Security: ClickFix, FileFix, fake CAPTCHA, and browser-based malware delivery. Read the original.
Published by the NHIMG editorial team on 2025-10-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org