Onderzoekers ontdekken tweede golf van malware in npm-packages

Verschillende onderzoekers melden een tweede golf van malwareaanvallen via npm‑packages die gebaseerd lijkt te zijn op de 'Shai‑Hulud'‑malware. De malware zou bedoeld zijn om credentials te stelen en vernietigt gebruikersgegevens als er maatregelen tegen worden genomen. Het is niet duidelijk hoeveel systemen getroffen zijn door malafide software.

Onder meer GitLab en beveiligingsbedrijf Aikido hebben het over een tweede golf van Shai-Hulud-aanvallen. De malware wordt nog steeds via gecompromitteerde npm-packages verspreid en gebruikt Trufflehog om secrets op te sporen, waaronder api-keys, cloudtokens en credentials voor GitHub en npm. De worm publiceert vervolgens kopieën van zichzelf via de packagemanager npm. Tweakers schreef onlangs een achtergrondartikel over npm-packages.

Onder meer packages van Zapier, ENS en AsyncAPI zouden getroffen zijn. Ook PostHog en Postman zijn getroffen en hebben de aanval erkend. Het gaat om bijna 500 geïnfecteerde packages, die bij elkaar volgens Aikido maandelijks 132 miljoen keer gedownload worden.

In tegenstelling tot de eerste golf van deze supplychainaanval, worden de gestolen gegevens niet naar een openbare GitHub‑repository geüpload, maar wordt er een repository met een willekeurige naam gemaakt. De beschrijving van de repository's is wel altijd hetzelfde, namelijk 'Sha1-Hulud: The Second Coming'. Er zouden al ruim 26.000 van dergelijke repo's op GitHub te vinden zijn. Op het moment van schrijven zijn er overigens minder dan 14.000 zoekresultaten voor deze beschrijving.

Daarnaast is er een 'dead man's switch' in de malware verwerkt. Hiermee worden gegevens in de Thuis-map van gebruikers verwijderd wanneer de malware de toegang tot zijn exfiltratiekanaal verliest. De malware zou automatisch andere packages van gebruikers kunnen infecteren. Dat kunnen er tot 100 zijn, terwijl dat er voorheen nog maximaal 20 waren.

Onderzoekers van GitLab adviseren ontwikkelaars die met npm-packages werken om te controleren of er bijvoorbeeld een verborgen Trufflehog-map of -bestand op een systeem te vinden is. Daarnaast zijn er bepaalde processen en commando's die op een infectie wijzen. Ook is het gebruikelijk om alle secrets te vernieuwen.

Reacties (42)

[bobberg]

Iemand al een tool gevonden waarmee je de packages kan checken?

[Craimasjien]

Je kunt de volgende indicators of compromise bekijken om te kijken of je repositories packages bevatten die de code heeft uitgevoerd.

Wat je kan doen om je packages te onderzoeken is de npm, pnpm of yarn lock files bekijken. Wat ik mijn teams heb aangeraden is om het volgende command te draaien (aangenomen dat je op Linux/MacOS zit) in de map waar alle git repo's staan opgeslagen:

grep -rE --include='*lock*' "(@asyncapi|@posthog|@zapier|@ensdomains|@voiceflow|@kvytech|@mcp-use|@trigo|@actbase|@hover-design|@louisle2|@dev-blinq|@fishingbooker)" .

Dit zou je de paden terug moeten geven waarin deze paketten gevonden zijn, dit zijn pakketten waarvan het bekend is dat ze besmet zijn (geweest).

Ook raad ik je aan om voorlopig even niks te updaten aan de hand van npm update/pnpm update totdat je zeker weet dat je packages gebruikt die niet (meer) besmet zijn.

[svane]

Je kunt de volgende indicators of compromise bekijken om te kijken of je repositories packages bevatten die de code heeft uitgevoerd.

Goede link, bedankt.

