ChainDrop: Isolate Before You Rotate, Then Hunt
A watcher checks the stolen GitHub token every 60 seconds and wipes the home directory if revocation lands first. Isolate before you rotate, then hunt.
ChainDrop: Isolate Before You Rotate, Then Hunt
ChainDrop is the Shai-Hulud worm variant that rode the tensorlake npm SDK on 8 October 2026, and its dead-man switch sets your response order: a background watcher checks the stolen GitHub token every 60 seconds and fires rm -rf ~/ if revocation lands before isolation. Isolate first, rotate second, hunt third. Everything else in this runbook follows that clock.
Socket flagged tensorlake 0.5.144 at 01:23:10 UTC on 8 October 2026, eleven minutes after publication, and npm pulled it by 02:54 according to Socket's timeline. In that window a preinstall hook dropped a Bun loader, which executed an obfuscated stealer and worm, and the release carried valid Sigstore provenance from the hijacked workflow.
What ChainDrop executes, and where
The payload never touches a Tensorlake sandbox. Socket warns that the install script runs on the developer machine or build server, outside every protection the platform sells. The sandbox vendor's own client becomes the host's problem. That inverts the trust diagram most teams draw, and it is why our untrusted code guide starts at the installer rather than the payload.
Unit42 traced the same family in the August keyv wave: a detached background process, a Bun 1.3.13 pin, and a PBKDF2 string decoder matching the Shai-Hulud toolchain JFrog documented. ChainDrop is a lineage, not an incident. Teams that isolate each workload lose a box here, not a laptop.
The sixty-second clock decides your order
After exfiltration the worm installs gh-token-monitor. The watcher queries the GitHub API with the stolen token every 60 seconds for up to 24 hours, per StepSecurity and byteiota analyses. If the token reads as revoked, it executes rm -rf ~/ on the victim machine. Revocation is therefore not the first move, and any runbook that opens with rotate everything has read the malware backwards.
Isolate at the network layer first: EDR quarantine, switch disconnect, anything that stops the host reaching api.github.com. Capture volatile memory next. Only then kill the watcher and rotate, from a clean out-of-band system, in that order. StepSecurity states the rule plainly: remove the token monitor before rotating.
The hunt list, where reinfection waits
ChainDrop plants reinfection in places installers trust. Socket and Unit42 document .claude/settings.json SessionStart hooks, .vscode/tasks.json tasks that run on folder open, a staged .claude/math_init.js payload, and fake Copilot or Dependabot workflow files pushed to reachable repositories. These are the same control-plane seams we mapped in our sandbox escape report, wearing package-manager clothes.
C2 rides Ethereum: the worm rotates roughly 60 public RPC endpoints until one answers, and the operator's contract originally listed npm-cache[.]com, pypi-get[.]com and js-mirror[.]com according to Unit42. Block the domains, and alert on serving hosts that query RPC endpoints at all, because that lookup is the cheapest signal you will ever get.
The six-step runbook
- Isolate the host at the network layer before touching credentials, so the watcher cannot see a revocation.
- Capture volatile memory and preserve lockfiles, publish logs and CI caches exactly as found, for the forensic record.
- Stop gh-token-monitor and delete its service definition, then confirm no GitHub API calls leave the host.
- Rotate everything the host held: npm tokens, GitHub PATs and OIDC configs, cloud keys, Vault tokens, SSH keys, CI secrets and AI tool API keys, from a clean machine.
- Hunt the reinfection list across every repository the identity could write, and audit npm and GitHub logs for releases your team did not cut.
- Rebuild from known-good source, never from cache, and ship egress allowlists that make the next watcher loud instead of lethal, the way our zero-public-ip playbook frames the default.
Verdict, and the caveats on this page
Our verdict: the worm is ordinary, and the order is everything. Isolation before rotation converts a hostage mechanism into noise, and the hunt list catches what the takedown misses.
- This runbook covers the ChainDrop and Shai-Hulud lineage only; unrelated npm campaigns such as MALFEX or NEBULA do not belong here and need separate playbooks.
- IOCs decay by design: the on-chain contract can rename C2 at will, so domain blocks are hours-wide controls, not fixes, which is the built-in limitation of any on-chain C2.
- In our Linux microVM fleet we only see the half of this story that runs on Linux; Windows PowerShell variants of the watcher behave differently and deserve their own validation.
- No check here proves absence. A host that installed 0.5.144 and never ran the hook still fails the compromise assumption, and correctly so.
FAQ
Why not revoke the stolen GitHub token right away?
Because the watcher treats revocation as a trigger. Every 60 seconds for up to 24 hours it checks the token, and a revoked answer fires the destructive payload before forensics finish. Isolate first, starve the check, then revoke from out of band.
Does valid npm provenance mean a package is safe?
No. The tensorlake release carried valid Sigstore provenance because the attacker published through the project's own hijacked workflow. Provenance attests where a package was built, not whether the source was poisoned, and treating it as a trust signal is how this wave spread.
Is ChainDrop still a threat after the tensorlake takedown?
The lineage is. The August keyv wave moved 444 packages and 1,381 versions per Elastic Security Labs, and the same toolchain reappears under new names. Assume future waves, keep the hunt list in your incident template, and watch maintainer accounts, not just packages.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"headline": "ChainDrop: Isolate Before You Rotate, Then Hunt",
"datePublished": "2026-10-17",
"dateModified": "2026-10-17",
"author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
"publisher": {"@type": "Organization", "name": "Krova Cloud"},
"mainEntityOfPage": "https://krova.cloud/blog/chaindrop-npm-worm-isolate-before-you-rotate"
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Why not revoke the stolen GitHub token right away?",
"acceptedAnswer": {"@type": "Answer", "text": "Because the watcher treats revocation as a trigger. Every 60 seconds for up to 24 hours it checks the token, and a revoked answer fires the destructive payload before forensics finish. Isolate first, starve the check, then revoke from out of band."}
},
{
"@type": "Question",
"name": "Does valid npm provenance mean a package is safe?",
"acceptedAnswer": {"@type": "Answer", "text": "No. The tensorlake release carried valid Sigstore provenance because the attacker published through the project's own hijacked workflow. Provenance attests where a package was built, not whether the source was poisoned, and treating it as a trust signal is how this wave spread."}
},
{
"@type": "Question",
"name": "Is ChainDrop still a threat after the tensorlake takedown?",
"acceptedAnswer": {"@type": "Answer", "text": "The lineage is. The August keyv wave moved 444 packages and 1,381 versions per Elastic Security Labs, and the same toolchain reappears under new names. Assume future waves, keep the hunt list in your incident template, and watch maintainer accounts, not just packages."}
}
]
}
]
}
