Het niet-zo-verborgen patroon in de Axios-aanval
Interlynk
Wat is er gebeurd?
Op 31 maart 2026 werden twee nieuwe versies van axios - de meest gebruikte HTTP-clientbibliotheek in het JavaScript-ecosysteem - op npm gepubliceerd via een gecompromitteerd maintainersaccount. De kwaadaardige versies (1.14.1 en 0.30.4) bereikten samen meer dan 100 miljoen wekelijkse downloads. Ze introduceerden een verborgen afhankelijkheid genaamd plain-crypto-js, die stilletjes een platformonafhankelijke Remote Access Trojan (RAT) uitrolde op elke ontwikkelaarsmachine, CI/CD-pijplijn en productieomgeving die een routinematige npm-installatie uitvoerde.
Zowel Google Threat Intelligence Group als Microsoft Threat Intelligence schreven de aanval toe aan UNC1069 / Sapphire Sleet, een financieel gemotiveerde dreigingsactor met banden met Noord-Korea, actief sinds ten minste 2018. De kwaadaardige versies stonden ongeveer drie uur live - net lang genoeg om enorme downstream-blootstelling te veroorzaken voordat npm ze verwijderde.
Als uw organisatie Node.js-software gebruikt, is de kans groot dat axios ergens in uw afhankelijkheidsboom voorkomt - zelfs als geen enkele ontwikkelaar het ooit expliciet heeft toegevoegd. Dat is de aard van transitieve afhankelijkheden. En dat is precies wat deze aanval zo gevaarlijk maakt.
De aanval, stap voor stap
De compromittering van axios volgde een nauwkeurige operationele volgorde die beveiligingsonderzoekers nu volledig in detail hebben gedocumenteerd:
Stap 1 - Diefstal van inloggegevens. De aanvaller verkreeg een langlevende klassieke npm-toegangstoken voor het account van @jasonsaayman, de primaire axios-maintainer. Hoewel het account MFA had geconfigureerd, omzeilde de aanvaller dit door de gestolen token direct te gebruiken - een bekend gat wanneer legacy-tokens naast OIDC-gebaseerde publicatieworkflows bestaan.
Stap 2 - Accountovername. Het geregistreerde e-mailadres op het maintaineraccount werd stilletjes gewijzigd van het legitieme Gmail-adres naar een Proton Mail-adres (ifstap@proton.me) onder controle van de aanvaller - een gebruikelijke pivot om de echte eigenaar buiten te sluiten.
Stap 3 - Vooraf klaarzetten van een kwaadaardig pakket. Voordat axios zelf werd aangepakt, publiceerde de aanvaller plain-crypto-js@4.2.0 als een schoon lokpakket om registerhistorie en geloofwaardigheid op te bouwen, gevolgd door plain-crypto-js@4.2.1 - het aflevervoertuig van de kwaadaardige payload.
Stap 4 - Vergiftiging van beide releasebranches. Binnen een venster van 39 minuten publiceerde de aanvaller axios@1.14.1 (getagd als latest) en axios@0.30.4 (getagd als legacy). Beide versies hadden plain-crypto-js@4.2.1 geïnjecteerd als afhankelijkheid. Het taggen van beide kanalen maximaliseerde de impact op projecten die ofwel de huidige ofwel de legacy axios-API gebruikten.
Stap 5 - Stille uitvoering na installatie. De kwaadaardige plain-crypto-js definieerde een post-install-lifecycle-hook. Op het moment dat een omgeving npm install uitvoerde, werd setup.js automatisch uitgevoerd - geen gebruikersinteractie vereist. Binnen twee seconden na installatie belde de malware al naar huis naar de C2-server van de aanvaller op sfrclak[.]com:8000 op IP (142.11.206[.]73)
Stap 6 - Platformspecifieke RAT-deploy. De dropper detecteerde het hostbesturingssysteem en implementeerde een op maat gemaakte payload van de tweede fase - een cross-platform RAT genaamd WAVESHAPER.V2 - voor macOS, Windows en Linux. De RAT begon onmiddellijk met systeemverkenning, inventariseerde directory's en draaiende processen, en exfiltreerde inloggegevens, SSH-sleutels, cloudtokens en API-geheimen.
Stap 7 - Provenance-kloof als camouflage. Legitieme axios-releases bevatten altijd OIDC-provenance-metadata en SLSA-buildattestaties die het npm-pakket terugkoppelen aan een specifieke GitHub Actions-run. De kwaadaardige versies hadden dit niet. Verdedigers die provenance-controle hadden ingericht, zagen dit onmiddellijk; degenen die vertrouwden op traditionele kwetsbaarheidsscanners zagen niets - omdat plain-crypto-js geen CVE had.
Opkomend aanvalspatroon
De axios-aanval is het nieuwste datapunt in een langdurige en versnellende trend.
Elke stap van dit draaiboek is eerder uitgevoerd - vaak door dezelfde klasse dreigingsactoren, tegen vergelijkbaar kritieke open-sourcepakketten:
event-stream (2018): Een kwaadaardige bijdrager verkreeg publicatierechten voor een slapend npm-pakket met 2 miljoen wekelijkse downloads en injecteerde een achterdeur die gericht was op een specifieke Bitcoin-wallet. De aanval bleef wekenlang onopgemerkt.
SolarWinds Orion (2020): Door staten gesteunde actoren (Nobelium/APT29) compromitteerden de SolarWinds-buildpipeline en voegden de SUNBURST-achterdeur toe aan ondertekende software-updates die werden verspreid naar 18.000 organisaties, waaronder Amerikaanse federale instanties. De aanval bleef 14 maanden onopgemerkt.
ua-parser-js (2021): Een gekaapt npm-account werd gebruikt om kwaadaardige versies te publiceren van een bibliotheek met 8 miljoen wekelijkse downloads, waarbij cryptominers en inloggegevensdieven werden uitgerold - dezelfde accountovernamevector die vijf jaar later tegen axios werd gebruikt.
XZ Utils (2022–2024): Een geavanceerde dreigingsactor besteedde bijna twee jaar aan het winnen van het vertrouwen van maintainers van een kerncompressiebibliotheek voor Linux voordat een achterdeur werd ingevoegd die OpenSSH-authenticatie op Fedora, Ubuntu en Debian als doel had. Bijna per ongeluk ontdekt door een Microsoft-engineer die anomalieën in SSH-latentie opmerkte.
tj-actions/changed-files (2025): Een GitHub Action die in duizenden CI/CD-workflows werd gebruikt, werd gecompromitteerd via tag poisoning, waarbij op grote schaal geheimen uit runner-omgevingen werden geëxfiltreerd.
Trivy / TeamPCP (2026): Dagen vóór de axios-aanval stal dreigingsactor TeamPCP een toegangstoken uit de GitHub Actions-workflow van de Trivy-beveiligingsscanner, vergiftigde 's nachts 76 versietags, oogstte inloggegevens uit CI/CD-omgevingen en gebruikte gestolen npm-tokens om een worm (CanisterWorm) zichzelf te laten verspreiden over meer dan 66 npm-pakketten - allemaal binnen enkele dagen rond de axios-aanval.
De rode draad in al deze aanvallen: compromitteer een vertrouwd component, lift mee op het impliciete vertrouwen van het ecosysteem en bereik automatisch elke downstreamgebruiker. De axios-aanval heeft dit niet uitgevonden - hij heeft het op schaal geperfectioneerd.
De versnelling is echt
Aanvallen op de toeleveringsketen waren vroeger chirurgische, geduldige operaties die in maanden of jaren werden gemeten. De backdoor in XZ Utils vergde twee jaar social engineering. SolarWinds bleef 14 maanden onopgemerkt. Vandaag werd de axios-aanval binnen 6 minuten na publicatie geïdentificeerd door tools voor gedragsanalyse — en trof toch meer dan 135 endpoints voordat deze werd ingedamd. De tijdlijn is gecomprimeerd van jaren naar uren. AI wordt nu door aanvallers gebruikt om kwaadaardige pakketten te genereren, verspreiding te automatiseren en zwakke plekken op machinesnelheid te vinden, terwijl AI-codingagents aan de kant van ontwikkelaars versies van afhankelijkheden met bekende kwetsbaarheden selecteren met percentages die 50% hoger liggen dan bij mensen. Het aanvalsoppervlak groeit sneller dan de verdediging.
Best practices voor mitigatie
Geen enkele maatregel stopt elke supplychainaanval. Effectieve verdediging vereist meerdere onafhankelijke lagen die over de volledige SDLC werken:
Weet altijd wat je draait
Je kunt een supplychainaanval op een component waarvan je niet wist dat je het gebruikte, niet detecteren of erop reageren. Geautomatiseerde SBOM-generatie die door de hele SDLC is ingebed — niet als een eenmalig auditresultaat, maar als een continu overzicht van wat er precies in elke build zit — is de fundamentele maatregel. Een SBOM die tijdens buildtijd wordt geproduceerd, legt transitieve afhankelijkheden zoals plain-crypto-js vast voordat ze ooit productie bereiken.
Pin afhankelijkheden. Commit lockfiles.
Zwevende versiebereiken (^1.14.0, ~1.14.0) zijn een open uitnodiging voor supplychainaanvallen. Elke update die binnen het bereik valt, wordt automatisch geïnstalleerd. Pin op exacte versies. Commit je package-lock.json. Gebruik npm ci (niet npm install) in alle CI/CD-pipelines — het respecteert het lockfile exact en zal niet stilzwijgend upgraden naar een kwaadaardige patchrelease.Dwing provenance en build-attestatie af
Vereis OIDC-provenance-metadata en SLSA Level 2+ voor alle kritieke third-party pakketten. Het duidelijkste vroege signaal van de axios-aanval was het ontbreken van provenance op nieuwe versies van een pakket dat dit altijd had meegeleverd. Het ontbreken van provenance op een nieuwe versie van een groot pakket moet een automatisch alarm activeren — niet slechts een handmatig onderzoek achteraf.Pas een publicatie-afkoelbeleid toe
Implementeer een minimumleeftijdbeleid voor releases — blokkeer installatie van pakketten die in de afgelopen 72 uur zijn gepubliceerd. Dit geeft de securitycommunity tijd om nieuwe releases te analyseren voordat ze je supply chain binnenkomen. De kwaadaardige axios-versies stonden slechts drie uur live; een afkoelperiode van 72 uur zou ze voor de overgrote meerderheid van organisaties volledig hebben geblokkeerd.Schakel postinstall-scripts uit of audit ze
De volledige axios-aanvalsketen draaide om npm's postinstall-lifecycle-hook. De meeste productiebuilds hebben geen lifecycle-scripts van third-party pakketten nodig. Gebruik npm install --ignore-scripts in CI/CD-pipelines waar scripts niet vereist zijn. Wanneer scripts noodzakelijk zijn, audit ze en zet ze expliciet op een allowlist.Monitor op afwijkend gedrag tijdens runtime
Traditionele kwetsbaarheidsscanners zoeken naar bekende CVE's. Supplychainaanvallen zoals axios introduceren volledig nieuwe pakketten zonder CVE-geschiedenis. Gedragsmonitoring — letten op onverwachte uitgaande netwerkverbindingen vanuit buildomgevingen, nieuwe processen gestart door npm install, of afwijkende patronen in credentialtoegang — vangt wat signature-gebaseerde tools missen. Binnen twee seconden na installatie was de axios-RAT al aan het "bellen naar huis". Monitoring van uitgaand netwerkverkeer vanaf CI-runners zou dit onmiddellijk hebben gedetecteerd.Roteer credentials agressief en trek langlevende tokens in
De axios-aanval was mogelijk omdat een langlevende npm-access-token directe publicatietoegang gaf — en daarmee elke OIDC-gebaseerde publicatiecontrole omzeilde die was ingesteld. Elimineer langlevende tokens waar mogelijk. Adopteer Trusted Publishing met OIDC. Roteer alle CI/CD-secrets volgens een regelmatig schema en behandel direct na elk supplychainincident elke credential die een getroffen omgeving heeft geraakt als gecompromitteerd.
Interlynk-klantervaring met Axios
Toen de axios-aanval openbaar werd, schakelden beveiligingsteams wereldwijd over op noodresponsmodus: afhankelijkheidsbomen auditen, CI/CD-logs doorzoeken, inloggegevens roteren, en proberen de meest basale vraag te beantwoorden - zijn wij getroffen?
Voor 77% van de Interlynk-klanten had die vraag een direct antwoord. De hierboven beschreven best practices zijn geen ambitieuze aanbevelingen op een Interlynk-checklist - het zijn geoperationaliseerde controles die in het platform zijn ingebouwd:
Continue SBOM-generatie, ingebed in de hele SDLC, betekende dat klanten al een actuele, nauwkeurige registratie hadden van elke afhankelijkheid in elke build - inclusief transitieve afhankelijkheden zoals plain-crypto-js.
Monitoring van open-source-risico's signaleerde wijzigingen in axios-versies en de introductie van nieuwe afhankelijkheden in realtime, afgezet tegen continu bijgewerkte dreigingsinformatie.
Beleidsafdwinging in de hele SDLC - inclusief vereisten voor dependency pinning en allowlisting van componenten - voorkwam dat de kwaadaardige versies überhaupt in build-pijplijnen terechtkwamen voor het merendeel van de klanten.
Leveranciersmonitoring bood direct inzicht in welke pakketten in de stuklijst actieve beveiligingsincidenten hadden, zonder dat handmatige loganalyse nodig was.
De 23% die de blootstelling nog aan het beoordelen was, had één ding gemeen: hiaten in SBOM-dekking voor legacy-pijplijnen of overgenomen codebases die nog niet in het platform waren opgenomen. Axios vond het gat. Dat doet het altijd.
Echte verdediging: SBOM-automatisering door de hele SDLC heen
Organisaties die reageerden op de axios-aanval stonden voor een bekende uitdaging: je kunt niet afdwingen wat je niet kunt zien, en je kunt niet zien wat je nooit hebt bijgehouden. Handmatige SBOM-generatie - een eenmalig auditdocument dat wordt geproduceerd voor een compliance-oplevering - biedt geen bescherming tegen een supplychainaanval die zich in drie uur ontvouwt en begint op ontwikkelmachines.
Het enige duurzame antwoord is het automatiseren van SBOM-generatie en beleidsafdwinging over de volledige Software Development Lifecycle. Niet als een point-in-time-export, maar als een continu, levend overzicht van elk component in elke build, beoordeeld tegen actuele dreigingsinformatie en organisatiebeleid, in elke fase van ontwikkeling tot productie.
Dit is vooral van belang voor complexe organisaties - met tientallen teams, honderden repositories en een mix van moderne en legacy-codebases. De beleidsvraag bij een supplychainaanval is nooit "volgen we in theorie best practices?" - maar "heeft elk team, elke pipeline, elk werkstation van ontwikkelaars het beleid daadwerkelijk afgedwongen toen het ertoe deed?" Handmatige processen en heldendaden op teamniveau kunnen die vraag op schaal niet consistent beantwoorden.
Het inbedden van SBOM-generatie in de SDLC - met geautomatiseerde beleidspoorten die niet-conforme componenten blokkeren om verder te gaan door de build-pipeline, continue monitoring van componentwijzigingen tegen live dreigingsinformatie, en tracking van leveranciersrisico's die gebeurtenissen zoals de axios-compromittering in realtime zichtbaar maakt - verandert supplychainbeveiliging van een reactief incidentresponsprobleem in een proactieve engineeringdiscipline.
Supplychainaanvallen versnellen. Het tijdvenster tussen publicatie van een kwaadaardig pakket en het eerste slachtoffer wordt nu gemeten in seconden, niet in dagen. De enige organisaties die niet koortsachtig "zijn we getroffen?" hoeven te beantwoorden, zijn degenen die al precies weten wat er in hun software zit - omdat ze het antwoord hebben geautomatiseerd.
Zie hoe Interlynk SBOM in je hele SDLC automatiseert en supplychainbeleid op schaal afdwingt. Boek een demo →