grep -rE --include='*lock*' "(@asyncapi|@posthog|@zapier|@ensdomains|@voiceflow|@kvytech|@mcp-use|@trigo|@actbase|@hover-design|@louisle2|@dev-blinq|@fishingbooker)" .

Dit is wellicht beter dan niks, maar pas op dat je hiermee wel de helft van de geïnfecteerde packages overslaat. Dit kan leiden tot een vals gevoel van veiligheid. Beter om alles door te lopen

Hier is de volledige lijst te vinden.

[Craimasjien]

Bedankt voor je aanvulling @svane, ik heb de grep geschreven met alle informatie die ik op het moment van schrijven tot mijn beschikking had. Ik heb onderhand een langere grep geschreven die inderdaad de lijst aanhoudt waar jij aan refereert.

Maar nog beter; ik heb besloten niet zelf te hannessen met bash en ben gebruik gaan maken van deze tool.

[svane]

Begrijp ik helemaal! Was niks mis met je reactie, maar het was even een algemene waarschuwing dat er inmiddels meer info beschikbaar was! Misschien klonk ik wat te negatief

Zelf moest ik ook even snel zoeken om zeker te weten of mijn repositories gespaard waren gebleven.

Ik heb dezelfde tool ook even gerund, maar kreeg wel wat false positives over Prisma packages, bij jou geen last van?

[.net]

Je kunt ook deze gebruiken: https://github.com/Cobenian/shai-hulud-detect

edit:
De ironie van het gebruiken van een externe package/script is me zeker niet ontgaan. Uiteraard altijd opletten en valideren voor je scriptjes gaat runnen.

[Reactie gewijzigd door .net op 26 november 2025 07:28]

[Martinspire]

Ik geloof je oprecht dat het een goede package is, maar een random package gebruiken om malware te detecteren is ook wel een leuke extra attack vector... Goed nadenken dus voordat je dit soort code draait.

Ik vind eigenlijk dat dit soort dingen vanuit NPM moeten komen om wat meer duidelijkheid te scheppen in de betrouwbaarheid.

[Reactie gewijzigd door Martinspire op 25 november 2025 23:04]

[base_]

Die https://github.com/Cobenian/shai-hulud-detect is letterlijk een shell script en een .txt bestand met package namen, en dus juist niet een package met mogelijk besmette dependencies. Wat ik nu vooral niet vertrouw zijn NPM packages
En ja bij twijfel moet je dat hele script wel even goed bekijken voordat je het uitvoert, spannend plaatje ook waarmee die readme begint.

[Martinspire]

Gast, het is een shell script van 2400 regels. Langer dan menig privacy policy...

Verder zijn er genoeg mensen die geen shell script kunnen lezen. Maar je geeft het toegang tot dezelfde resources als zo'n postinstall script en wat er nu staat kan weer anders zijn dan wat er over een paar dagen in komt te zitten.

[.net]

To be fair, als je op Github rond gaat hangen mag je wel verwachten dat je enige kennis van scripting of coding hebt.

Verder wel eens dat er een rol voor NPM ligt in dit soort dingen. Ik wil je er wel op wijzen dat deze attacks ook private NPM feeds raken, dus het is niet altijd zo makkelijk als het soms lijkt in eerste instantie.
Persoonlijk voel ik er veel meer voor dat NPM support voor post-install scripts volledig weghaalt, het is steeds weer gedoe met dit soort 'magic'.

[Reactie gewijzigd door .net op 26 november 2025 07:32]

[Martinspire]

Het gaat helemaal niet over de taal, het gaat erom dat het 2400 regels zijn. Dat is niet even een quick scan en overheen te scannen of het legit is. Dan zitten er teveel variabelen in waarmee men misbruik kan plegen.

[jaenster]

Nvm; ik had niet goed gelezen, my bad :)

[Reactie gewijzigd door jaenster op 26 november 2025 16:48]

[Jerie]

To be fair, als je op Github rond gaat hangen mag je wel verwachten dat je enige kennis van scripting of coding hebt.

