The growing abuse of Node.js in targeted attacks is another example of how threat actors increasingly prefer to operate through trusted software rather than introduce obviously malicious binaries. According to Symantec, attackers have been using the legitimate `node.exe` runtime in campaigns targeting government departments, technology companies and hotels since at least February 2026. The appeal is straightforward: Node.js is a legitimate, signed developer runtime, while the malicious logic can remain inside JavaScript files interpreted by that runtime. This can make the activity less conspicuous to controls that still place too much weight on binary reputation or digital signatures. In one intrusion against an Asian technology company, the attackers reportedly downloaded the official Node.js installer directly from `nodejs.org` after their previous attempts to deploy AdaptixC2 and Cobalt Strike had been blocked. Instead of abandoning the attack, they changed the execution mechanism and used a trusted runtime to establish long-term access. 

That shift is important because it illustrates how adaptable modern attackers have become. Security controls may successfully detect one malware family or block a known C2 framework, but the attacker’s objective is not to run Cobalt Strike specifically. The objective is to maintain execution and persistence on the victim. If one tool is blocked, another can be substituted. In this campaign, Node.js became the execution layer for attacker-controlled JavaScript, while registry Run keys could be used to relaunch the payload at login. The runtime itself may look entirely legitimate to endpoint security because, technically, it is. This is why allowlisting an executable based purely on publisher trust or a valid signature is increasingly inadequate. Defenders need to understand what trusted processes are actually executing, which scripts they load, where those scripts originated and what network behaviour follows.

The attack chain also demonstrates why ClickFix remains so effective. Attackers do not necessarily begin by exploiting a software vulnerability. Instead, users are manipulated into running commands themselves under the pretext of fixing an error or completing a CAPTCHA verification. Once that initial execution occurs, the attackers gain the flexibility to deploy different tooling depending on what endpoint controls allow. Symantec observed Node.js being used alongside malware families such as ModeloRAT, Mistic, GateKeeper, AsukaStealer and EtherRAT, while other related intrusions deployed AdaptixC2, Cobalt Strike and the Rust-based C2Looper backdoor. The variety of tooling suggests that Node.js is not tied to one sophisticated threat group or one narrowly defined campaign. It is becoming another execution mechanism that multiple actors can incorporate into their operations.

This should change how defenders think about developer tooling on ordinary endpoints. Node.js is perfectly legitimate on developer workstations and application servers, but its presence on systems that have no business requirement for JavaScript development or Node-based applications deserves scrutiny. An employee in finance, hospitality operations or a general administrative role suddenly installing Node.js shortly after a browser-based ClickFix event should be treated very differently from a software engineer running the same binary as part of a known development workflow. Context matters. Security teams should therefore baseline which systems legitimately require runtimes such as Node.js, Python, PowerShell, Java and other interpreters rather than treating those tools as universally benign because they are widely used.

The persistence mechanism is equally important. A registry Run key that launches Node.js with a script at every login may appear superficially similar to legitimate application persistence. The defensive signal comes from correlation. A newly installed Node.js runtime, an unfamiliar JavaScript file in a user-writable location, a recently created Run key and outbound traffic to unusual infrastructure occurring within the same timeframe form a much stronger indicator than any one of those events independently. This is precisely why modern endpoint detection needs to focus on behaviour chains rather than isolated indicators.

EtherHiding adds another layer of resilience to these attacks. In the reported campaign, compromised hosts used blockchain infrastructure to help discover command-and-control information. GuidePoint Security separately reported that at least 31 organizations had been compromised through ClickFix-style campaigns in which malicious code used the Polygon blockchain as a dynamically updateable address book for C2 infrastructure. Instead of hardcoding a single attacker-controlled IP address or domain inside the malware, the attacker can update blockchain data and effectively redirect infected systems toward new infrastructure. That weakens one of the most common incident-response actions: identify the C2 domain, block it and assume communication has been severed.

The economics of EtherHiding make the technique particularly attractive. Updating blockchain data can cost only a tiny amount, yet potentially redirect every infected endpoint simultaneously. The blockchain is not being used because criminals suddenly developed philosophical enthusiasm for decentralized finance. It provides resilient public infrastructure that defenders cannot simply take offline. Blocking one C2 server becomes temporary if the malware can retrieve a replacement location from another trusted or widely accessible service. This forces defenders to focus on the behaviour of the compromised endpoint rather than relying exclusively on destination blocking.

