I created a mitigation tool that can be used to fix/remove the worm from all infected repositories, and did a writeup about this.
On Monday, the Hades campaign introduced Composer, Go and Pip support. Before that it had only support for NPM and AI assistant editors. (Well, and Ruby btw but nobody uses Rubygems anymore it seems).
What even Microsoft gets wrong: This is the first worm that runs on all platforms in the code ecosystem. Developer host machines, servers, ci/cd runners. And all of them spread the worm to all repositories that are accessible on those machines.
You would have to completely shutdown 100% of all computers AND aws ec2 AND google cloud platform AND azure AND kubernetes clusters AT THE SAME TIME to beat this worm. It literally spreads across all infrastructure.
Kill switch, as always with APT28 malware, is setting the host language to ru_RU.KOI8-R (LANG environment variable). That disables the spread mechanism.
My Mitigation Tool (I'm updating it as new package systems are targeted ...):
https://github.com/cookiengineer/antimiasma
Blog post:
https://cookie.engineer/weblog/articles/malware-insights-mia...
It only spreads if you run the code...
No, it spreads if you open a folder. That's the point why developers all underestimate the worm's capabilities.
This ^
In a tool that's dumb enough to run code from untrusted folders.
`cd folder` does nothing.
> "cd folder" does nothing.
That's like recommending to use the xterm on Windows. Statistically, nobody uses their computer that way anymore. The world has moved on since the 1990s.
I was only not affected because I use a heavily customized VIM, but even there can I not control how package managers like npm, pip or composer or go are behaving, because they will happily execute the malware payloads on install.
And time wise it's an absurd thing to ask people to manually download all whl files of all their dependencies, extract all those files, and then check whether there was malware in them or not. It's simply not possible to do manually.