Pertinente onzin.

[Guru Evi]

JFrog Enterprise, Snyk, Qodana, GItHub/GitLab Enterprise en een reeks andere tools, sommige zijn gratis/freemium voor hobby, onderzoekers, educatieve en open source projecten. Ik weet niet of er een “open source” pakket is omdat dit soort beveiliging een voltijdse functie is voor duizenden mensen binnen de voorgenoemde bedrijven.

[Reactie gewijzigd door Guru Evi op 26 november 2025 04:02]

[lenwar]

Een willekeurige virusscanner lijkt mij? Het verbaast me ook eerlijk te zijn dat dit niet aan de repo-kant gebeurd, maar dit zal je dus ook op je eigen apparaten moeten doen. Windows en MacOS worden er standaard van voorzien. Linux en UNIX moet je zelf even regelen.

[cracking cloud]

Met deze gist: https://gist.github.com/michaelbromley/ccb954b5224bce3798cceaa137cc3bbb

[Martinspire]

Deze is wat lastiger te zien qua infectie zo te merken. Maar alsnog niet geraakt. Ben blij met de laatste PNPM features zoals het verplichten dat packages pas na een x uur kunnen worden geïnstalleerd en het voorkomen van uitvoeren van postinstall scripts. Wel ben ik nog op zoek naar een goede tool om de packages nog eens extra te scannen en wellicht een mirror te gebruiken voor als er weer eens wat met Github aan de hand is.

Verder hoop ik dat NPM toch eens zelf tools gaat releasen om te scannen of je geraakt bent met dit soort aanvallen. Want het is lastig en men maakt allerlei (vibe coded) tooltjes waarvan je de betrouwbaarheid ook niet kunt valideren en die net zo goed een extra aanvalsvector kunnen zijn.

[bobberg]

Ik weet niet of je op mijn project duid, maar de code is inzichtelijk en niet bepaald veel.

[Jerie]

Je zou kunnen zeggen het is beter dan niets. Je zou ook kunnen zeggen je weet niet wat je code doet want je hebt het niet zelf geprogrammeerd. Ik denk dat code gegenereerd door LLMs als zodanig moet worden aangeduid. Dat deed je hier.

Zelf gebruikte ik sudo -E $HOME/.cargo/bin/rg -. -g '*lock*' -P "(@asyncapi|@posthog|@zapier|@ensdomains|@voiceflow|@kvytech|@mcp-use|@trigo|@actbase|@hover-design|@louisle2|@dev-blinq|@fishingbooker)" /

Want rg biedt 2x betere performance dan grep:

<sub>$ time grep -rE --include='*lock*' "(@asyncapi|@posthog|@zapier|@ensdomains|@voiceflow|@kvytech|@mcp-use|@trigo|@actbase|@hover-design|@louisle2|@dev-blinq|@fishingbooker)" $HOME

real 0m0.703s
user 0m0.240s
sys 0m0.411s

$ time rg -g '*lock*' -P "(@asyncapi|@posthog|@zapier|@ensdomains|@voiceflow|@kvytech|@mcp-use|@trigo|@actbase|@hover-design|@louisle2|@dev-blinq|@fishingbooker)" $HOME

real 0m0.397s
user 0m0.263s
sys 0m0.250s</sub>

En ja, ik heb het meerdere malen geprobeerd. Dit zijn niet de outliers (idealiter voer je het 100x uit en neem je het gemiddelde maar ik denk dat het punt is gemaakt). Vervolgens ben ik ook maar hidden files gaan speuren, en meteen even gehele / scannen.

Ik zou iemand die rg zou gebruiken toch even aanraden om de manpage te lezen. We voeren veel te gemakkelijk code uit die we niet begrijpen of lezen. Dat is hier ook de zwakte geweest. Eigenlijk wil je ook nog .gitignore negeren (standaard respecteert rg deze), dat kan middels -uuu of --no-ignore

