Direct naar de inhoud
Software Supply Chain Security

Indexed-btree: malware verstopt in npm runtime-code

npm runtime malware

Een nieuw incident in de software supply chain laat zien hoe snel aanvallers zich aanpassen aan strengere beveiligingsmaatregelen. Onderzoekers van Checkmarx rapporteerden een kwaadaardig npm-pakket met de naam indexed-btree dat zijn gedrag niet via installatiehooks verbergt, maar in npm runtime malware binnen applicatiecode. Zelfs nadat npm bepaalde automatische lifecycle-scripts tegenwerkt, blijft de dreiging bestaan—alleen de plek waar de aanval “meeloopt” verandert.

Daarnaast is er ook nieuws rond de Noord-Korea gelinkte campagne PolinRider. Daarbij duikt opnieuw schadelijke code op in pakketten die via Packagist worden aangeboden, nadat eerder een malafide wijziging door Socket was opgeschoond.

Wat maakt indexed-btree anders dan “klassieke” supply chain-aanvallen?

Veel supply chain-aanvallen leunen op lifecycle-scripts zoals preinstall en postinstall. Dat zijn scripts die tijdens het installeren van een pakket automatisch worden uitgevoerd. In dit geval gebruikt indexed-btree die aanpak niet. Integendeel: het pakket doet alsof het een normale B-tree/indexing-utiliteit is en lijkt qua functionaliteit op een legitieme tegenhanger, met name sorted-btree.

Checkmarx stelt dat indexed-btree de kwaadaardige lader volledig laat draaien vanuit application code at runtime. Met andere woorden: de uitvoering vindt plaats tijdens het gebruik van de library in je software, niet tijdens de installatie van het npm-pakket.

Hoe de malware zich verstopt: van runtime methode tot versleutelde payload

Volgens de analyse zit de schuilplaats in een methode die behoort tot een “normale” indexingstructuur: BTree.prototype.set(). Op het moment dat die methode wordt aangeroepen door de hosttoepassing, wordt de kwaadaardige flow geactiveerd.

Bij die activatie wordt vervolgens een bestand gestart met de naam sharedLoad.min.js. Dit onderdeel bevat een obfuscated first stage die op zijn beurt weer andere stappen orkestreert.

De aanval bevat meerdere herkenbare onderdelen:

  • Fingerprinting van de host om context over het systeem te verzamelen.
  • Beacons en communicatie richting een hard-coded Slack-kanaal en een Telegram-bot.
  • EtherHiding om versleutelde blob-data op te halen uit een smart contract op het Sepolia testnet.
  • Samenvoegen tot een tweede-stage payload, waarna de uiteindelijke uitvoering kan plaatsvinden.

Opvallend is ook de “cleanup”-fase: na de kwaadaardige stappen verwijdert de campagne de sporen door malafide artifacts te wissen en de trigger uit de package-code terug te trekken. Daarmee wordt het moeilijker om later nog exact dezelfde techniek te observeren.

Wanneer en hoe verspreidde indexed-btree zich?

Het pakket en de bijbehorende GitHub repository zijn inmiddels offline gehaald en niet langer beschikbaar via npm. Toch geven statistieken inzicht in het bereik. De aanvaller uploadde indexed-btree op 18 juni 2026. Binnen korte tijd zou het pakket miljoenen downloads hebben gegenereerd.

Checkmarx koppelde het uploadprofiel aan de npm-gebruiker charlessadler25. Op basis van de gegevens die onderzoekers konden afleiden, zou de campagne bovendien illegale opbrengsten hebben opgeleverd ter hoogte van ongeveer €230.933,57, oftewel ongeveer 109 ETH.

Waarom npm’s install-beveiligingen dit niet oplossen

npm versie 12 introduceerde een veiligheidswijziging die automatische uitvoering van lifecycle-scripts zoals preinstall en postinstall beperkt. Voor defenders is dat een belangrijke stap: het haalt een veelgebruikte route voor malware uit de keten.

Tegelijkertijd toont deze campagne de grens van “alleen installtijd” beveiliging. Dezelfde kernles komt terug in de analyse: aanvallers verplaatsen uitvoering naar een plek die niet wordt geraakt door install-time beperkingen—namelijk naar runtime-functionaliteit die uit naam van legitieme code wordt aangeroepen.

Met andere woorden: lifecycle scripts blokkeren helpt, maar elimineert het risico niet. Het verandert vooral het speelveld. Daarom is npm runtime malware detectie cruciaal: niet alleen kijken naar wat er tijdens installatie gebeurt, maar ook naar wat de library doet wanneer je applicatie daadwerkelijk draait.

