Self-Replicating Worm Affected Several Hundred NPM Packages, Including CrowdStrike's (www.koi.security) 24
The Shai-Hulud malware campaign impacted hundreds of npm packages across multiple maintainers, reports Koi Security, including popular libraries like @ctrl/tinycolor and some packages maintained by CrowdStrike.
Malicious versions embed a trojanized script (bundle.js) designed to steal developer credentials, exfiltrate secrets, and persist in repositories and endpoints through automated workflows.
Koi Security created a table of packages identified as compromised, promising it's "continuously updated" (and showing the last compromise detected Tuesday). Nearly all of the compromised packages have a status of "removed from NPM". Attackers published malicious versions of @ctrl/tinycolor and other npm packages, injecting a large obfuscated script (bundle.js) that executes automatically during installation. This payload repackages and republishes maintainer projects, enabling the malware to spread laterally across related packages without direct developer involvement. As a result, the compromise quickly scaled beyond its initial entry point, impacting not only widely used open-source libraries but also CrowdStrike's npm packages.
The injected script performs credential harvesting and persistence operations. It runs TruffleHog to scan local filesystems and repositories for secrets, including npm tokens, GitHub credentials, and cloud access keys for AWS, GCP, and Azure. It also writes a hidden GitHub Actions workflow file (.github/workflows/shai-hulud-workflow.yml) that exfiltrates secrets during CI/CD runs, ensuring long-term access even after the initial infection. This dual focus on endpoint secret theft and backdoors makes Shai-Hulud one of the most dangerous campaigns ever compared to previous compromises.
"The malicious code also attempts to leak data on GitHub by making private repositories public," according to a Tuesday blog post from security systems provider Sysdig: The Sysdig Threat Research Team (TRT) has been monitoring this worm's progress since its discovery. Due to quick response times, the number of new packages being compromised has slowed considerably. No new packages have been seen in several hours at the time...
Their blog post concludes "Supply chain attacks are increasing in frequency. It is more important than ever to monitor third-party packages for malicious activity."
Some context from Tom's Hardware: To be clear: This campaign is distinct from the incident that we covered on Sept. 9, which saw multiple npm packages with billions of weekly downloads compromised in a bid to steal cryptocurrency. The ecosystem is the same — attackers have clearly realized the GitHub-owned npm package registry for the Node.js ecosystem is a valuable target — but whoever's behind the Shai-Hulud campaign is after more than just some Bitcoin.
Koi Security created a table of packages identified as compromised, promising it's "continuously updated" (and showing the last compromise detected Tuesday). Nearly all of the compromised packages have a status of "removed from NPM". Attackers published malicious versions of @ctrl/tinycolor and other npm packages, injecting a large obfuscated script (bundle.js) that executes automatically during installation. This payload repackages and republishes maintainer projects, enabling the malware to spread laterally across related packages without direct developer involvement. As a result, the compromise quickly scaled beyond its initial entry point, impacting not only widely used open-source libraries but also CrowdStrike's npm packages.
The injected script performs credential harvesting and persistence operations. It runs TruffleHog to scan local filesystems and repositories for secrets, including npm tokens, GitHub credentials, and cloud access keys for AWS, GCP, and Azure. It also writes a hidden GitHub Actions workflow file (.github/workflows/shai-hulud-workflow.yml) that exfiltrates secrets during CI/CD runs, ensuring long-term access even after the initial infection. This dual focus on endpoint secret theft and backdoors makes Shai-Hulud one of the most dangerous campaigns ever compared to previous compromises.
"The malicious code also attempts to leak data on GitHub by making private repositories public," according to a Tuesday blog post from security systems provider Sysdig: The Sysdig Threat Research Team (TRT) has been monitoring this worm's progress since its discovery. Due to quick response times, the number of new packages being compromised has slowed considerably. No new packages have been seen in several hours at the time...
Their blog post concludes "Supply chain attacks are increasing in frequency. It is more important than ever to monitor third-party packages for malicious activity."
Some context from Tom's Hardware: To be clear: This campaign is distinct from the incident that we covered on Sept. 9, which saw multiple npm packages with billions of weekly downloads compromised in a bid to steal cryptocurrency. The ecosystem is the same — attackers have clearly realized the GitHub-owned npm package registry for the Node.js ecosystem is a valuable target — but whoever's behind the Shai-Hulud campaign is after more than just some Bitcoin.
Check RFK Jr.! (Score:2, Insightful)
I'm pretty sure this one made it into his brain as well.
Re: Check RFK Jr.! (Score:2)
Re: (Score:2)
NPM is the new... (Score:3)
Excel macros. You don't even have to email the malware to people.
Re: (Score:2)
So it's difficult for a bunch of hobbyists and college kids to push back against that. If we had a functioning federal government there would be some assistance coming but we very much don't. And it's pretty obvious that the current American head of state has some dirt that's in the hands of our enemies because he's acting like a little bitch and it's p
Re: (Score:3)
Or we can just admit that Javascript is a shitty, unfixable language (read: 30-year old-tech demo spilled directly into global production) and all its infrastructure was built by neophytes trying to prove it could run with the big dogs.
Shocked (Score:5, Insightful)
I am shocked, shocked to hear, that Crowdstrike has sloppy software management practices in place!
Re: (Score:2)
Yeah, as if we needed any more reason to consider this bloated "security" software to be malware. I really don't understand why anyone in their right minds would install it or allow it to be installed on their systems. Giving some third-party company complete control over what software can run on your machines basically screams "I don't understand anything about security" better any almost anything else you could possibly do as a system administrator, IMO, short of posting the shared-across-all-machines r
Re: (Score:2)
Easy: Regulatory controls. In many environments, you get a 250+ page spreadsheet with hundreds to thousands of controls on them. There are some vendors like Crowdstrike which fill a niche that nobody else does, as they don't sell an "antivirus". So, it is either buying Crowdstrike, writing a POAM why you didn't use Crowdstrike, or taking the hit why you delibrately didn't buy Crowdstrike or something similar.
It would be nice if OS makers could put the functionality of Crowdstrike as a layer in the OS, p
Re: (Score:2)
Clownstroke has software management practices? Do you have any evidence for that?
Whoa. (Score:2)
This one is rather significant.
I wonder which private repos were made public. This could be the main prize. Industrial espionage ops?
Re: (Score:3)
In any case an abject failure of a whole community. One that does not look like it can be fixed. The whole thing should be reclassified as "amateurs only" and any professional use made illegal.
NPM needs to be burned to the ground (Score:5, Insightful)
I've never seen a software distribution mechanism as careless and sloppy as NPM. Bazillions of dependencies and no signing of packages. At the very least, NPM should start demanding signed packages (and have said packages signed by a real human being, not by some CI process with access to the signing key.)
Re: (Score:3)
Rust's cargo packaging system is almost exactly the same way. And the last time I looked, Go's packaging was very similar. And package signing won't help if the maintainer's key/cert has been exfiltrated and cracked.
This is what you get when you embrace DLL Hell -- the idea that you should pin your program to a single specific revision of a library, rather than, y'kn
Re: (Score:3)
First of all, NPN itself is a piece of junk, the "cool guys" (teenagers who think they know how to program because they managed to glue together a few bits of JavaScript) have the terrible habit of pasting everything and the kitchen sink as dependencies, even when you could (or should) write the code snippet you need yourself and thus avoid adding another 1MB of JavaScript “libs”. It's how they arrived at this absurdity of any simple application literally needing thousands
Re: (Score:2)
Sounds like, "move fast, break things, be fragile."
I guess there is just a huge amount of utility in doing this which everyone is willing to go with, and security concerns are just accepted and to some extent ignored, because why try to set up a system that is more careful and assured, when the problems might not show up for years.
Re: (Score:1)
Sure we did, it was called dpkg.
Red Hat fucked everything with RPM and then Flatpak and Snap were created as a solution in search of a problem.
Re: (Score:2)
I do not think this mess can be fixed. When it gets this badly screwed up, the participants in the disaster do not have what it takes.
Re: (Score:2)
While NPM might be easier to hack, my bet is all the major distribution systems (Maven, NuGet, ... most languages have their own) are vulnerable to the same sort of problems. The libraries are often built by open-source volunteers. Some have larger organizations behind them, but most do not. The less well-funded libraries just won't be able to defend themselves from targeted attacks. Their private keys will leak or the developer may even be just plain bribed.
As a user of these systems, all it takes is to ha