Kwaadaardige npm-pakketten verbergen hun loader in gewone JavaScript-code; malware start pas wanneer een applicatie de dependency gebruikt, niet tijdens de installatie, meldt Checkmarx.
Voor Nederlandse softwareteams verschuift daarmee de grens van dependency-beveiliging. npm v12 blokkeert installatiescripts, maar een pakket dat tijdens normaal gebruik kwaadaardige code uitvoert, komt alsnog door die poort. De inzet is de CI/CD-omgeving zelf: wat lokaal of in een build-runner draait, werkt mogelijk binnen dezelfde omgeving als broncode, tokens en cloudtoegang.
De aanval zit in een gewone methode
De campagne draait om indexed-btree, een pakket dat de legitieme B-tree-bibliotheek sorted-btree nabootst. Er staat geen preinstall of postinstall in package.json. De loader zit in BTree.prototype.set, een methode die gebruikers volgens Checkmarx voortdurend aanroepen. Bij een specifieke sleutelwaarde start de code een verborgen bestand met een eerste malwarefase.
De applicatie hoeft dus geen verdachte functie te importeren. De methode die bij normaal gebruik hoort, is de ingang. De code maakt een los Node-proces aan en laat fouten stil vallen, waardoor een statische controle die vooral package.json en installatiescripts bekijkt groen licht kan geven. BleepingComputer meldt dat npm's nieuwe maatregelen lifecycle-scripts zoals preinstall, install en postinstall blokkeren tenzij ze expliciet zijn toegestaan, maar die rem beoordeelt niet automatisch wat een pakket tijdens gebruik doet.
Twee versies en miljoenen downloads
OSV, met een melding van Amazon Inspector, noemt versies 2.1.1 en 2.1.2 van indexed-btree als getroffen. Checkmarx rapporteert voor het pakket bijna 2 miljoen wekelijkse downloads op het moment van de analyse. Daarmee gaat het niet om een obscure dependency die alleen in een verlaten hobbyproject stond.
De onderzoekers koppelen daarnaast negen verwijderde npm-pakketten aan dezelfde operatie. In de gepubliceerde telling staat btree-core op 1.951.274 downloads; zeven van de negen pakketten zitten boven 400.000. De pakketnamen klinken als gewone hulpprogramma's voor indexen, wachtrijen en caches, precies het soort code dat via een andere dependency ongemerkt in een applicatie kan belanden.

De malware wacht op gebruik
Na activatie verzamelt de code informatie over het systeem, waaronder architectuur, hostnaam, processor, geheugen en uptime. Die gegevens gaan naar hardcoded kanalen op Slack en Telegram. Voor de besturing gebruikt de malware een smart contract op het Sepolia-testnet als verwijzing naar een volgend adres. Met X25519, ECDH en AES wordt een tweede payload uit de blockchain ontsleuteld.
Die constructie maakt het lastiger om de commandostructuur weg te nemen door één domein of IP-adres te blokkeren. De loader kan bovendien zijn eigen bestanden verwijderen en de trigger uit de prototypefunctie halen. Een incident kan daardoor verdwijnen uit een omgeving voordat een onderzoeker de oorspronkelijke code opnieuw bekijkt.

De grens verschuift van installatie naar runtime
De werkwijze bouwt voort op eerdere npm-aanvallen, maar de technische les is anders. Bij de npm-worm die in augustus honderden pakketten besmette via een gekaapt maintainer-account lag de eerste ingang in een preinstall-script. Bij indexed-btree lijkt de installatie schoon en begint de aanval pas wanneer de applicatie de bibliotheek gebruikt.
Dat maakt installatiescripts blokkeren nog steeds nuttig, maar niet afdoende. De gids voor het beveiligen van een AI-automatiseringsstack met lockfiles, npm ci en scanners beschrijft de laag die voorkomt dat een onverwachte dependency je build binnenkomt. Deze campagne laat zien dat er daarna nog een tweede vraag ligt: welk gedrag vertoont de code wanneer de build of applicatie echt draait?
De relevante scheidslijn is daarom niet langer geïnstalleerd versus niet geïnstalleerd, maar gecontroleerd gedrag versus onbekend gedrag. Wie alleen de eerste status meet, ziet een schone dependency. Wie ook runtime en runner observeert, ziet de echte grens van zijn softwareketen.
Veelgestelde vragen
Afhankelijkheden onder controle
Ik breng je softwareketen in kaart, ontwerp de controles rond je eigen proces en bouw ze in je CI en automatiseringen in. Van meedenken en ontwerp tot realiseren en automatiseren, self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
