Attackers fetch Node.js from the official site to run their malware

Symantec's Threat Hunter Team reported on 3 September 2026 that several actors are using the signed Node.js runtime to run malware and keep it alive. Since February 2026 the attacks have hit government departments, technology companies, hotels and other organisations. In one intrusion at an Asian technology company, AdaptixC2 and Cobalt Strike payloads were blocked, after which the attackers installed Node.js from its official site and used it to run an implant. The implant is believed to have fetched its command and control data from the Ethereum blockchain, a technique known as EtherHiding.

In another attack, against a US fintech organisation, the attackers installed Node.js to deploy AdaptixC2, Cobalt Strike BEACON and finally a Rust based backdoor known as C2Looper.

What this means for you if you run endpoint security

The point of a signed and well known runtime is that it looks like something that belongs on the machine. The malware sits in a script, and what executes is a file with a valid signature from a known publisher. Block lists for unknown binaries help little when the binary is known. In the Asian case two familiar tools were stopped, and the attackers answered by fetching a legitimate program instead. That says something about how adaptable they are.

Our advice is to treat Node.js the way you treat PowerShell. An unexpected installation on a machine where nobody develops software is a signal in itself. If you have developers, you know which machines should have it, and the rest can be alerted on. Traffic to blockchain services from servers that have no reason for it is another lead worth following.

Berigo recommends

• Build an inventory of which machines have a legitimate use for Node.js, and alert on new installations outside that list.
• Monitor cases where Node.js opens network connections or spawns child processes from unusual directories.
• Block or alert on traffic to blockchain services from servers and clients that do not need it.
• Check whether your detection rules for Cobalt Strike and AdaptixC2 still catch them when they are run through a scripting runtime.
• Rehearse a scenario where the attacker switches tools after the first block, since that is exactly what happened here.