Onderzoekers ontdekken tweede golf van malware in npm-packages

Verschillende onderzoekers melden een tweede golf van malware-aanvallen 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 (13)

[bobberg]

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

[.net]

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

[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.

[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.

[bobberg]

N.a.v. je reactie even een script gevibecode:
https://github.com/bobberg/sha1-hulud-folder-checker

[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.

[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.