[Reactie gewijzigd door Jerie op 26 november 2025 04:35]

[svane]

Je zou kunnen zeggen het is beter dan niets. Je zou ook kunnen zeggen je weet niet wat je code doet want je hebt het niet zelf geprogrammeerd.

Het is mogelijk om code te begrijpen die je niet zelf hebt geprogrammeerd... Ik vind 't nog wel beledigend overkomen als je beweert dat @bobberg deze code niet kan begrijpen, zo ingewikkeld ziet het er ook niet uit.

Zelf gebruikte ik sudo -E $HOME/.cargo/bin/rg -. -g '*lock*' -P "

Leuke tool, en mooie aanrader. Ik weet echter niet of het in dit specifieke geval aan te raden is om een externe tool die zelf ook weer rond de 10 dependencies heeft, te gaan installeren als je toch al grep op je systeem hebt. Dit hele artikel gaat immers over dependencies waar malware in zit. voor die 0,3 sec zou ik grep prima vinden.

[Jerie]

Bij echt programmeren weet je dat in ieder geval één mens het heeft gelezen. Bij vibecoden is het gebaseerd op... niemand die dat weet. Attributie doen veel LLMs niet aan. Doen ze dat wel, had je ook net zo goed zelf het kunnen bouwen. Daarnaast zit je nog met auteursrecht.

Ik ga gewoon mijn hele NAS na. Eigenlijk zou ik ook nog Docker volumes moeten checken.

[svane]

En tóch zitten we hier te reageren op een artikel over malware die zich bevindt in 500+ packages die niet door AI zijn geschreven..... Blijkbaar heeft het niet heel veel geholpen dat minstens één mens deze code gelezen heeft.

In dit geval zegt @bobberg zelf de code te hebben gelezen en gecontroleerd. Niet heel lastig te geloven zou ik denken. Als je de auteur niet gelooft dan maakt het toch ook helemaal niks uit of er AI tool gebruikt is? Sterker nog, ik moet echt mijn best doen om een AI tool kwaadaardige code te laten schrijven.... juist dat is iets wat mensen zonder geweten beter kunnen.

Stel dat @bobberg had gelogen en zou beweren de code zelf te hebben geschreven, had je het dan meer vertrouwen gehad in de code? Was er dan minder kans op malware in de code?

De auteur van deze andere code heeft ook lopen vibe-coden. (zie de .claude uitzondering in de .gitignore). De enige reden dat deze post wel op +1 staat, is omdat niemand de moeite heeft genomen dit uit te zoeken.

Ondanks dat deze code gemaakt is door een onbekende programmeur met slechts één actieve repository, en een website uit 't jaar nul, zonder https certificaat, en met tig dode links, wordt deze repository hier wél vertrouwd. Vraag jezelf eens af waarom dat is, puur omdat onze mede-gebruiker hier wél eerlijk was over het gebruik van AI? Verdient hij daarom écht 43 moderaties op -1?

[Jerie]

En tóch zitten we hier te reageren op een artikel over malware die zich bevindt in 500+ packages die niet door AI zijn geschreven.....

(Niet door AI geschreven -> dat zeg je wel heel stellig.)

Blijkbaar heeft het niet heel veel geholpen dat minstens één mens deze code gelezen heeft.

Toch is het minder risicovol dan dat helemaal niemand de code heeft gelezen. Het probleem met NPM is dat men heel erg leunt op de meest triviale content voor libraries. Het is algemeen bekend dat de barrier of entry binnen JS en Python gemeenschap zeer laag is. Dan krijg je ook veel rommel van amateurs. Die zwakte is ook al eerder aangetoond. O.a. https://xkcd.com/2347/ gaat hierover

Stel dat @bobberg had gelogen en zou beweren de code zelf te hebben geschreven, had je het dan meer vertrouwen gehad in de code? Was er dan minder kans op malware in de code?

