Tegenwoordig draait veel softwareontwikkeling op pakketten uit de npm-registry. Juist daarom is het extra verontrustend dat onderzoekers een reeks trojanized npm pakketten hebben gevonden die ogenschijnlijk reguliere kalender- en streakhulpprogramma’s zijn, maar in de praktijk worden gebruikt om een Linux-achterdeur te plaatsen. Het doel is het laten draaien van RedC2 4.0, een implant die vervolgens commando’s van een aanvaller afhandelt.
Wat dit geval opvallend maakt: de code lijkt “normaal” te werken, maar de uitvoering van de payload is slim ingebouwd in het import- en laaddenkpatroon van de dependency graph. Daarmee wordt de drempel verlaagd voor aanvallers die via supply chain-aanvallen binnenkomen.
Hoe trojanized npm pakketten RedC2 4.0 activeren
De ontdekte packages maskeren zich als bruikbare modules voor dagelijkse functionaliteit. Ze leveren de beloofde functionaliteit, maar bevatten tegelijk code die bij het laden van de module de bijgesloten binair wordt gevonden, uitvoerbaar wordt gemaakt en wordt gestart als een achtergrondproces.
Belangrijk detail uit het onderzoek: er is geen uitgebreide “install hook” nodig en er hoeft ook geen expliciete exportfunctie te worden aangeroepen. Zodra de module ergens in je afhankelijkheden wordt geïmporteerd—zelfs als het via transitieve dependencies gebeurt—kan de payload worden gelanceerd. Daardoor kan het gebeuren dat teams iets toevoegen dat nooit direct “verdacht” oogt, maar wel RedC2 in werking zet zodra de software draait.
De vermommingslaag: kalender- en utilitymodules
De onderzoekers noemen meerdere trojanized varianten, met versies rond 1.0.0 en 1.0.1. De namen (zoals modules die naar streaks, kaarten of caches verwijzen) suggereren toepassingen die je in een kalender- of bijhoudcontext zou verwachten.
Onder de motorkap draait echter een bestand met per package een andere naam. Die binair valt in dezelfde categorie, maar wisselt qua bestandsnaam, bijvoorbeeld in varianten als math-core.bin, math-calc.bin, calc-math.dat of calc-cache.bin. Waar je ook op let: de inhoud is hetzelfde doelwit—een Linux beacon die hoort bij RedC2 4.0.
De payload wordt doorgaans teruggevonden in een mapstructuur onder dist/ of in dist/internal/. Vervolgens wordt die binair uitgevoerd zodra de package-entry bestanden hun werk doen.
Een trojan loader in dist/index.mjs
Volgens het rapport verloopt de levering via een entry file: dist/index.mjs. Deze module fungeert als een trojan loader. De loader her-exporteert daarbij de “date helpers” zodat het pakket inhoudelijk legitiem blijft lijken, terwijl het tegelijkertijd bij module-load de ingesloten implant start.
De combinatie van her-exporteren én het starten van de payload maakt dit soort supply chain-malware moeilijker te herkennen met snelle scans. Je ziet immers gedrag dat lijkt op dat van een normale utility, terwijl er in dezelfde flow ook extra activiteit plaatsvindt.
Wat RedC2 4.0 op een besmet Linux-systeem doet
Zodra RedC2 4.0 eenmaal actief is op de Linux-host, gaat de malware communiceren met een externe server. Het systeem “checkt in” door basisinformatie over de machine te verzamelen en die gegevens door te sturen. Daarna begint de command-processing loop: opdrachten binnenkomen, via commando’s worden uitgevoerd en resultaten gaan terug naar de operator.
De Linux-variant gebruikt daarbij interactie via /bin/sh en ondersteunt Linux-specifieke acties. Denk aan:
- Systeemdiscoverie en inventarisatie
- Bestandsoperaties en gegevensverzameling
- Het verzamelen van interessante secrets, waaronder SSH-sleutels en browser-credentials
- Persistence en ondersteuning voor in-memory uitvoering van ELF-onderdelen
- SOCKS5 proxying en network pivoting
Met andere woorden: het gaat niet alleen om “beacons” die aanwezig zijn, maar om een bruikbare toolset voor post-exploit. Dat maakt de impact groter wanneer de aanvaller later stappen wil zetten richting extra systemen of verdere datadiefstal.
C2-functies en het grotere plaatje: AI-assist en multidisclosure
RedC2 wordt op fora gepositioneerd als een command-and-control toolkit voor meerdere besturingssystemen. In het onderzoek wordt beschreven dat de C2-laag zowel Windows als macOS-varianten kent met vergelijkbare functionaliteit, maar met verschillen in extra capabilities.
Voor de C2-omgeving worden onder andere terminaltoegang, bestandsverwerking en gestaffelde payload delivery genoemd. Daarnaast beschrijven de onderzoekers een reeks meer “operatorvriendelijke” features: multi-beacon operaties, netwerkvisualisatie en tunneling. Ook wordt genoemd dat de framework in-memory uitvoering ondersteunt van onderdelen zoals BOFs, .NET-assemblies en shellcode.
Verder is er in de beschrijving sprake van een AI-gedreven component: Red Agent, waarmee operators op basis van natuurlijke taal commando’s kunnen omzetten naar instructies voor de beacon. Het idee: een model dat “operator intent” vertaalt naar concrete command sequence. Het abstractieniveau maakt het voor minder ervaren operators makkelijker om complexe taken uit te voeren.
Waarom dit werkt: supply chain verlaagt de drempel
Deze casus past in een bredere trend: supply chain-aanvallen kunnen de eerste toegang tot een systeem leveren, zonder dat het verdachte payload direct zichtbaar is in de applicatielogica. Onderzoekers benadrukken dat het hier gaat om AI-integratie en een C2-framework dat via npm-distributie beschikbaar kan komen.
Dat betekent niet dat elke toepassing die een npm-module gebruikt meteen kwetsbaar is, maar wél dat je afhankelijkheden als onderdeel van je dreigingsmodel moet behandelen. Als je importketen geraakt wordt, kan een “onschuldig” pakket ineens gedrag vertonen dat niet overeenkomt met wat je verwacht op basis van de functionaliteit op de verpakking.
Praktische aandachtspunten voor teams
Als je software ontwikkelt of deployt met npm-pakketten, kun je uit dit soort incidenten gerichte stappen halen. Welke precies passen hangt af van je omgeving, maar een paar maatregelen komen steeds terug bij dit type supply chain risico.
- Controleer transitive dependencies: niet alleen direct geïnstalleerde pakketten, maar ook wat daaronder schuilgaat.
- Let op ongebruikelijke payloads binnen project- of build-mappen (bijvoorbeeld executables of binairen in dist/).
- Monitor module-load gedrag in runtime: start er ineens processen op momenten dat je dat niet verwacht?
- Gebruik strengere dependency policies (bijv. lockfiles, gecontroleerde registries en scanning in CI/CD).
- Houd incident-signalen bij rond command execution, in-memory uitvoering en onbekende netwerkconnecties.
Als je intern al werkt met beveiligingsanalyses en alerting, kan dit soort patronen helpen om beter te detecteren wanneer dependency-gedrag “afwijkt” van normaliteit.
Vergelijkbare supply chain signalen
Dit incident staat niet op zichzelf. Eerder werd bijvoorbeeld ook gewezen op supply chain-aanvallen waarbij legitieme crates of packages worden misbruikt tijdens build-processen. Dat leert één kernles: “build-time” en “dependency-time” zijn momenten waarop malware zich kan verbergen.
Wil je een parallel lezen over build-time besmetting via pakketten? Bekijk dan ook Rust supply chain: build-time malware via crates. En als je interesse hebt in hoe AI en moderne tooling ook binnen security governance risico’s kunnen vergroten, helpt Shady AI: het nieuwe governance-risico voor security om het bredere dreigingslandschap scherp te krijgen.
Conclusie: behandel npm-dependencies als aanvalsvector
De ontdekking van trojanized npm pakketten die RedC2 4.0 als Linux implant laten draaien laat zien hoe ver aanvallers kunnen gaan met vermomming. De packages lijken functioneel, maar activeren payloads zodra modules worden geladen—zelfs transitief. Daardoor kan een besmetting ongemerkt binnenkomen in build- en runtime workflows.
Wie npm gebruikt voor echte productieomgevingen doet er goed aan dependencyketens streng te monitoren, build-artefacten te controleren en runtime gedrag te bewaken. Zo verklein je de kans dat “gewone” pakketten in de praktijk veranderen in een route naar een stealthy C2-implant.
Bron: https://thehackernews.com/2026/08/14-trojanized-npm-packages-drop-redc2.html