That does not mean organizations should attempt to block all blockchain access indiscriminately. Instead, network security teams should determine whether endpoints have legitimate reasons to query blockchain RPC infrastructure or associated services. Most enterprise desktops have very little operational need to communicate with such infrastructure directly. Unexpected blockchain-related communications from systems shortly after suspicious script execution therefore deserve investigation. Network monitoring can also correlate these communications with Node.js execution, new persistence mechanisms and subsequent connections to newly registered or low-reputation domains.

The campaign also shows how attackers combine living-off-the-land, dual-use tools and commodity malware rather than selecting one philosophy and sticking to it. Node.js may execute malicious JavaScript, which then invokes PowerShell or Windows command-line utilities, which in turn deploy additional payloads. Each stage can use legitimate software while progressively moving the system toward full compromise. Defenders therefore need visibility across process ancestry. Seeing PowerShell alone may not be meaningful. Seeing `node.exe` launch PowerShell shortly after the user executed a ClickFix command is considerably more interesting.

Application control can provide useful protection, but it needs to be implemented intelligently. Blocking Node.js outright may be practical on systems that do not require it, while developer environments may need more granular policies. Organizations can restrict execution from user-writable directories, control which scripts are permitted to execute, prevent interpreters from launching unexpected child processes and apply reputation checks to downloaded script content. The objective should not be to classify Node.js itself as malicious but to prevent an attacker from turning an unrestricted general-purpose runtime into an execution platform.

Browser security is equally important because ClickFix often begins on compromised websites. GuidePoint’s research describes attackers injecting fake CAPTCHA prompts into legitimate websites, creating two victims at once: the business whose website has been compromised and the users who trust that site enough to follow the malicious instructions. Organizations should continuously monitor public-facing websites for unauthorized JavaScript changes and unexpected third-party content. Website integrity monitoring is not merely a concern for protecting the organization’s brand; a compromised corporate website can become part of another attacker’s malware-delivery infrastructure.

Security-awareness training also needs to evolve beyond the traditional warning not to open suspicious attachments. Users should understand that legitimate websites can be compromised and that browser instructions asking them to copy commands into the Windows Run dialog, PowerShell or Terminal are inherently suspicious. A CAPTCHA has no legitimate reason to require a user to execute an operating-system command. That simple rule may be more useful than trying to teach employees to visually distinguish every new ClickFix variant.

Organizations should also monitor for unexpected downloads of official development runtimes. The fact that attackers downloaded Node.js from the genuine vendor site is an important reminder that domain reputation cannot tell the whole story. A connection to `nodejs.org` is not malicious by itself, but it may become highly relevant when observed on a non-development endpoint immediately after suspicious browser activity. Security analytics need to combine destination reputation with user role, endpoint profile and surrounding behaviour.

The broader lesson is that attackers increasingly do not need to bring their own execution environment. Modern operating systems and enterprise endpoints already contain or can easily obtain powerful interpreters, scripting engines and signed utilities. The attacker’s task is simply to persuade the system to use those capabilities on malicious instructions.

Node.js is therefore not the vulnerability here.

Trust is.

A signed executable, an official download site and a legitimate runtime can all be individually trustworthy while still participating in a malicious attack chain.

That is why defenders increasingly need to ask a different question. Instead of “Is this program legitimate?”, the better question is “Is this legitimate program doing something that makes sense on this system, for this user, at this moment?”

That distinction is becoming one of the most important boundaries in endpoint security.

Threat actors are leveraging the trusted Node.js JavaScript runtime in multiple cyber attacks as a way to deploy malicious payloads. According to a new report published by the Symantec Threat Hunter Team today, the attack method has been put to use in attacks targeting government departments, technology companies, and hotels since February 2026. "The technique's appeal is that node.exe (the

Source: Attackers Turn Trusted Node.js Runtime Into Malware Delivery Tool in Targeted Attacks via The Hacker News — published 03 Sep 2026.