Axios bajo fuego: het is de taak om de suministro-cadena in npm aan te pakken

Laatste update: 04/01/2026
Auteur: C Bronpad
  • Kwaadaardige Axios-releases op npm voegden een verborgen afhankelijkheid toe die tijdens de installatie een platformonafhankelijke trojan voor toegang op afstand installeerde.
  • Aanvallers hebben misbruik gemaakt van een gecompromitteerd beheerdersaccount en verouderde npm-tokens om axios@1.14.1, axios@0.30.4 en plain-crypto-js@4.2.1 te publiceren.
  • De RAT kon geheimen stelen, toegang krijgen tot repositories en cloudomgevingen, met behulp van IOC's zoals sfrclak.com, 142.11.206.73 en specifieke bestandssysteemartefacten.
  • Beveiligingsteams dringen er bij ontwikkelaars op aan om lockfiles te controleren, inloggegevens regelmatig te vernieuwen, de workflows in de toeleveringsketen te beveiligen en getroffen machines als volledig gecompromitteerd te beschouwen.

Illustratie van een aanval op de toeleveringsketen van Axios

Gedurende een paar spannende uren was een van de meest gebruikte JavaScript-bibliotheken ter wereld, Axios, werd een onverwacht middel om malware te verspreiden. Een gerichte aanval Een aanval op de toeleveringsketen van het npm-ecosysteem Een routinematige update van afhankelijkheden is daardoor een potentiële achterdeur geworden voor aanvallers op honderdduizenden ontwikkelaarsmachines en buildsystemen.

Onderzoekers van verschillende beveiligingsbedrijven en Google's Threat Intelligence Group hebben ontrafeld hoe een kwaadwillende een systeem wist te bemachtigen. Trojaans paard voor externe toegang (RAT) in specifieke Axios-releases op npm, vergelijkbaar met de npm-toeleveringsketenworm.

Wat Axios is en waarom het compromis zo belangrijk is.

In de kern is Axios een Promise-gebaseerde HTTP-client voor Node.js en browsersHet werkt op de achtergrond in talloze projecten en handelt dagelijkse taken af ​​zoals "haal mijn berichten van de server op" of "verstuur dit formulier naar de API" zonder dat ontwikkelaars handmatig netwerkcode op laag niveau hoeven te schrijven.

Omdat Axios zowel in de browser als op Node.js-servers draait, is het een fundamentele afhankelijkheid in moderne JavaScript-stacksJe hebt het misschien nooit expliciet geïnstalleerd, maar je bent er toch indirect van afhankelijk wanneer je:

  • Gebruik webapplicaties die zijn gebouwd met frameworks zoals React, Vue of Angular en die hun API-aanroepen omwikkelen met Axios.
  • Voer desktop- of mobiele apps uit die zijn gebouwd met technologieën zoals Electron, React Native en vergelijkbare webgebaseerde runtime-omgevingen.
  • Communiceer met kleinere SaaS-tools, beheerdersdashboards of zelfgehoste services waarvan de ontwikkelaars Axios hebben gekozen voor HTTP-verzoeken.

In die zin is Axios een beetje zoals de loodgieterswerk in uw huisJe denkt er zelden over na, maar het transporteert de data als het ware via water tussen je app en de buitenwereld. Je merkt het pas echt als er een lek is – precies wat deze aanval heeft veroorzaakt, maar dan op de schaal van een software-ecosysteem.

Hoe de Axios npm-aanval zich ontvouwde

Het incident draait om twee npm-releases: axios@1.14.1 en axios@0.30.4Door gebruik te maken van gecompromitteerde inloggegevens van een van de belangrijkste beheerders van het project, zijn aanvallers erin geslaagd om te publiceren. kwaadaardige builds rechtstreeks naar npm terwijl de openbare GitHub-broncode ongewijzigd blijft, een patroon dat ook wordt beschreven in de Shai-Hulud-analyse.

