Cybersecurityonderzoekers hebben een nieuwe reeks malafide npm-pakketten blootgelegd die zich richten op gebruikers van ontwikkeltools van Alibaba. In deze campagne draait het niet om één losse besmette package, maar om een doordachte software supply chain-aanval: door slimme dependency-structuren wordt extra kwaadaardige functionaliteit meegeleverd tot aan een ultieme backdoor/RAT.
Voor teams die npm gebruiken in bouw- en ontwikkelprocessen is dit precies het soort incident dat je niet wilt onderschatten. Ook al zijn de aantallen downloads niet massaal, de impact kan groot zijn door de gerichte aanpak en de mogelijkheden voor laterale beweging.
Wat is er ontdekt bij deze malafide npm-pakketten?
De onderzoekers zagen pakketten die in eerste instantie lijken op onschuldig werk—of zelfs geheel zonder functionaliteit—maar later werden aangepast met kwaadaardige code. Een van de meest in het oog springende voorbeelden is lib-mtop. Dat pakket is unscoped (dus geen npm-scope zoals @ali) maar draagt dezelfde naam als een private package die onder een @ali-scope zou vallen.
De timeline is opvallend: de publicatie startte al in november 2023, en bij die eerste publicatie stond er in de praktijk geen bruikbare functionaliteit klaar. Vervolgens werden er in maart en april nieuwe versies geüpload (onder meer v1.0.1 tot en met v1.0.3) waarin wel degelijk kwaadaardige logica zat.
Van “lure packages” naar loader-logica
De kern van de aanval zit in hoe npm dependencies oplossen. Meerdere top-layer pakketten fungeren als lokpakketten en bootsten namen na van private, scoped packages. Daarmee wordt tijdens installatie de normale resolutie van afhankelijkheden geactiveerd.
Volgens de analyse zijn sommige van die lokpakketten in feite lege wrappers. Ze bevatten in hun package.json echter wel een dependency naar een pakket dat qua naam correspondeert met een private @ali-scoped variant. Daardoor ontstaat er een keten waarin extra modules worden binnengehaald.
Een cruciaal onderdeel is een loader die remote code ophaalt en vervolgens uitvoert. De uitvoering gebeurt via een mechanisme dat een JavaScript payload ophaalt met curl en die daarna draait op het systeem waar de package wordt geïnstalleerd of gemporteerd.
De dependency-keten: meerdere modules, één doel
Onderzoekers beschrijven dat de kwaadaardige functionaliteit verdeeld is over meerdere packages binnen dezelfde dependency tree. Daarbij worden top-layer packages gebruikt om de rest van de keten te activeren, waarna tussenlagen de loader-logica verbinden met de uiteindelijke kwaadaardige payload.
In de beschreven set kwam naar voren dat tot wel 10 lokpakketten kunnen leunen op een module die functioneert als een soort brug tussen de onschuldige ogende starters en de kwaadaardige modules. In één van de lagere schakels wordt daarnaast contact gezocht met een GitHub-repository om een configuratie op te halen en op basis daarvan verder te gaan.
Wat maakt de RAT-aanpak cross-platform?
Het uiteindelijke kwaadaardige gedrag is ontworpen om op meerdere besturingssystemen te werken. Daarbij wordt gebruikgemaakt van een rule engine die per OS bepaalt wat de volgende stap is. In de analyse wordt genoemd dat daarbij het vm-moduleconcept wordt ingezet om de eindfase te sturen en payload-downloads afhankelijk van het slachtofferplatform mogelijk te maken.
Ook opvallend is hoe de campagne probeert te vermommen. De payload wordt volgens de beschrijving opgehaald van een domein dat lijkt op een Alibaba-achtige naamgeving, waardoor detectie lastiger kan worden en de activiteit minder verdacht oogt. Daarmee probeert de aanvaller de aanval binnen een “normaal” ogend ontwikkel-ecosysteem te houden.
Acties op Windows, Linux en macOS
De laatste fase in de aanval verschilt per platform. De onderzoekers noemen concrete acties:
- Windows: de malware beëindigt een set app-processen van een Alilang enterprise security-, VPN- en office-productiviteitsapp en vervangt kerncode door een getrojaniseerde versie.
- Linux: er wordt een binair payloadbestand naar
/tmpgedownload, als detached proces gestart, waarna het bestand weer wordt verwijderd zodra de code in het geheugen is geladen. - macOS: er wordt een kwaadaardig achtergrondscript toegevoegd aan
~/.zshrcen er wordt een Launch Agent ingericht die gedurende 10 minuten actief blijft.
De uiteindelijke backdoor/RAT wordt vervolgens uitgerust met uitgebreide mogelijkheden: commando-uitvoering, willekeurige bestand upload/download, hostverkenning, het “staging” van payloads en zelfs laterale beweging.
Daarnaast kan de backdoor persistence opbouwen door kwaadaardige code te injecteren in veelgebruikte enterprise samenwerkingsapps zoals DingTalk, Wukong en Qoder. Dat maakt het lastiger om met één reboot of één uninstall de schade te beëindigen.
Welke ontwikkelaars lopen extra risico?
Het onderzoek geeft geen harde conclusie over de exacte dadergroep, maar wel aanwijzingen. De aanwezigheid van Chinese taalcommentaar in de code en timestamps in GitHub commits (met een UTC+08:00-offset) wijzen op een waarschijnlijker scenario: een Chinese-speaking actor die inzet op Chinese-speaking ontwikkelaars en teams die werken met tools die bij de Alibaba-omgeving horen.
De onderzoekers schatten het doel vooral als industrieel spionage. De downloads van de kwaadaardige packages zijn naar verwachting niet extreem hoog, maar doordat de aanval specifiek is en de backdoor lateraal kan verspreiden, is de werkelijke impact moeilijk te meten.
Welke npm-pakketten horen bij de campagne?
De disclosure noemt een lijst met betrokken packages. Hieronder staan de pakketten die in samenhang met de aanval zijn geïdentificeerd:
- lib-mtop
- aone-kit
- aone-kit-cli
- aone-sandbox
- local-config-parser
- smart-config-manager
- cloud-config-fetcher
- fast-transform-pipeline
- aone-cloud-cli
- colder-cli
- def-open-client
- feedback-ai-sdk
- flight-compare-analyzer
- lwp-web-client
- lzd-unified-station-sdk
- open-worker-cli
- test-skill-zip
- uniapi-bridge
Wat moet je nu doen als je een van deze pakketten hebt geïnstalleerd?
Als er in jouw omgeving één van deze malafide npm-pakketten is geïnstalleerd, is het verstandig om ervan uit te gaan dat er sprake kan zijn van compromittering. De onderzoekers adviseren daarom drie praktische stappen.
1) Veronderstel compromittering en reset credentials
Rotteer gevoelige authenticatiegegevens. Doe dit bij voorkeur vanaf een schone machine of omgeving, zodat je zeker weet dat je niet opnieuw met een reeds besmet systeem werkt. Denk daarbij aan API keys, tokens, SSH-credentials en andere secrets die op developer workstations of CI-servers kunnen staan.
2) Audit developer systems op verdachte activiteit
Bekijk je ontwikkelwerkplekken en buildomgevingen op tekenen van vreemde downloads, ongebruikelijke processtarts of persistente configuraties. Omdat de aanval persistence kan inbouwen via OS-specifieke mechanismen, wil je vooral letten op afwijkingen in scripts (zoals shell-profielen op macOS) en services/agents.
3) Controleer je build- en dependency-keten
Omdat de aanval draait om dependency resolution, is het niet genoeg om alleen naar het “top package” te kijken. Breng de volledige dependency tree in kaart en vergelijk die met wat je verwacht. Tools en processen rond Software Supply Chain Security zijn hier essentieel: denk aan het afdwingen van herleidbare, gecontroleerde dependencybronnen.
Als je specifiek wilt weten hoe teams omgaan met supply chain-risico’s in dependency’s en ontwikkelsoftware, sluit het ook aan op eerdere cases zoals gecompromitteerde npm- en Python-packages: actiestappen.
Extra reminder: supply chain aanvallen gaan verder dan npm
In dezelfde disclosure wordt ook een afzonderlijke campagne genoemd rond een “poisoned version” van een Python library die informatie stealer functionaliteit kan dragen. De les voor organisaties is dezelfde: zodra build tools of libraries worden aangetast, kan de aanval via imports of packaging routes doorwerken in meerdere ecosystemen.
Voor IT- en securityteams betekent dit dat je je detection en incident response niet moet beperken tot één pakketbeheerder. Het gaat om het patroon: van geënsceneerde code naar het afhandelen van secrets en het exfiltreren daarvan.
Conclusie: neem malafide npm-pakketten serieus
Deze campagne laat zien hoe malafide npm-pakketten via een zorgvuldig samengestelde dependency-keten een cross-platform RAT kunnen afleveren. De combinatie van lokpakketten, remote payload download en OS-specifieke persistence maakt het een serieus scenario voor ontwikkelaars en teams die Alibaba-gerelateerde tooling gebruiken.
Door nu snel te handelen—credentials roteren, developer omgevingen auditen en je dependencyketen doorlichten—kun je de kans op verdere schade verkleinen en gerichter opschalen zodra er aanwijzingen zijn van compromise.
Wil je je aanpak voor software supply chain verder aanscherpen? Bekijk dan ook hoe incidenten met authentieke ontwikkelomgevingen en dependency-risico’s eerder zijn aangepakt in Amazon linkt npm-aanvallen aan Noord-Koreaanse actoren.
Bron: https://thehackernews.com/2026/08/18-malicious-npm-packages-deliver-cross.html