Op welke manier kun je beter verdedigen?

Onderzoekers adviseren om de focus te verbreden. Het beperken van install-time gedrag is één laag. Maar in dit soort aanvallen moet je ook runtime gedrag analyseren—bijvoorbeeld door observatie van verdachte functie-aanroepen, afwijkende netwerkconnecties en het opstarten van payload-logica die niet past bij de verwachte library-functionaliteit.

Een praktische manier van denken is “meerdere controlepunten”:

  • Voor installatie: blijven scannen op bekende verdachte pakketten en reputatie-analyse toepassen.
  • Tijdens uitvoering: runtime gedrag monitoren, inclusief modules die worden geladen, netwerkverkeer en obfuscatiepatronen.
  • Na uitrol: logs en alerts gebruiken om ongewoon gedrag alsnog vroegtijdig te stoppen.

Als je wilt begrijpen hoe aanvallers installstappen of runtime gedrag kunnen misbruiken in WordPress, is dit artikel relevant: Comment2Shell in WordPress: update nu 7.1.1. Het gaat niet om npm, maar het principe van uitvoering die “verkeerd” wordt gestart binnen een applicatieworkflow is herkenbaar.

Gerelateerde npm-accounts en pakketten: meerdere varianten uit dezelfde operatie

Checkmarx vermeldt dat indexed-btree onderdeel lijkt van een bredere reeks pakketten die samen bij dezelfde operatie hoorden. Deze pakketten zijn inmiddels ook uit de npm-omgeving verwijderd. De lijst omvat onder meer:

  • ordered-kv-index
  • btree-leaderboard
  • priority-slot-queue
  • btree-range-store
  • btree-core
  • btree-time-index
  • btree-lru-cache
  • neighbor-key-map
  • sliding-score-window
  • mutex-forge

Die parallelle varianten passen bij een patroon waarin aanvallers niet één “perfect” pakket maken, maar meerdere varianten inzetten om detectie te omzeilen en distributie te vergemakkelijken.

PolinRider op Packagist: opnieuw compromissen in ontwikkelaarsflow

Naast de npm-kwestie komt er ook een update rond PolinRider. Socket meldt dat het schadelijke code in de dev-main-versie van visanduma/nova-two-factor heeft verwijderd. Het Packagist-pakket had volgens de informatie meer dan 700.000 cumulatieve downloads.

De opvallende eigenschap van PolinRider is dat de dreigingsactor vaak eerst developer accounts compromitteert en vervolgens kwaadaardige inhoud in code repositories injecteert. Daarna zetten aanvallers routine-ontwikkelacties in als trigger: een repository clonen, openen in een IDE, of normale ontwikkeling doorlopen.

In verschillende gevallen worden payloads verstopt in ogenschijnlijk onschuldige bestanden zoals configuratie- of font-bestanden, en worden daarnaast technieken gebruikt zoals malafide VS Code auto-run tasks. Ook worden blockchain-gebaseerde verstopmethoden ingezet om staged payloads te leveren.

Wat is er veranderd in de laatste iteratie?

Socket ziet dat de nieuwste versie een nieuwe insteek gebruikt: er wordt zwaar obfuscated JavaScript toegevoegd aan index.php, en de uitvoering gebeurt via PHP’s shell_exec(). Dat betekent dat een PHP entry point de JavaScript infection chain kan starten, wat de uitvoering aanpast aan de specifieke codebase van het gecompromitteerde project.

Verder wijst Socket erop dat de compromissen mogelijk al sinds medio juni 2026 speelden binnen de betreffende GitHub organisatie. De geïnjecteerde wijzigingen zouden via de LaHiRu-developeraccount zijn ingebracht.

De overkoepelende boodschap voor teams

De combinatie van indexed-btree en PolinRider benadrukt één punt: beveiligingsmaatregelen verschuiven het gedrag van aanvallers, maar nemen de dreiging niet weg. Als install-time checks verbeteren, zoeken aanvallers naar alternatieve routes—zoals runtime-verstopte functionaliteit en het activeren van kwaadaardige code vanuit methodes die op het eerste gezicht legitiem lijken.

Wie software supply chain echt wil verzwaren, moet daarom bredere detectie inzetten dan alleen het “moment van installeren”. Observeer ook wat dependencies doen wanneer ze draaien, en controleer op afwijkingen in gedrag, communicatie en payload-opbouw.

Zo verklein je de kans dat npm runtime malware onopgemerkt door je build- en uitrolproces heen glipt.

Bron: https://thehackernews.com/2026/09/malicious-npm-package-indexed-btree-hid.html