In plaats van de code van Axios zichtbaar te wijzigen, voegde de aanvaller een nieuwe, ogenschijnlijk ongerelateerde afhankelijkheid toe: plain-crypto-js@4.2.1Dit pakket is speciaal ontwikkeld voor de operatie en werd nergens in de bronbestanden van Axios geïmporteerd.Dit is een waarschuwingssignaal voor iedereen die de verschillen nauwkeurig bekijkt, maar het is gemakkelijk over het hoofd te zien in geautomatiseerde workflows die simpelweg op het register vertrouwen.

De twee besmette Axios-versies hadden samen een enorm potentieel bereik, dat zich uitstrekte tot ongeveer 100 miljoen wekelijkse downloads op npmNaar schatting is Axios aanwezig in bijna 80% van de cloudomgevingen en CI/CD-pipelines, dus zelfs een korte blootstelling vormde een ernstig systeemrisico.

Cruciaal is dat de getroffen versies nooit in de verschenen zijn. officiële GitHub-tags voor het Axios-project. Dat detail wijst er sterk op dat de normale releaseprocessen werden omzeild: de aanvaller gebruikte een gestolen npm-token om pakketten rechtstreeks naar de registry te pushen, buiten het normale openbare releaseproces om.

De mechanismen van de kwaadaardige afhankelijkheid en de RAT

De kern van het compromis ligt in wat er tijdens de installatie is gebeurd. Elke workflow die werd uitgevoerd npm install en naar binnen getrokken axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 Met ingeschakelde scripts werd een verborgen postinstallatieroutine geactiveerd.

Binnen de kwaadaardige afhankelijkheid bevindt zich een postinstall-script (node ​​setup.js) werd automatisch uitgevoerd. Dat script downloadde een versleutelde dropper, die vervolgens een platformspecifieke RAT-payload ophaalde die was afgestemd op... macOS, Windows of LinuxDe RAT gaf de aanvaller interactieve toegang op afstand tot de gecompromitteerde machine.

Eenmaal actief, kan deze remote access trojan het systeem in kaart brengen, geheimen verzamelen en willekeurige commando's uitvoeren. Denk maar eens na. cloud API-sleutels, CI-implementatietokens, npm-authenticatietokens, SSH-sleutels, repository-toegangstokens en andere gevoelige omgevingsvariabelen Wordt vaak geïnjecteerd in build-agents of laptops van ontwikkelaars.

Van daaruit zouden aanvallers een andere koers kunnen varen: broncode bekijken, toekomstige releases manipuleren, meer backdoors toevoegen of zich lateraal in de productie-infrastructuur begeven. Voor ontwikkelaars die werken aan crypto-gerelateerde projecten – wallets, exchanges, DeFi-frontends – zou dit soort toegang direct kunnen leiden tot Diefstal van cryptovaluta of bredere financiële fraude.

Heimelijke tactieken: waarom het compromis moeilijk te ontdekken was

De makers van de malware hebben er alles aan gedaan om hun sporen zo klein en vluchtig mogelijk te houden. Volgens onderzoekers is de dropper heeft zijn sporen schoongemaakt onmiddellijk na de executie.

Dat betekent dat als je onderzocht node_modules/plain-crypto-js/package.json na Bij een infectie zou je een volkomen onschuldig manifest zien: geen postinstallatiescript, geen setup.jsgeen duidelijke aanwijzingen voor een misdrijf. Standaard hulpmiddelen zoals npm audit Of een vluchtige handmatige controle van de mappenstructuur zou niet aan het licht brengen wat er al gebeurd was.