Ik vind het goed dat hij er eerlijk over is. Dat schreef ik ook in mijn eerste reactie:

"Ik denk dat code gegenereerd door LLMs als zodanig moet worden aangeduid. Dat deed je hier."

Wat betreft die andere code, je hebt gelijk dat die dan ook niet op +1 hoort. Je hebt hier ook een attack vector te pakken.

Echter, de meest informatieve post in dit hele draadje is nog altijd deze:

Craimasjien in 'Onderzoekers ontdekken tweede golf van malware in npm-packages'

Om twee redenen: 1) Deze linkt direct naar indicators of compromise, en 2) deze bevat 1 simpel CLI commando om een directory te scannen. 1 simpel CLI commando die maar 1 binary gebruikt, namelijk grep. Een binary die op ieder systeem zit. Ik verfijn de performance vervolgens (voor degenen die hun hele / willen scannen) en dan krijg ik van jou bepaalde kritiek. Kijk ook maar eens naar die moderaties.

Verdient hij daarom écht 43 moderaties op -1?

Mijn antwoord hierop weet je gezien bovenstaande (zie mijn quote van mezelf) denk ik wel. Echter, die discussie hoort hier niet thuis. Ik heb bij mezelf de moderatierechten uitgezet.

[Reactie gewijzigd door Jerie op 28 november 2025 02:55]

[bobberg]

Thanks voor de feedback. Het script heb ik toch echt helemaal nagelopen voordat ik het commit, dus ik weet wel wat het doet. En het script had mijn hele documenten folder van vele gigabytes binnen paar seconden doorzocht, dus ik vind het allemaal wel meevallen. Ondertussen is het toch helemaal weg gedownvote. Geeft goed aan hoe anderen hier over dit soort werk denken.

[SPee]

Als ik rg uitvoer, dan krijg ik het volgende:

-bash: rg: command not found

Ik zou iemand die een oplossing aanbied toch even aanraden om bij de standaard linux tools te blijven die iedereen op zijn systeem heeft staan. We gaan veel te vaak uit van het eigen ecosysteem en plukken tools van het internet die maar ergens online genoemd worden. Je weet niet wat dat tooltje doet. Liever een leesbaar scriptje met iets vertraging, dan een obscure exe.

[Martinspire]

Ik zag er 1 voorbij komen met 2400 regels aan bash script, dus dat vind ik teveel om zo even te scannen op malware.

[Memori]

npm view [package] time --json
npm install [package]@"[versie]"

Ik installeer sinds de Shai-Hulud malware nooit meer versies jonger dan twee weken.

[HollowGamer]

Ik check de changes/commits. Zoveel tijd kost dat niet.

Het probleem is dat je hier vrij weinig tegen kan doen. Als je een package installeert, heeft die mogelijk ook weer dependency die je helemaal niet weet. Die kan dus ook malware hebben.

[N0 0B]

Dat zit dan toch in je changelijst die je doorloopt? Maar ja dan ben je wel recursief bezig om alles te doorgronden, wat veiligheid ten goede komt. Niets is gratis.

[HollowGamer]

Van beide ben ik al een tijd overgestapt naar alternatieven, of gebruik het via de editor zelf.

Soms vraag ik mij af hoe dit kan? De packages zitten dus op de repo (doen zij niet een pnpm install?), en er is toch een bot die kan kijken of packages veilig geupdated kunnen worden?

[R4gnax]

Uit het bronartikel van Aikido:

If it can't authenticate with GitHub or NPM, it will wipe all files in the users Home directory.

Nice. Lekker spiteful.
Als je dus geinfecteerd raakt en enkel NPM intern gebruikt binnen je organisatie, met mogelijk een interne package repository, dan gaan deze rotzakken gewoon voor het secundaire doelwit: maximale schade voor de getroffene.

[henk717]

