ChainDrop

ChainDrop does not need a phishing lure at the point of infection. The delivery vehicle is a trojanized version of a package a developer already trusts. Microsoft assesses that the earliest poisoned releases were seeded using stolen maintainer credentials, after which the worm sustained itself with stolen npm publishing tokens and, in some workflows, GitHub Actions OIDC publishing. From the victim's side, the trigger is ordinary: running npm install, or a CI pipeline pulling a patch update for a transitive dependency during a routine rebuild.

The affected packages were not fringe libraries. Microsoft reported more than 400 compromised packages across unrelated publishers, including packages in the keyv, flat-cache, and cache-manager ecosystems, which sit deep in the dependency trees of a large share of JavaScript projects. That depth is the point. A team does not have to install a malicious package directly. A dependency three or four levels down is enough, which is why many organizations were exposed without any obviously suspicious action on their part.

Many malicious versions appeared as clean patch bumps with no corresponding source commit, pull request, or tag, because the attacker modified and republished package tarballs directly rather than compromising each public source repository. This is the lineage's signature: the same self-propagating worm behavior CISA warned about for the original Shai-Hulud campaign in September 2025, now delivered through preinstall execution.

Affected releases add a preinstall lifecycle script that launches a bundled file, setup.mjs, which in turn runs a large, heavily obfuscated Bun-based JavaScript payload. Because npm executes preinstall scripts before installation completes, the code runs on developer workstations and build runners before application tests or conventional security checks begin. The representative process pattern is a node process invoking node setup.mjs, which then spawns a bun child from a temporary download directory.

On startup the payload runs a short preflight. It determines whether it is on a developer workstation or in a CI/CD environment, checks the runtime environment, exits on Russian-language systems, and avoids launching duplicate instances. On workstations it detaches a background copy so it continues after the install command returns. In CI it stays attached to the active job, because that is where workflow secrets, runner credentials, and OIDC publishing permissions live.

From there the collectors run. A shell collector captures the GitHub CLI token and every process environment variable. A filesystem collector walks credential files, shell histories, cloud configuration, and SSH keys. On CI runners, the payload also reaches for credentials held only in GitHub Actions runner memory, which is why an investigation limited to files on disk can miss the most sensitive exposure.

The evasion is layered and mostly practical rather than exotic. The payload ships as a large, heavily obfuscated Bun bundle. Choosing the Bun runtime instead of Node is itself an evasion: endpoint tooling and monitoring rules scoped to Node process behavior may not inspect a Bun process the same way. The obfuscation is designed to hinder static analysis of the bundle.

Execution guardrails reduce noise and analysis exposure. The payload exits on Russian-language systems, avoids duplicate instances, and behaves differently on a workstation versus a CI runner. In one exfiltration fallback path, a stolen GitHub token is placed into the request using double Base64 encoding, which is encoding for evasion rather than encryption. Because delivery arrives through the legitimate package's own install process, there is no external dropper or email attachment to flag at the point of entry.

Command and control is deliberately resilient. Microsoft documents that the active C2 domain is resolved dynamically through an on-chain smart-contract read, with a cryptographically signed GitHub commit as a fallback source for the current domain. This lets the operator rotate infrastructure without shipping a new payload, so blocking a single domain has limited durable value. If the HTTPS channel is unavailable entirely, the worm falls back to committing encrypted results into an attacker-created public GitHub repository, using a trusted platform as its exfiltration path.

The objective is credentials, and the credential set is broad. The payload does not just scan files for token patterns; it uses the credentials it finds to call service APIs, verify access, and pull additional secrets those identities are entitled to. It authenticates to npm, GitHub, AWS, Kubernetes, and HashiCorp Vault, and enumerates packages, repositories, workflow secrets, cloud parameters, and secret-store values. Discovered GitHub tokens are validated, then used to check token scopes and enumerate writable repositories.

Collected data is serialized to JSON, gzip-compressed, and encrypted with a randomly generated AES-256-GCM key and 12-byte IV; the AES key is wrapped with the attacker's RSA public key using RSA-OAEP-SHA256. Exfiltration goes first to the dynamic HTTPS endpoint, then falls back to a public GitHub repository where encrypted results are committed as files named like results-<timestamp>-<counter>.json.

Two modifications extend the compromise beyond theft. First, worm propagation: npm tokens are checked for package-write permission and 2FA-bypass capability, then the payload downloads a package's latest tarball, copies the malware bundle in, adds a loader, replaces the lifecycle scripts, increments the patch version, and republishes. One token becomes many poisoned releases. Second, repository persistence: using stolen GitHub credentials, the worm injects loader files into .claude/ and .vscode/ configuration paths across repository branches, so future editor activity can restart the payload and infect the next developer who opens the repository. A conditional path also installs a token-monitor component that maintains access and carries a destructive handler if the monitored token is revoked.