In de praktijk leidde dit gedrag ertoe dat onderzoekers afhankelijk werden van externe bronnen. indicatoren van compromis (IOC's)Er werd gebruikgemaakt van netwerktelemetrie en hostartefacten in plaats van eenvoudige statische scans van de inhoud van npm-pakketten. Tegen de tijd dat de aanval openbaar werd, waren de kwaadaardige versies al van npm verwijderd, wat de reconstructie van het exacte uitvoeringsverloop verder bemoeilijkte.

Belangrijke indicatoren voor een inbreuk op het Axios-incident

Hoewel de malware probeerde zijn sporen uit te wissen, hebben beveiligingsteams concrete IOC's (Indicators of Compromise) gedeeld die kunnen helpen bepalen of een omgeving is getroffen. De belangrijkste hiervan zijn de volgende:

Op de netwerkzijdeZoek naar communicatie met:

  • Domain: sfrclakcom
  • IP adres: 142.11.206.73

Beide indicatoren zijn door de grote beveiligingsleveranciers geblokkeerd, maar ze blijven nuttige markeringen in historische logboeken en SIEM-zoekopdrachten.

Op de bestandssysteemOnderzoekers hebben artefacten in verband met de RAT onder de aandacht gebracht:

  • MacOS: /Library/Caches/com.apple.act.mond
  • Linux: /tmp/ld.py
  • Windows: bestanden onder %PROGRAMDATA%\wt en tijdelijke scripts zoals %TEMP%\6202033.vbs or .ps1 die mogelijk slechts kortstondig bestaan ​​tijdens de uitvoering

Wat betreft npm-pakketten, de gecompromitteerde builds en hun bekende checksums zijn:

  • axios@1.14.1, SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
  • axios@0.30.4, SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
  • plain-crypto-js@4.2.1, SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

Beveiligingsbedrijven zoals Huntress hebben ten minste geconstateerd 135 systemen die contact opnemen met de command-and-controlserver van de aanvaller Tijdens de relatief korte periode waarin de gegevens openbaar werden gemaakt, waarschuwden onderzoekers van Google dat daardoor uiteindelijk mogelijk "honderduizenden" geheimen zijn gelekt.

Wie zat er achter de aanslag? De verantwoordelijkheid en de link met Noord-Korea.

De Threat Intelligence Group van Google heeft de inbreuk op Axios publiekelijk in verband gebracht met een verdachte Noord-Koreaanse dreigingsacteur getraceerd als UNC1069. John Hultquist, hoofdanalist bij de dreigingseenheid van Google, merkte op dat Noord-Koreaanse operators een lange geschiedenis hebben van... Supply chain-aanvallen gericht op het stelen van cryptovaluta en andere activa.

Volgens Google en andere beveiligingsbedrijven lijkt het Axios-incident onderdeel te zijn van een bredere campagne van Noord-Koreaanse groeperingen, waaronder organisaties zoals Lazarus, die zich richten op... afpersing, financiële diefstal en data-exfiltratie gericht op sectoren zoals crypto, fintech en cloudinfrastructuur.

Hoewel de volledige impact nog onduidelijk is, doet de combinatie van een enorm populair pakket, toegang tot ontwikkelomgevingen en de aard van de gestolen gegevens analisten vermoeden dat de gevolgen ernstig zullen zijn. vervolgaanvallen in de vorm van verdere verstoringen van de toeleveringsketen, ransomware en directe cryptodiefstal.

Hoe het beheerdersaccount en de npm-workflow werden misbruikt

Een van de meest verontrustende aspecten voor de open-sourcegemeenschap is hoe de aanvallers erin slaagden kwaadaardige Axios-versies te publiceren zonder de openbare codebase aan te raken. De sleutel was een gehackt beheerdersaccount op npmwaarvan wordt aangenomen dat het toebehoort aan een belangrijke Axios-beheerder genaamd jasonsaayman.

De aanvallers zouden het e-mailadres dat aan dat npm-account was gekoppeld, hebben gewijzigd naar een adres dat ze zelf beheerden. Daarmee konden ze... Sluit de rechtmatige beheerder buiten. en nieuwe pakketversies pushen alsof het echte updates waren, terwijl de officiële GitHub-repository gewoon schoon bleef.

De operatie bracht ook een structureel probleem in npm aan het licht: ondersteuning voor oude authenticatietokens, en de behoefte aan tools voor supply chain management en een strenger beleid ten aanzien van tokens.

In dit geval wezen beveiligingsonderzoekers erop dat npm nog steeds standaard ingesteld op het oude token voor publicatie, en er was geen controlemechanisme dat dat token automatisch introk zodra modernere publicatiemethoden werden geconfigureerd. Die co-existentie creëerde een kwetsbare achterdeur die UNC1069 kon misbruiken.

Blootstellingsperiode en vroege detectie

De inbreuk op Axios was geen langdurig proces. Onderzoek wijst uit dat de kwaadaardige versies ongeveer drie uur beschikbaar op npm tussen de late zondagavond en de vroege uren van maandag of dinsdag, afhankelijk van de tijdzone.

StepSecurity en andere bedrijven merkten op dat de aanvaller het ecosysteem had geïnfecteerd met een een schone versie van de schadelijke afhankelijkheid ongeveer 18 uur eerder Het koppelen van de gemanipuleerde variant aan Axios. Deze stap lijkt bedoeld te zijn geweest om een ​​onschadelijke geschiedenis voor het pakket op te bouwen en te voorkomen dat geautomatiseerde anomaliedetectoren geactiveerd zouden worden wanneer de afhankelijkheid plotseling opdook.

Nadat de geïnfecteerde Axios-versies live waren gegaan, voerde de trojan uitgebreide verkenning uit op elk systeem waarop hij draaide: Mappen scannen, actieve processen weergeven, schijven opsommen en vervolgens die informatie terugsturen naar de server van de aanvaller. Dit alles gebeurde achter de schermen tijdens wat voor ontwikkelaars een routineuze installatie van afhankelijkheden leek.

Dankzij een gecoördineerde reactie van de beheerder, npm en diverse beveiligingsleveranciers werden de schadelijke versies binnen enkele uren verwijderd. Zoals verschillende onderzoekers en het team van Google zelf echter benadrukten, Een korte blootstellingsperiode is niet hetzelfde als een laag risico. wanneer het doelwit een bibliotheek is met tientallen miljoenen wekelijkse downloads.

Impact op ontwikkelaars, cryptoprojecten en eindgebruikers

Vanuit praktisch oogpunt zijn de meest directe slachtoffers van het Axios-incident: ontwikkelaars en bouwomgevingen die de schadelijke versies installeerden. Iedereen die een installatie of build heeft uitgevoerd waarbij axios@1.14.1, axios@0.30.4 of plain-crypto-js@4.2.1 met ingeschakelde scripts werd geïnstalleerd, moet ervan uitgaan dat het systeem volledig gecompromitteerd kan zijn.

Voor projecten in de cryptovaluta-sector – wallets, gecentraliseerde en gedecentraliseerde exchanges, DeFi-dashboards, handelsbots en Web3-frontends – staat er bijzonder veel op het spel. Veel van deze systemen afhankelijk zijn van Axios voor de communicatie met blockchain-gateways, API's en backend-servicesEn ze beheren vaak gevoelige geheimen zoals privésleutels, API-gegevens en gebruikersgegevens.

Als een ontwikkelaarswerkstation of CI-agent in een dergelijk project geïnfecteerd raakte, konden aanvallers niet alleen de lokaal opgeslagen geheimen bemachtigen, maar ook toegang tot repositories en implementatiepipelinesDaarmee zouden ze mogelijk kwaadaardige code in toekomstige releases kunnen injecteren, eindgebruikers indirect kunnen schaden of geldstromen kunnen omleiden.

Gebruikers die simpelweg voltooide applicaties in hun browser uitvoeren, bevinden zich daarentegen in een betere positie: de RAT werd geleverd tijdens installatie- en montagestappenNiet tijdens de uitvoering in de browser. Het bezoeken van een site die Axios gebruikt voor client-side aanroepen, activeert de aanval dus niet vanzelf. Het risico concentreert zich op degenen die de betreffende npm-pakketten hebben geïnstalleerd.

Directe stappen die ontwikkelaars moeten nemen

Beveiligingsteams en beheerders zijn duidelijk geweest: als er ook maar een kleine kans bestaat dat uw systemen de gecompromitteerde Axios- of plain-crypto-js-releases hebben binnengehaald, beschouw die hosts dan als volledig onbetrouwbaar totdat het is onderzochtDat betekent meer dan alleen het verhogen van een versienummer.

Concrete acties die door onderzoekers en leveranciers worden aanbevolen, zijn onder meer:

  • Controleer uw afhankelijkheden en lockfiles: Zoek naar axios@1.14.1, axios@0.30.4 en plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock en CI-logboeken; zie hoe je ze veilig kunt repareren.
  • Upgrade naar geverifieerde veilige versies: Ga over op schone Axios-releases (bijvoorbeeld de direct daaropvolgende gepatchte tags die door de beheerders worden aanbevolen) en zorg ervoor dat uw lockfiles opnieuw worden gegenereerd.
  • Vernieuw je inloggegevens regelmatig: Ga ervan uit dat alle geheime gegevens op de getroffen machines of pipelines – cloud-API-sleutels, npm-tokens, SSH-sleutels, implementatiesleutels, .env-variabelen – mogelijk zijn gestolen en vervang deze regelmatig.
  • Herstel beschadigde systemen: Herimplementeer waar mogelijk buildagents, CI-runners en ontwikkelwerkstations vanuit vertrouwde images in plaats van ze ter plaatse te proberen op te schonen.
  • Infrastructuur van blok C2: Toevoegen sfrclak.com en 142.11.206.73 naar firewalls, DNS-blokkeerlijsten en EDR-regels.
  • Zoektocht naar artefacten: Controleer de bestandspaden en tijdelijke bestanden die bij de RAT horen op macOS-, Windows- en Linux-systemen.

Verschillende beveiligingsbedrijven hebben organisaties die de besmette versies hebben geïnstalleerd, geadviseerd om standaard uitgaan van compromis.Met andere woorden: ga ervan uit dat de aanvallers toegang hadden en doorloop systematisch de stappen voor incidentbestrijding in plaats van te hopen dat de malware niets heeft aangericht.

Bredere lessen voor de beveiliging van de softwaretoeleveringsketen

Naast de directe noodmaatregelen heeft het Axios-incident het debat over de manier waarop het bredere ecosysteem omgaat met vertrouwen, identiteit en distributie in open source weer aangewakkerd. Het illustreert hoe een account voor beheerder van één bibliotheek kan een cruciale factor worden in de beveiligingsstrategie van talloze organisaties.

Uit analyses achteraf en leveranciersonderzoek zijn verschillende thema's naar voren gekomen:

  • Legacy-tokens vormen een last: Oude npm-tokens kunnen ongemerkt blijven bestaan ​​naast nieuwere, op OIDC gebaseerde workflows. Projecten hebben expliciete beleidsregels nodig om ze in te trekken zodra er veiligere methoden beschikbaar zijn.
  • Geautomatiseerde updates hebben twee kanten: Automatische afhankelijkheidsupdates versnellen de ontwikkeling, maar betekenen ook dat een kwaadaardige release zich door ecosystemen kan verspreiden voordat iemand het merkt.
  • Afhankelijkheidsanalyse is noodzakelijk, maar niet voldoende: Statische controles en npm audit zijn nuttig, maar ze hebben het moeilijk tegen vluchtig gedrag zoals zelfverwijderende postinstallatiescripts.
  • Beveiliging van de beheerder is een kritieke infrastructuur: Sterke MFA, hardwarematige beveiligingssleutels, zorgvuldige omgang met toegangstokens en regelmatige controle van wie mag publiceren zijn nu net zo belangrijk als het schrijven van goede code.

Voor oprichters, CTO's en technische leiders is het compromis van Axios een herinnering dat Risico's in de toeleveringsketen vormen een strategische kwestie.Het gaat niet alleen om een ​​technisch aspect. Het beïnvloedt hoe snel je kunt leveren, hoe je je CI/CD-pipelines ontwerpt en hoe je het gemak van open source afweegt tegen de noodzaak om te controleren of wat je in productie draait.

Samengevat laat de inbreuk op Axios op npm zien hoe een kortstondige maar goed geplande aanval een vertrouwde bouwsteen van het JavaScript-ecosysteem kan veranderen in een heimelijke toegangspoort voor malware die toegang op afstand mogelijk maakt. Nu aanvallers zich net zozeer richten op beheerders en distributiekanalen als op eindgebruikers, hangt het gezond houden van softwareleveringsketens af van strengere controles op publicatieprocessen, agressieve monitoring op afwijkingen en de bereidheid om afhankelijkheden met dezelfde scepsis te benaderen als voorheen alleen gold voor extern netwerkverkeer.

auditoría de seguridad npm
Gerelateerd artikel:
Uitgebreide handleiding voor NPM-beveiligingsaudits en supply-chain-aanvallen
Gerelateerde berichten: