Een nieuwe campagne in de software supply chain maakt misbruik van de npm-registry. Onderzoekers melden bijna 800 kwaadaardige pakketten die zijn ontworpen om op Windows, macOS en Linux een cross-platform RAT (Remote Access Trojan) en een infostealer te leveren.
Opvallend is de manier waarop de pakketten hun payload uitvoeren. In plaats van bekende triggers via install-hooks (zoals preinstall of postinstall) vragen de pakketten ontwikkelaars via een README om het pakket handmatig in te laden met require(). Dat maakt de aanval anders dan veel npm-gerichte incidenten die vooral draaien om automatisch uitgevoerde install-scripts.
Bijna 800 kwaadaardige npm-pakketten
De pakketten lijken qua naamgeving afkomstig uit dezelfde “familie” van typosquatting. Volgens een open-source malwareonderzoeker zouden sommige namen voortkomen uit AI-gegenereerde varianten (“AI slop squatting”) of uit willekeurige varianten van populaire pakketnamen.
Ondanks die variatie hebben ze een gemeenschappelijk doel: het afleveren van een krachtige downloader die vervolgens per besturingssysteem een passende tweede fase ophaalt. Daarmee is het pakket zelf slechts de eerste schakel in een bredere keten.
Geen install-hooks, maar require()-instructies
Veel npm-aanvallen proberen uitvoering te forceren via lifecycle hooks. In dit geval werkt het anders. De onderzoekers troffen een README aan waarin staat dat ontwikkelaars het pakket moeten laden met require()—een ingebouwde functie om modules, lokale bestanden en third-party code te importeren.
Dat betekent dat de kans op misbruik deels verschuift: niet alleen “automatische installatie” is gevaarlijk, maar ook het onbewust uitvoeren van de aanbevolen laadroute in eigen code. Een snelle review kan daardoor nét misleiden, zeker wanneer de pakketten aan de buitenkant normaal ogen.
Hoe de downloader per systeem de payload kiest
De uitvoering start met een downloader die de host-omgeving detecteert: besturingssysteem en processorarchitectuur. Daarna haalt de malware een compatibele payload op bij een van drie Cloudflare Workers-hosts.
De onderzoekers noemen hierbij drie domeinen onder workers[.]dev. Als HTTPS-downloads niet slagen, wijzigt de malware van strategie: ze gebruikt platform-specifieke DNS TXT-records om de volgende fase te verkrijgen vanaf een domein onder wel1[.]ru.
Per combinatie van OS en CPU hoort een ander payloaddomein:
- Linux x64 – sdk.dl.wel1[.]ru
- Linux ARM64 – ext.dl.wel1[.]ru
- macOS – pkg.dl.wel1[.]ru
- Windows – net.dl.wel1[.]ru
De TXT-recordmethode werkt in stappen. Eerst vraagt de malware een TXT-record op met de prefix c.<domain>. Het antwoord wordt geïnterpreteerd als een aantal “chunks” (tussen 1 en 2.000). Vervolgens worden genummerde TXT-records opgevraagd; die strings worden aan elkaar geplakt en daarna Base64-decoded naar een binair buffer.
Windows, macOS en Linux: vergelijkbare keten, eigen uitvoering
In de eindfase schrijft de malware de payload weg naar een tijdelijke locatie en voert ze uit. Daarbij verschilt de uitvoeringstechniek per platform: op Linux en macOS gebeurt dit via /bin/sh, op Windows via cmd.exe.
Windows: ETW/AMSI verstoren en persistence regelen
De Windows-keten start eveneens met de payload-downloader en vervolgt met een aantal stappen om monitoring en analyse te bemoeilijken. In het bijzonder wordt beschreven dat de malware Event Tracing for Windows (ETW) en Antimalware Scan Interface (AMSI) aanpakt om observatie te verstoren.
Daarna volgt het gedrag richting detectie-omzeiling: er wordt gezocht naar sandboxes en virtuele omgevingen. Vervolgens zet de malware persistence op via een Registry Run-key en een scheduled task, waarna een versleutelde extra component wordt gedownload en gestart (genoemd als /pkg/update_win.exe).
macOS: analyse-artifacts en debug sporen vermijden
De macOS-infectieketen lijkt sterk op Windows in opzet, maar gebruikt platformpassende mechanismen. De malware controleert op debugging, analyse-artifacts en soortgelijke signalen voordat een geschikte payload wordt opgehaald (met een genoemd bestand als /pkg/beacon_mac.bin).
Lukt dat niet via de standaardroute, dan grijpt de malware terug op de eerder beschreven DNS TXT-dispensatie. Voor persistence gebruikt macOS een LaunchAgent. Daarna draait de uitvoer in een detached process.
Linux: UPX, Cloudflare en uiteindelijk Sliver
Voor Linux wordt een sample genoemd dat is verpakt als een UPX-packed ELF-binair. Die component is geconfigureerd om extra payloads op te halen van een Cloudflare Workers URL (in de beschrijving staat opnieuw een workers[.]dev-domein genoemd).
De keten eindigt met de inzet van Sliver, een open-source command-and-control (C2) framework. Daarmee krijgt de aanvaller een beheerslaag om opdrachten uit te voeren op geïnfecteerde systemen.
“Telemetry” als rookgordijn
Naast de downloader troffen onderzoekers een bestand aan dat ogenschijnlijk op een analytics- of telemetry SDK lijkt: lib/telemetry.js. Dit onderdeel bevat volgens de analyse ook dezelfde downloaderlogica, maar is niet het “entry point” van het pakket.
De onderzoekers zien dit als bewust ruis: het grote, realistisch uitziende implementatieblok maakt een snelle codecheck minder effectief. Het gedrag kan daardoor bij oppervlakkige inspectie lijken op “normale profiling of analytics”, terwijl het in werkelijkheid onderdeel is van de kwaadaardige keten.
Doelwit mogelijk: financiële instellingen
Bij de macOS-payload worden domeinen genoemd die associaties oproepen met financiële organisaties en mobile payments (zoals tcsbank[.]ru en cloudpayments[.]ru). Dat suggereert dat de campagne mogelijk gericht is op Russische financiële infrastructuur en betalingsketens.
De onderzoekers plaatsen deze observatie in de context van eerdere aanvallen waarbij npm niet alleen werd gebruikt voor credential theft, maar ook voor gericht afleveren van OS-specifieke second-stage malware.
Link met eerdere dependency confusion-campagnes
Er wordt ook een vermoeden geuit dat deze campagne een evolutie is van een dependency confusion-aanpak met de codenaam Moika. Die werd eerder in april waargenomen en bestond uit meer dan 250 gepubliceerde pakketten die informatie uit de omgeving wilden stelen en daarna een OS-specifieke tweede fase afleverden.
Het interessante aan deze ontwikkeling: waar dependency confusion zich vaak richt op het ophalen van een dependency uit een verkeerde registry, laat de huidige campagne zien dat de dreiging zich ondertussen uitbreidt naar een duidelijke “deployable” malwareketen met een cross-platform RAT als einddoel.
Meer dan npm: ook browserextensies in de keten
Naast npm noemen onderzoekers ook campagnes waarin aanvallers Google Chrome-extensies inzetten. Die extensies worden bijvoorbeeld vermomd als game emulators, password managers, productivity tools, CSS inspectors of markdown converters.
Het effect is dat de browser verandert in een web crawling proxy. De crawl-opdrachten komen remote binnen via een persistent WebSocket-verbinding. Extensies bevatten daarnaast een commerciële web bandwidth-sharing SDK die koppelt met een residentiële proxy-netwerkdienst voor scraping.
Daarbij rapporteren Unit 42-achtige bevindingen dat sommige extensies hun werkwijze wel gedeeltelijk beschrijven in store-teksten en privacybeleid, en dat opt-in soms als noodzakelijk wordt gepresenteerd voor “doorlopende service”.
Dat maakt duidelijk dat “supply chain” breder is dan alleen package managers: het gaat om elke manier waarop software distributie en gebruikersgedrag samen een route naar misbruik vormen.
Wat kun je nu doen?
Een campagne met cross-platform RAT via npm vraagt om praktische maatregelen die verder gaan dan “alleen updates draaien”. Denk aan het aanscherpen van je manier van dependencybeheer en code-review.
- Beperk afhankelijkheden: laad niet klakkeloos nieuwe pakketten in productiecode zonder beoordeling.
- Controleer README-instructies: let extra op instructies die vragen om handmatig require() op verdachte modules uit te voeren.
- Scan op ongebruikelijke activeringspaden: ook zonder install-hooks kan malware toch actief worden.
- Werk je monitoring bij: verwacht dat aanvallers ook ETW/AMSI-achtige verstoringen proberen, en evalueer je detectie op behavior.
Wil je de bredere context rond supply chain dreigingen en governance/compliance beter begrijpen? Lees dan ook governance vs compliance in cyberrisk voor een raamwerk om dit soort risico structureel te managen.
En als je geïnteresseerd bent in hoe aanvallers via package-achtige routes uitvoering benaderen, dan sluit CI-workflows gehackt via GitHub issues aan bij het thema: aanvallers zoeken telkens naar het zwakste punt in je bouw- en deployketen.
Conclusie
De ontdekking van bijna 800 kwaadaardige npm-pakketten laat zien dat supply chain aanvallen snel evolueren. Deze campagne levert een cross-platform RAT en infostealer niet via standaard install-hooks, maar via een misleidende require-aanpak en een payloaddraaiboek dat per OS en architectuur werkt.
Wie dependencies gebruikt als onderdeel van applicatiebouw, doet er goed aan README’s, import-instructies en de uitvoerflow van pakketten extra kritisch te bekijken. Alleen dan voorkom je dat “een ogenschijnlijk klein npm-pakket” alsnog de deur opent naar een volledig uitgerolde malwareketen.
Bron: https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
