- En angriper kompromitterte npm-kontoen til den primære vedlikeholderen av Axios og ga ut versjon 1.14.1 og 0.30.4 med en fantomavhengighet, plain-crypto-js, som distribuerte en plattformuavhengig RAT under installasjonen.
- Skadevaren kontaktet en C2-server (sfrclak[.]com) og lastet ned spesifikke nyttelaster for Windows, macOS og Linux, utførte systemrekognosering, vedlikeholdt periodiske beacons og i noen tilfeller etablerte persistens.
- Angrepet, som Google og andre forskere tilskrev den nordkoreanske aktøren UNC1069, kombinerte et eksponeringsvindu på omtrent tre timer med en sofistikert sosial manipuleringskampanje mot vedlikeholderen for å stjele deres legitimasjon.
- Organisasjoner som klarte å installere de berørte versjonene må forplikte seg til å iverksette tiltak, søke etter RAT-artefakter, rotere legitimasjonsinformasjon, feste sikre versjoner av Axios og styrke kontrollene for forsyningskjede, CI/CD og avhengighetshåndtering.
JavaScript-utviklingsmiljøet har nettopp opplevd en av de skremselshendelsene som får deg til å revurdere hvor mye du stoler på avhengighetene dine, noe som demonstreres av sårbarhetsproblemer i biblioteker . Axios, et av de mest brukte HTTP-bibliotekene i økosystemet, ble manipulert på npm for å distribuere en trojaner for ekstern tilgang (RAT) gjennom tilsynelatende legitime versjoner. Hendelsen varte bare noen få timer, men den har gjort det klart at programvareforsyningskjeden henger i en mye tynnere tråd enn mange trodde.
Det alvorlige problemet er ikke bare at angriperne klarte å snike skadelig programvare inn i en pakke som ble lastet ned titalls eller hundrevis av millioner ganger i uken. Det virkelige problemet er at de gjorde det ved å kapre hovedvedlikeholderens npm-konto, og publisere "offisielle" versjoner som så normale ut og ikke berørte en eneste linje med Axios-kildekoden . All den ondsinnede oppførselen befant seg i en fantomavhengighet som var spesielt designet for angrepet.
Hvordan Axios' forpliktelse til npm oppsto
For å forstå omfanget av hendelsen må vi starte med inngangspunktet. Angriperen klarte å ta kontroll over npm-kontoen til «jasonsaayman», hovedvedlikeholderen av Axios, og endret den tilknyttede e-postadressen til en under deres kontroll , hostet på Proton Mail. Fra det øyeblikket hadde de fritt spillerom til å publisere nye versjoner av pakken som om de var vedlikeholderen.
Ved å bruke disse påloggingsinformasjonene lastet han opp to ondsinnede versjoner av Axios: 1.14.1 og 0.30.4 , som dekker begge hovedgrenene av prosjektet. Opplastingene ble gjort med bare 39 minutters mellomrom, og ifølge StepSecuritys analyse ble de gjort direkte fra npm ved hjelp av en klassisk langlivet token, som fullstendig omgikk den vanlige CI/CD-pipelinen basert på GitHub Actions.
Atten timer før det siste angrepet hadde aktøren allerede publisert en «ren» versjon relatert til den ondsinnede avhengigheten i npm-registeret . Dette innledende trinnet tjente til å generere en historikk og forhindre at noen automatiserte kontroller ble utløst når en helt ny pakke dukket opp på tidspunktet for angrepet.
Det som er slående er at angriperne ikke endret Axios' kildekode eller gjorde noen synlige endringer i GitHub-depotet . Faktisk hadde versjon 1.14.1 og 0.30.4 ingen tilsvarende commits eller tagger på GitHub; de eksisterte bare på npm. Hovedforskjellen lå i pakkens avhengighetsfil, som ble publisert i registeret.
Under normale omstendigheter deklarerer Axios bare tre avhengigheter: follow-redirects, form-data og proxy-from-env . I de kompromitterte versjonene dukket det imidlertid opp en fjerde avhengighet, en som tidligere ikke eksisterte i prosjektet: plain-crypto-js, versjon 4.2.1. Dette fantombiblioteket ble ikke brukt noe sted i Axios-kodebasen, men det inkluderte et post-installasjonsskript som kjørte automatisk når pakken ble installert med npm, pnpm eller lignende verktøy.
plain-crypto-js: fantomavhengigheten distribuert av RAT
Nøkkelen til angrepet lå i den ekstra avhengigheten. plain-crypto-js ble publisert på npm av en bruker ved navn «nrwise», også med en Proton Mail-e-postadresse, og dens eneste formål var å kjøre et obfuskert etterinstallasjonsskript i Node.js (setup.js) . Skriptet fungerte som en dropper, det vil si som det første installasjonsprogrammet for skadevarens andre fase.
Da Axios ble installert i en av de forgiftede versjonene, utløste npm-livssyklusen etter installasjon automatisk plain-crypto-js-koden uten at utvikleren måtte foreta noen spesiell handling . Dropperen koblet seg til en kommando- og kontrollserver (C2) som var aktiv i sfrclakcom-domenet, lyttet på port 8000, og lastet ned en nyttelast spesifikk for operativsystemet til den berørte maskinen. Denne oppførselen kan identifiseres gjennom nettverkstrafikkanalyse.
Forskere ved StepSecurity og andre analyseteam beskriver en svært forsiktig oppførsel. Etter å ha kjørt den ondsinnede nyttelasten, fjernet dropperen sine egne spor: den slettet postinstall-skriptet, erstattet package.json-filen med en "ren" versjon og etterlot en node_modules-fil som ved første øyekast virket harmløs . På denne måten fant ikke en påfølgende manuell inspeksjon den ondsinnede koden direkte i Axios.
For å identifisere manipulasjonen var det eneste pålitelige sporet i låsefilene (package-lock.json, pnpm-lock.yaml, yarn.lock) og tilstedeværelsen av spesifikke versjoner: axios 1.14.1 eller 0.30.4 og plain-crypto-js 4.2.1, i tillegg til to versjoner av den pakken med mellomliggende tall (4.2.0, 4.2.2) som er koblet sammen i noen analyser. Socket oppdaget på sin side senere at den samme skadelige programvaren også ble distribuert gjennom pakkene @shadanai/openclaw (forskjellige versjoner 2026.3.xx) og @qqbrowser/openclaw-qbot (0.0.130), og sikkerhetsteknikker som honeypots kan også bidra til å identifisere lignende kampanjer.
RAT på tvers av plattformer: Windows, macOS og Linux i søkelyset
Etter kjøring fungerte setup.js-skriptet som en orkestrator som var i stand til å oppdage operativsystemet og følge en plattformspesifikk angrepsbane . Kampanjen var tydelig forberedt på forhånd: ifølge StepSecurity hadde angriperne tre separate nyttelaster forhåndskompilert, én for hvert system.
På macOS-systemer startet etterinstallasjonsprosessen en AppleScript som lastet ned en trojanisert binærfil fra sfrclakcom:8000-serveren . Denne binærfilen ble lagret i /Library/Caches/com.apple.act.mond-banen, tillatelsene ble justert for å gjøre den kjørbar, og til slutt ble den startet i bakgrunnen ved hjelp av /bin/zsh. Når RAT-en kjørte, ble selve AppleScript-en slettet for å komplisere den rettsmedisinske analysen ytterligere.
På Windows-maskiner fant skadevaren systemets PowerShell-binærfil, kopierte den til %PROGRAMDATA%\wt.exe for å skjule den som Windows-terminalen, og genererte et midlertidig VBScript . Dette VBScriptet kontaktet deretter C2-serveren for å laste ned et ekstra PowerShell RAT-skript, kjørte det og slettet deretter den nedlastede filen. Videre opprettet Windows-varianten %PROGRAMDATA%\system.bat-filen med en nedlastingsrutine som tillot skadevaren å hente seg selv ved hver pålogging og la til en utførelsesnøkkel i Windows-registeret for å sikre persistens.
På Linux og andre Unix-lignende systemer foruten macOS, brukte dropperen Node.js sin execSync til å starte en shell-kommando som lastet ned et Python-skript fra sfrclakcom, lagret det som /tmp/ld.py og utførte det med nohup for å holde det kjørende i bakgrunnen . I motsetning til Windows viste ikke denne varianten en robust persistensmekanisme, noe som tyder på en raskere datautfiltreringsorientert tilnærming eller sporadisk distribusjon av persistens via påfølgende kommandoer.
SafeDep og Elastic Security Labs analyserte nyttelastene på andre nivå og konkluderte med at RAT-ene for macOS (C++ Mach-O binær) og Linux (Python-skript) delte samme kommandosett, C2-protokoll, meldingsformat og driftsatferd . Denne typen analyse er vanligvis avhengig av skannetjenester som VirusTotal , som forenkler korrelasjonen av prøver og IOC-er.
I alle tilfeller utførte hver kompromitterte vert en umiddelbar systemrekognosering: brukerkataloger, stasjonsrøtter, aktive prosesser og andre metadata . Denne informasjonen ble sendt til kommando- og kontrollserveren, og agenten opprettholdt en beacon-løkke på omtrent 60 sekunder, mens den ventet på nye instruksjoner, inkludert utførelse av tilleggsskript eller injeksjon av binærfiler i minnet.
Eksponeringsvindu, mål og tilskrivelse til Nord-Korea
De skadelige versjonene av Axios var tilgjengelige på npm i omtrent tre timer, i løpet av en nøye valgt tidsramme. De kompromitterte pakkene ble publisert like før midnatt søndag (et tidspunkt som maksimerte forsvarernes reaksjonstid), og hendelsen ble innhentet tidlig mandag morgen , etter at sikkerhetsfirmaer varslet myndighetene om den avvikende oppførselen.
I løpet av den relativt korte perioden oppdaget Huntress minst 135 systemer som koblet seg til angriperens server . Gitt at Axios registrerer mer enn 80–100 millioner nedlastinger per uke (ifølge ulike kilder, til og med mer enn 300 millioner i noen perioder), representerer dette tallet sannsynligvis bare toppen av isfjellet, begrenset til systemene som kommer til oppmerksomheten til analysefirmaer som har offentliggjort dataene sine.
Google, gjennom sitt trusselintelligensteam, tilskrev angrepet til en mistenkt nordkoreansk aktør merket UNC1069 . Elastic Security Labs forsterket denne hypotesen ved å finne en sterk likhet mellom RAT levert på macOS og WAVESHAPER, en C++-bakdør oppdaget av Mandiant og også koblet til den samme trusselgruppen.
Google-analytikere understreket at grupper med tilknytning til Nord-Korea har spesialisert seg på angrep i forsyningskjeden og kryptovalutatyveri i årevis . Mønsteret er konsistent: de kompromitterer utviklingsinfrastruktur, mye brukte biblioteker eller pålitelig programvare for deretter å bevege seg lateralt mot mål som administrerer verdifulle eiendeler, private nøkler eller legitimasjon.
Flere rapporter fremhevet også at modereringen og utformingen av angrepet antydet et godt koordinert team : tre parallelle implementeringer av samme RAT (PowerShell, C++ og Python), en konsistent C2-protokoll, nesten identisk oppførsel på tvers av alle varianter, og en tydelig selvrensende strategi for å unngå å etterlate spor. Elastic understreket at denne konsistensen peker mot en enkelt utvikler eller en gruppe som jobber ut fra et delt designdokument, langt fra improvisasjon.
Utover de rent tekniske aspektene, er et av de mest urovekkende punktene i saken hvordan hovedvedlikeholderens npm-konto ble kapret. Axios-sjefen selv forklarte senere at han hadde tofaktorautentisering aktivert på nesten alle tjenestene sine , og likevel endte han opp med å gi tilgang uten å innse det.
Ifølge obduksjonsanalysen som teamet delte, satte angriperne i gang en svært omfattende sosial manipuleringsoperasjon, støttet av AI-drevne verktøy, for å vinne deres tillit . De utga seg for å være grunnleggeren av et selskap, og kopierte selskapets visuelle identitet, fotografi og til og med bedriftens merkevarebygging. De opprettet et ekte Slack-område med firmalogoen, kanaler med innlegg som angivelig var synkronisert med LinkedIn, og til og med falske profiler av ansatte og andre vedlikeholdere av åpen kildekode-programvare.
Innenfor dette miljøet planla de et møte via Microsoft Teams der en hel gruppe fagfolk tilsynelatende deltok . Under møtet simulerte de et teknisk problem og indikerte at en komponent i systemet deres var utdatert. Vedlikeholdsteknikeren, som antok at det var et legitimt krav knyttet til selve videokonferanseverktøyet, lastet ned og installerte den foreslåtte filen.
Den filen var faktisk trojaneren for fjerntilgang som tillot angriperne å vende seg til offerets påloggingsinformasjon og til slutt ta kontroll over npm-kontoen som ble brukt til å publisere Axios . Hele prosessen var så godt orkestrert, med så mange troverdige detaljer, at offeret beskrev den som «perfekt koordinert, profesjonell og fullstendig overbevisende».
Dette menneskelige elementet i hendelsen gjør det klart at selv tekniske tiltak som 2FA er utilstrekkelige når sosial manipulering på høyt nivå kombineres med visuell etterligning, deepfakes eller detaljert kloning av organisasjoner . Det svakeste leddet er nok en gang menneskelig interaksjon.
Innvirkning på organisasjoner og utviklere som bruker Axios
Fra et praktisk synspunkt er hovedproblemet å finne ut hvem som faktisk ble berørt. Enhver organisasjon som installerte [email protected] eller [email protected] i løpet av vinduet de var tilgjengelige, bør anta at maskinen eller pipelinen som utførte installasjonen kan være kompromittert.
Anbefalingene fra firmaer som StepSecurity, Aikido, Huntress og Elastic er utvetydige. Ved mistanke er en proaktiv tilnærming nødvendig, ikke bare å "slette og installere node_modules på nytt ." Den kloke fremgangsmåten er å gjenoppbygge de berørte maskinene eller miljøene fra klarerte bilder og nøye gjennomgå CI/CD-loggene for å identifisere hvilke jobber eller pipelines som kan ha kjørt de kompromitterte versjonene.
Videre er det kritisk å rotere alle påloggingsinformasjoner og hemmeligheter som RAT-en kan ha tilgang til fra disse nodene : npm-tokens, skyleverandørnøkler, pipeline-hemmeligheter, databasepåloggingsinformasjon, SSH-nøkler osv. Å la disse påloggingsinformasjonene være i omløp etter et slikt angrep åpner døren for stille lateral bevegelse.
På et teknisk nivå bør team gjennomgå låsefilene sine (package-lock.json, pnpm-lock.yaml, yarn.lock) for referanser til de kompromitterte versjonene av Axios og plain-crypto-js . Hvis disse elementene blir funnet, er neste trinn å inspisere de berørte systemene for potensielle RAT-artefakter: /Library/Caches/com.apple.act.mond på macOS, %PROGRAMDATA%\wt.exe og %PROGRAMDATA%\system.bat på Windows, eller /tmp/ld.py på Linux.
Parallelt anbefales det å eksplisitt angi sikre versjoner av Axios, som 1.14.0 og 0.30.3, og bruke overstyringer eller løsningsmekanismer for å forhindre at transitive avhengigheter omdannes til uønskede versjoner . Å blokkere utgående trafikk til sfrclakcom-domenet er også et fornuftig inneslutningstiltak, i hvert fall mens hele omfanget av angrepet analyseres.
Sikkerhetsleksjoner for programvareforsyningskjeden
Axios-hendelsen er ikke en isolert hendelse, men et nytt ledd i en kjede av angrep i forsyningskjeden som inkluderer tilfeller som SolarWinds, Kaseya, 3CX, Polyfill.io og sårbarheter som utnyttes i Log4j. Kjerneideen er alltid den samme: å kompromittere en mye brukt, pålitelig komponent for å maksimere rekkevidden , i stedet for å forsøke å angripe maskin for maskin.
En av de oftest gjentatte lærdommene fra eksperter er at tillit ikke kan stole utelukkende på populariteten til et bibliotek eller omdømmet til en vedlikeholder . Hvis utgivelseskanalen (npm-kontoen, CI/CD-pipelinen, byggeinfrastrukturen) blir kompromittert, arver alt som gis ut gjennom den den risikoen. Manuell kodegjennomgang er heller ikke tilstrekkelig hvis skadelig programvare gjemmer seg i transitive avhengigheter og sletter seg selv etter kjøring.
Det har også blitt fremhevet at «standardhastigheten» for avhengighetsoppdateringer har en kostnad når det gjelder angrepsflate . Å alltid automatisk ta i bruk den nyeste versjonen er utrolig praktisk, men det åpner døren for at en ondsinnet oppdatering kan spre seg i løpet av minutter. Noen organisasjoner vurderer allerede retningslinjer som å kreve at en ny versjon har vært i økosystemet i en viss periode før adopsjon, eller at endringer i kritiske pakker må gjennomgå ytterligere manuell gjennomgang.
Når det gjelder utviklingsinfrastruktur, må CI/CD-miljøer behandles som svært sensitive ressurser . Enhver RAT som kjøres under avhengighetsinstallasjon vil nesten helt sikkert søke pipeline-hemmeligheter og tilgang til andre miljøer. Å segmentere disse nodene, overvåke dem nøyere og rotere hemmelighetene deres med jevne mellomrom er ikke lenger en "ideell" anbefaling, men en nødvendighet.
Til slutt krever det å oppdage denne typen angrep å kombinere informasjon fra flere kilder: installerte versjoner, låsefiler, indikatorer på kompromitterte operativsystemer og nettverkstelemetri . Verktøy som genererer og administrerer programvarelister (SBOM-er) hjelper med å raskt spore hvilke prosjekter som bruker hvilke pakker, noe som er viktig når massive varsler som dette utløses.
Hele denne episoden med Axios illustrerer i hvilken grad avhengighetsøkosystemet, uansett hvor modent og konsolidert det kan virke, fortsatt er sterkt avhengig av tillit og konstant årvåkenhet. Et tilsynelatende uskyldig bibliotek, vedlikeholdt av én person som blir offer for et godt utført sosialt manipuleringsangrep, kan i løpet av få timer bli en global vektor for utplassering av plattformuavhengige RAT-er mot selskaper, frilansere og organisasjoner i alle størrelser . Styrking av kontrollene rundt publiseringskontoer, pipelines og kritiske avhengigheter er ikke lenger en valgfri beste praksis, men en forutsetning for fortsatt utvikling i et miljø der angripere er stadig mer tålmodige, ressurssterke og utstyrt med bedre verktøy.
