Inside the ChainDrop npm Attack: How TENEX Proactive Monitoring Caught It in Under Two Minutes

Another large-scale software supply chain attack hit the npm ecosystem yesterday morning. Dubbed “ChainDrop” by StepSecurity, the campaign follows the now-familiar Shai-Hulud pattern: a compromised maintainer account, malicious versions of trusted packages, and self-propagating code designed to spread as fast as developers can install it.

Hundreds of packages were affected, including some with more than 150 million weekly downloads. As BleepingComputer reported, the campaign ultimately compromised over 1,300 package versions representing a combined 2 billion monthly downloads. For most of the industry, the first alert came from third-party threat intelligence hours into the campaign. Our detections fired within two minutes of the first malicious packages being published.

Here is what happened, how we caught it, and why we believe this approach needs to become the industry norm.

What Happened

Early yesterday morning, a compromised maintainer account was used to publish malicious versions of popular npm packages, with widely used caching utilities such as Keyv, Cacheable, flat-cache, and file-entry-cache among the initial targets. The campaign bore the trademarks of previous attacks built on the leaked Shai-Hulud toolset, and it continued to expand throughout the day as the malware propagated to additional packages.

The worm activates through a preinstall script the moment a developer runs npm install. From there, it harvests developer and cloud credentials, including GitHub and npm tokens, AWS credentials, and Kubernetes secrets, then exfiltrates the stolen data. Because it can republish itself through any package whose maintainer credentials it captures, every infection becomes a new distribution point.

Supply chain attacks like this are especially dangerous because they weaponize trust. Developers install packages they have relied on for years, CI/CD pipelines pull updates automatically, and malicious code rides in through the front door. By the time traditional threat intelligence feeds catch up, the code may already be running in thousands of environments.

A Two-Minute Detection Window

Multiple packages involved in the first stage of the campaign triggered our detections within two minutes of release. Seeing that some of the affected packages had over 150 million weekly downloads, we knew immediately this was a significant event. Automated triage flagged the same signatures used in earlier Shai-Hulud-style attacks.

We reported the compromised packages to npm in just over 11 minutes. Shortly after, we identified the likely root cause as a compromised maintainer account, since several other packages under the same maintainer were published with identical signatures in quick succession.

Within minutes, our Threat Intelligence, Threat Hunt, and Detection Engineering teams were engaged: identifying indicators, hunting for evidence of execution, and building and validating detections while the campaign was still unfolding. Our teams remained engaged throughout the day as the scope grew.

Why We Caught It Early

Following previous incidents, TENEX developed internal tooling to monitor tens of thousands of the most downloaded packages across multiple ecosystems. This system operates in near real-time to identify anomalies at the point of publication.

The detection capability is based on proactive monitoring of the supply chain rather than reliance on external threat intelligence feeds.

The monitoring framework focuses on three primary objectives: minimizing detection latency at the source, accelerating indicator generation for threat hunting, and deploying validated detections in the initial stages of a campaign.

This methodology represents a shift from reactive to proactive managed detection and response (MDR). By monitoring package registries directly, threats can be identified and mitigated before they are widely reported by third-party intelligence sources.

This is part of a broader shift in how we think managed detection and response should work. The MDR and MSSP industry has traditionally been reactive: waiting for an alert indicating a user, endpoint, or other client asset has been attacked. We think the better model is to go find the threats where they originate.

Where Things Stand

Threat hunting across monitored environments using the indicators associated with this campaign found no evidence of compromise. Hunters identified the Bun runtime executing in a small number of environments, but assessed it as legitimate developer activity rather than attacker behavior.

The scope of the attack continues to expand, and we are monitoring developments and updating detections as new indicators emerge.

The Takeaway

ChainDrop will not be the last attack of its kind. The Shai-Hulud playbook is public, and the npm ecosystem remains an attractive target because a single compromised maintainer account can reach millions of downstream users.

The lesson for defenders is that speed matters, and speed comes from position. If your first signal arrives from a third-party feed, you are already behind. Monitoring the package ecosystems directly at the source turns a supply chain attack from a surprise into an event you can measure within minutes.

That is the standard we hold ourselves to, and the one we think the industry should expect.