#chaindrop worm

Traditionally, forensic analysis is often enough to find the root cause of a malware infection, and stop it or at least point the victim in the right direction of remediating it. That’s the point of this type of analysis. Worms, however, are by definition self-propagating, frequently obfuscated in logs, and now take advantage of automated updates. Knowing they’re there does little to halt their spread and remediating them usually involves restoring software to a previous version because there’s no other way to get rid of them. Especially these days, when automation translates to an inability to keep up defensively.

StepSecurity has released their analysis of the latest worm to affect npm packages. They’ve dubbed it ChainDrop, and are fairly confident this is a highly evolved descendant of Shai-Hulud 2.0. In the span of just four hours, a single hijacked maintainer repository from Jared Wray was poisoned with the malware, which then spread through 444 packages and 2,212 versions across more than a dozen victim organizations. The article has a thorough breakdown of each affected package, but in short there are two tiers of incident groups. 11 verified full worm carriers in the jaredwray ecosystem, and the worm’s own propagation into 433 victim packages republished automatically using harvested CI credentials, each carrying the Bun downloader stager and the payload. At least three of the affected npm’s garner roughly 150 million downloads a week. The worm is targeting Claude Code, VS Code and GitHub Copilot workflows, uses an Ethereum blockchain C2 (EtherHiding) as a dead drop, and has analyst-proof encrypted exfiltration.

Microsoft has also published coverage of this incident, with much of the same information as StepSecurity (albeit in a more reader friendly way). The attack was discovered because of a rapid sequence of unauthorized patch releases across the hundreds of affected packages. Their breakdown includes details on how ChainDrop functions once it’s installed. Determination of being in a CI/CD environment, which slightly changes its behavior. Credential collection from local files, environment variables, command-line tools, and GitHub Actions runner memory. Authentication to npm, GitHub, AWS, Kubernetes, and HashiCorp Vault to enumerate additional accessible resources and secrets. Encryption and exfiltration of collected data through an HTTPS channel, using GitHub repositories as a fallback. Usinh recovered npm publishing access to modify and republish additional packages. And using GitHub credentials to inject files into Claude and Visual Studio Code configurations across repository branches for persistence.

Deployment follows a consistent pattern of introducing heavily obfuscated files that execute automatically during npm install via a preinstall script, downloading a runtime and executing a second stage obfuscated payload. Its spread into unrelated repositories was accomplished through stolen maintainer credentials and tokens, likely harvested during the first wave. Worm-like propagation is quick – within minutes – and most likely automated.

The attacker compromised Jared Wray’s GitHub account, pushed poisoned release commits and tags internally, and let the projects' own release workflows ship the malware, cryptographically attested and indistinguishable from legitimate releases by any automated provenance check. Every downstream supply chain and dependency tree using these packages was affected and, because the initial wave was from a verified maintainer, no security measures were tripped at that time. The first wave of unrelated but similar release updates is what gave it away. StepSecurity and Microsoft both state that anyone with any of the affected packages should consider their system compromised and roll back their versions to a safer one, as well as rotating credentials. This is an ongoing incident and I’m sure I’ll be covering it again as more details come to light.