De npm-wereld krijgt opnieuw te maken met een supply chain-aanval die niet alleen technisch slim is, maar ook strategisch: een malafide npm-pakket bereikte miljoenen downloads voordat het werd opgemerkt. Onderzoekers van Checkmarx beschrijven hoe de aanvallers beveiligingssignalen omzeilden door kwaadwillige logica te verstoppen in JavaScript-code die pas actief wordt zodra de bibliotheek draait.
In plaats van te leunen op de meest voor de hand liggende aanvalspaden (zoals opvallende install-scripts), bouwden de makers van het pakket aan geloofwaardigheid. Daardoor werd het minder snel verdacht en kon het langer blijven “meegroeien” in projecten die afhankelijk zijn van open-source modules.
Hoe het malafide npm-pakket geloofwaardigheid opbouwde
Wat deze campagne extra vervelend maakt, is de aanpak. De aanvallers kozen niet voor een directe “snelheid naar boven” door bewust bekende, extreem populaire pakketten aan te vallen. In plaats daarvan creëerden ze vertrouwen door een ogenschijnlijk nette GitHub-repository te gebruiken.
Het betreffende pakket heet indexed-btree en imiteert de legitieme functionaliteit van een B-tree/indexing-tool. Volgens Checkmarx haalde indexed-btree tot ongeveer 2 miljoen downloads per week voordat het werd ontdekt. De onderzoekers merken op dat er zelfs veel commits aanwezig waren in de repository—iets dat normaal gesproken helpt om een project legitiem te laten lijken.
Opmerkelijk genoeg bevatte de GitHub-repository niet direct de kern van de kwaadaardige code. Daarmee is de kans groter dat reviews op basis van repository-inhoud of snelle scans op de verkeerde plek blijven zoeken.
Verborgen triggers in JavaScript prototypecode
De kern van de aanval zit in hoe de malware wordt geactiveerd. De onderzoekers geven aan dat de “trigger” niet is ingebouwd via een install-script (dat door veel beveiligingsoplossingen sneller wordt gedetecteerd). In plaats daarvan verstopten de aanvallers kwaadwillige logica in de JavaScript prototypecode van het pakket.
Concreet wordt malware gelinkt aan de BTree.prototype.set-methode. Zodra de bibliotheek wordt uitgevoerd en die methode wordt aangeroepen, kan de eerste fase van de malware starten. Dit maakt het lastig om op basis van oppervlakkige inspectie meteen te zien wat er mis kan gaan: de code ziet er functioneel uit en de kwaadaardige acties liggen op een route die pas tijdens runtime zichtbaar wordt.
Wat de malware doet zodra hij actief is
Na activatie verzamelt de malware informatie over het systeem. Vervolgens stuurt de malware die gegevens naar communicatiekanalen die hardcoded in de code zijn opgenomen. Checkmarx noemt daarbij een Slack-kanaal en een Telegram-chat.
Daarna koppelt de malware aan een command-and-control (C&C) mechanisme dat gebruikmaakt van een smart contract op het Sepolia-netwerk. Het contract dient als schakel om een tweede stage op te halen: die wordt vervolgens geëxtraheerd en gedecrypt. Tot slot worden sporen op het systeem opgeschoond om detectie na de uitvoering te bemoeilijken.
Blockchain als C&C en link met eerdere aanvallen
Het gebruik van blockchain voor C&C is geen “nieuw idee”, maar het blijft wel effectief wanneer het goed wordt ingebed. Volgens Checkmarx was het gebruikte smart contract eerder terug te vinden in de mutex-forge-package. Dat wijst erop dat delen van de campagne technisch verwant kunnen zijn aan andere supply chain-incidenten.
Verder geven de onderzoekers aan dat de aanvaller met het betreffende contract naar schatting 109 ETH (bijna $300.000) heeft verdiend. Hoewel dit geen directe maatstaf is voor de impact op individuele slachtoffers, geeft het wel context over de schaal en het doorzettingsvermogen van de aanvallers.
Meer pakketten uit dezelfde supply chain-aanval
De campagne stopt niet bij één module. Checkmarx noemt meerdere pakketten die zijn gekoppeld aan dezelfde supply chain-lijn, waaronder: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map en sliding-score-window.
Sommige van die pakketten hadden volgens Checkmarx toen ze werden verwijderd zelfs meer dan 5 miljoen downloads. Daarmee ontstaat een breder plaatje: organisaties kunnen niet alleen risico lopen via één directe afhankelijkheid, maar ook via “ketens” van modules die op elkaar lijken of in dezelfde set terecht zijn gekomen.
Waarom dit type aanval zo lastig te stoppen is
Veel verdedigingsmechanismen zijn sterk in het herkennen van bekende patronen, zoals verdachte install-stappen of duidelijk kwaadaardige scripts tijdens installatie. Deze campagne omzeilt dat door de malware te verbergen binnen de packagecode en pas tijdens runtime te laten handelen via prototype-overschrijving en methode-activering.
Daarbij helpt de camouflage: een nette GitHub-repository met veel commits en een pakket dat functioneel lijkt op een bekende tool maakt het makkelijker om als “normale afhankelijkheid” in CI/CD- en build-pipelines te belanden.
Wat kun je doen als je afhankelijk bent van npm-modules?
Als je software ontwikkelt of beheert met npm, is dit soort incidenten een extra reden om je afhankelijkheden systematisch te controleren. Denk aan het beperken van het aantal externe modules, het volgen van dependency updates en het instellen van policy’s die risico’s vroeg afvangen.
Concreet kun je onder meer:
- Dependency scanning gebruiken voor bekendheid met verdachte packages en versies.
- Lockfiles (zoals package-lock.json of npm-shrinkwrap) strikt beheren zodat je bouw reproduceerbaar blijft.
- Runtime-gedrag aandacht geven: inspecteer of modules onverwachte netwerkacties of dataverzameling initiëren.
- Least privilege toepassen in build- en runtime-omgevingen zodat een compromis minder schade kan aanrichten.
Wil je bredere context over supply chain-aanvallen in JavaScript/ontwikkelketens? Bekijk dan ook eens onze artikelen over andere npm-incidenten, zoals het verhaal rond Indexed-btree en verstopte runtime-malware, dat dieper ingaat op hetzelfde thema.
Snelle check: ben je mogelijk geraakt?
De belangrijkste vraag is of jouw projecten afhankelijk zijn van de modules die in de campagne worden genoemd, en of je build-paden mogelijk precies die versies hebben geïnstalleerd.
Neem daarom de tijd om je package.json en lockfiles te vergelijken met de verdacht verklaarde lijst. Als je systemen draaien met productie-afhankelijkheden uit npm, is het ook zinvol om te beoordelen of dezelfde pakketversies eerder zijn ingezet in staging of CI.
Tot slot: als je incident response hebt ingericht, oefen dan op een “dependency-compromis”-scenario. Op die manier kun je sneller schakelen bij een ontdekking in de supply chain.
Conclusie
Deze zaak laat zien hoe ver aanvallers kunnen gaan om een malafide npm-pakket geloofwaardig te maken. Door kwaadaardige logica te verstoppen in JavaScript prototypecode en door slimme camouflage via GitHub, kon het pakket lang blijven doorlopen en miljoenen downloads verzamelen.
Voor organisaties is de boodschap helder: vertrouw niet alleen op install-time detectie, maar pak afhankelijkheidsbeheer, runtime-visibility en strikte controle op versies serieus aan. Daarmee verklein je de kans dat een schijnbaar “normale” npm-module je build- of productieomgeving ongemerkt besmet.
Bron: https://www.securityweek.com/malicious-b-tree-npm-package-accumulates-millions-of-downloads/
