De ChainDrop NPM-aanval is een nieuwe supply chain-campagne die laat zien hoe snel besmette afhankelijkheden zich kunnen verspreiden via package registries. In korte tijd werden er honderden kwaadaardige varianten op NPM gepubliceerd, met brede impact op ontwikkelaars en automatiseringsomgevingen.
De kern van het probleem: geïnfecteerde pakketten voeren tijdens installatie malafide code uit. Daarmee wordt niet alleen informatie gestolen, maar krijgt de aanvaller ook de mogelijkheid om verdere besmettingen door te zetten via herpublicatie van pakketten en misbruik van gestolen credentials.
Wat is de ChainDrop NPM-aanval?
ChainDrop maakt deel uit van een reeks supply chain-aanvallen waarbij aanvallers bestaande ontwikkelstromen vergiftigen. In dit geval is sprake van meer dan 2.200 kwaadaardige versies van 440 pakketten die op de NPM-registry zijn gezet. De campagne startte met 11 malware-dragers in specifieke namespaces, nadat de GitHub-account van de maintainer was gecompromitteerd.
Het resultaat is extra schadelijk omdat veel van die pakketten breed worden gebruikt in het NPM-ecosysteem. Volgens de beschikbare informatie hadden de geïnfecteerde pakketten samen meer dan 500 miljoen wekelijkse downloads. Ook leidde de “poisoning” van onderdelen tot 433 extra geïnfecteerde pakketten.
Hoe de malware werkt tijdens installatie
Geïnfecteerde pakketten bevatten een preinstall dropper. Die dropper downloadt een legitieme Bun JavaScript-runtime en start vervolgens een tweede fase met 710 KB aan obfuscated code. Die tweede fase is verantwoordelijk voor de daadwerkelijke kwaadaardige acties.
Een opvallend detail is dat de malware is ontworpen voor zelfverspreiding en aanvullende besmetting. Zodra de code draait, is het doel niet beperkt tot het systeem waar het pakket werd geïnstalleerd; het richt zich op het verzamelen van identiteiten en vervolgens op het uitrollen van nieuwe, aangepaste pakketversies.
Secrets stelen uit ontwikkel- en cloudomgevingen
Na uitvoering zoekt de malware naar secrets die hij kan vinden op developer workstations en in omgevingen die gebruikmaken van NPM, GitHub en cloud- en infrastructuurcomponenten. Het gaat daarbij om credentials die vervolgens worden misbruikt om toegang te krijgen tot meerdere diensten.
Concreet richt de malware zich op het terugvinden van gegevens voor authenticatie bij onder meer NPM, GitHub, Amazon Web Services (AWS), Kubernetes en HashiCorp Vault. Met die gestolen identiteit kan de aanvaller onder andere pakketten, repositories, workflow secrets, cloudparameters en secret-store waarden enumereren.
Daarna volgt exfiltratie van de gestolen informatie. Die uitgaande data gaat ofwel naar een dynamisch HTTPS-eindpunt, ofwel naar door de aanvaller aangemaakte openbare GitHub-repositories met een specifieke beschrijvende tekst.
Extra besmetting via herpublicatie op NPM
Een belangrijk onderdeel van de ChainDrop NPM-aanval is het vermogen om zelf opnieuw pakketten te publiceren. De malware gebruikt gestolen NPM publicatiegegevens om van pakketten die binnen bereik liggen aangepaste, geïnfecteerde versies te maken.
De beschreven werkwijze omvat onder andere:
- Het enumereren van pakketten die beschikbaar zijn voor de gecompromitteerde identiteit.
- Het downloaden van de laatste tarballs.
- Het invoegen van de malware en een setup loader.
- Het toevoegen van een preinstall hook.
- Het verhogen van de patchversie en het republishen van de gemanipuleerde packages.
Dit betekent dat één besmetting kan uitgroeien tot een keten van nieuwe besmettingen, precies doordat de aanvaller kan publiceren namens een geauthenticeerde identiteit.
Misbruik van GitHub en GitHub Actions
Naast NPM speelt ook GitHub een grote rol. Met gestolen GitHub-credentials kan de malware repositories beïnvloeden. Er wordt onder andere beschreven dat de aanvaller Claude- en Visual Studio Code configuratiebestanden kan injecteren in repositories.
Dat heeft twee gevolgen. Ten eerste kan het bijdragen aan persistentie binnen de ontwikkelomgeving. Ten tweede ontstaat er een aanvullende infectieroute: een pad dat draait om developer-to-developer besmetting, doordat wijzigingen in repositories opnieuw bij anderen kunnen landen via hun ontwikkelworkflow.
Ook wordt er melding gemaakt van het inzetten van GitHub Actions om meer repositories te besmetten met als doel opnieuw credential theft.
Command-and-control met EtherHiding
De malware gebruikt een command-and-control mechanisme gebaseerd op een Ethereum blockchain. Dit is beschreven als een techniek waarbij de communicatie minder zichtbaar kan zijn, aangeduid als EtherHiding. In plaats van klassieke C&C-kanalen maakt de malware gebruik van de blockchain-infrastructuur om instructies te verkrijgen.
Hoewel dit technisch klinkt, is het praktische punt voor organisaties vooral: netwerkverkeer alleen is vaak niet genoeg om de aanwezigheid van dergelijke malware betrouwbaar te detecteren.
Dead-man’s switch en zelfverwijdering
Om ontdekking en langdurige aanwezigheid te beperken, bevat de malware een dead-man’s switch op macOS en Linux. Na het bereiken van persistentie wordt elke 60 seconden de GitHub API gepolst met behulp van de gestolen GitHub token.
Als die token niet meer werkt, dan wordt de toestand gewist en stopt de malware. Daarnaast wordt er vermeld dat de malware zichzelf ook kan zelf-clearen na 24 uur, wat opsporing achteraf kan bemoeilijken.
Waarom het aantal kwaadaardige versies zo snel opliep
De campagne liet een snelle escalatie zien. Doordat de malware ook veel historische versies opnieuw publiceerde van de gecompromitteerde pakketten, kwam het totaal aantal waargenomen kwaadaardige iteraties op 2.212 uit binnen minder dan vier uur (waarneming op 4 augustus).
Dit is precies waarom supply chain-aanvallen zo lastig te bestrijden zijn: het probleem zit niet alleen in “de nieuwste release”, maar kan ook in eerdere versies die nog steeds in bouw- en installatieprocessen voorkomen.
Wat moeten NPM-ontwikkelaars nu doen?
De waarschuwing is helder: wie een van de geïnfecteerde pakketversies heeft geïnstalleerd, moet rekening houden met compromittering van de betreffende machine of buildomgeving. De aanbevolen aanpak bestaat uit het isoleren en het zorgvuldig bewaren van bewijsmateriaal, gevolgd door herstel en rotatie.
Concreet wordt aangeraden om geïnfecteerde systemen te isoleren en bewijs te bewaren, zoals:
- package tarballs
- npm logs
- CI logs
- GitHub audit logs
- runner images
Daarna volgen acties om de schade te beperken: het verwijderen van de malware, het opnieuw opbouwen van CI runners en buildmachines, en het intrekken en roteren van credentials die mogelijk zijn blootgesteld. Tot slot is auditing van GitHub-repositories op anomalous activity een belangrijke stap om verdachte wijzigingen of herpublicaties te vinden.
Praktische checklist voor teams met CI/CD
Omdat de ChainDrop NPM-aanval vooral misbruikt wat er al bestaat in moderne ontwikkelketens, helpt een herhaalbare aanpak. Overweeg onderstaande punten als startpunt voor een interne incidentrespons-checklist.
- Inventariseer afhankelijkheden: check welke NPM-pakketten jullie in builds gebruiken en of er overlap is met de geïnfecteerde versies.
- Beperk en isoleer: behandel getroffen buildagents en ontwikkelmachines als mogelijk gecompromitteerd.
- Rotatie van tokens: trek NPM- en GitHub-tokens in die in de relevante periode actief waren.
- CI/CD herbouw: herstart of herbouw runners, images en pipeline-omgevingen om persistence te verwijderen.
- Audit repositories en workflows: controleer workflow files, commits en configuraties op ongeautoriseerde wijzigingen.
Met deze stappen verklein je de kans dat gestolen identiteiten opnieuw kunnen publiceren, data kunnen blijven exfiltreren of extra repos kunnen raken via geautomatiseerde pipelines.
Gerelateerd: aanvallen op ontwikkelketens
Als je dit type supply chain-risico breder wilt plaatsen, zijn er ook eerdere signalen geweest van aanvallen die via package ecosystemen of ontwikkeltools vergelijkbare schade proberen te veroorzaken. Zo kun je lezen over de QuickFox supply chain aanval en over een npm-worm die honderden pakketten besmette. Daarmee zie je terugkerende patronen in distributie en misbruik van automatisering.
Conclusie
De ChainDrop NPM-aanval laat zien hoe een supply chain-incident niet stopt bij een besmet pakket. Door installatie-malware, secrets theft en het herpubliceren van gemanipuleerde versies kan één gecompromitteerde route uitgroeien tot een groot besmettingsvlak met impact op ontwikkelaars, CI/CD en cloudtoegang.
Wie NPM in zijn leveringsketen gebruikt, doet er goed aan om snel te beoordelen welke afhankelijkheden geraakt kunnen zijn, om systemen en runners te isoleren, bewijs te bewaren en alle mogelijk gecompromitteerde credentials te roteren. Dat is de route om de exposure window te verkleinen en herhaling te voorkomen.
Bron: https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