Dat is genuanceerder, er zit een stap in waarbij die de eerdere gevangen credentials van anderen download om vervolgens met die van hun te uploaden. Het is vooral een manier om github te dwingen dit niet zomaar te blokkeren, doen ze dat wel en mislukt de aanval wordt het een wiper.

[Goldwing1973]

Lijkt erop dat Github al actie heeft ondernomen om ze onvindbaar te maken.
Als ik op Github zoek naar 'Sha1-Hulud: The Second Coming' dan krijg ik gelijk

Too many requests

You have exceeded a secondary rate limit.

Please wait a few minutes before you try again;
in some cases this may take up to an hour.
Signing in may provide a higher rate limit if you are not already signed in.

En via Google zijn ze ook niet (meer) te vinden
site:github.com Sha1-Hulud: The Second Coming

[Reactie gewijzigd door Goldwing1973 op 26 november 2025 10:23]

[cracking cloud]

Hoe lang is NPM nog houdbaar?

Naast de dependency hell ook nog deze ongein erbij

[Martinspire]

Ze hebben gewoon als doelwit de populaire package managers. Net zoals Windows vaak doelwit is.

[SPee]

Alleen zijn de grootste (en succesvollere) aanvallen op het NPM ecosysteem. Andere programmeertalen hebben ook een (de)centrale repository met veelgebruikte libraries. Dus daar een succesvolle aanval plegen, zorgt ook voor vele infecties. Maar toch is de intensiteit van aanvallen daar een stuk lager.

Naar mijn idee:
1. Releases volgen elkaar snel op. In plaatst van een Beta release, is het gelijk een nieuwere versie.
2. Men wil "het nieuwste van het nieuwste" en is niet tevreden met een oudere versie.
3. Veel gebruik van kleine libraries (zoals een leftpad, isOdd of isEven).
4. Veel beginners met weinig kennis.

[jaenster]

1) dit gaat over upgrades van versie 1.33.6 naar 1.33.7, niet voor een nieuwe versie van 1.0.0 naar 2.0.0
2) Nieuwste van het nieuwste zijn bugfixes
3) isOdd en isEven zijn voorbeeld packages, ik weet dat het vaak aangehaald als npm staat vol met bullshit maar het is letterlijk een voorbeeld
4) Juist beginners updaten niet constant hun packages, omdat ze niet weten hoe het werkt en hebben geen pipelines of enig benul

Ik hoor een hoop onderbuik in je reactie, voeg wat constructiefs toe, zoals pnpm heeft gedaan, waarbij je kan aangeven hoe oud een release moet voor dat je het kan gebruiken. Met als nadeel dat als je een bug hebt/exploit hebt je dus langer moet wachten voor dat je deze kan gebruiken.

Je kan veel zeggen over deze attacks, maar ze zijn allemaal binnen 24 uur gedetecteert en opgelost.

[air2]

Ik denk vrij lang, zolang ze maar de actie ondernemen om dit soort ongein te voorkomen. Daar wordt momenteel hard aan gewerkt, door b.v. direct check of een wijziging wel van de correct GitHub repo komt, zodat je met enkel npm credentials niet veel kan.

[paulwump]

Ik zou toch echt blij worden van een stukje uitleg. Bij de titel haak ik al af. Dit stuk is voor niet ingewijden dus totaal onleesbaar en onbegrijpbaar. Jammer. Ga toch even het achtergrondartikel bekijken.

[PomPomPom]

Maar waarom? Is dit de achterkant van een poging Microsoft af te persen (via NPM, via Github)? Is het een poging om het hele model van Open Source de nek om te draaien? Is het een afleiding van iets wat we nu NIET zien? Is het van een groep die stoer wil doen of van iemand die ontslagen is?

Ik zie geen direct verdienmodel.

[RevXTND]

Credentials harvesten voor de volgende malware. En gezien de destructieve eigenschappen en agressieve manier van reproductie, ervaring opdoen en leren voor grootschalige disruptie.