- Un atacator a compromis contul npm al principalului administrator al Axios și a lansat versiunile 1.14.1 și 0.30.4 cu o dependență fantomă, plain-crypto-js, care a implementat un RAT multiplatformă în timpul instalării.
- Malware-ul a contactat un server C2 (sfrclak[.]com) și a descărcat sarcini specifice pentru Windows, macOS și Linux, efectuând recunoaștere a sistemului, întreținând beacon-uri periodice și, în unele cazuri, stabilind persistența.
- Atacul, atribuit de Google și alți cercetători actorului nord-coreean UNC1069, a combinat o fereastră de expunere de aproximativ trei ore cu o campanie sofisticată de inginerie socială împotriva responsabilului cu gestionarea datelor, pentru a-i fura acreditările.
- Organizațiile care au reușit să instaleze versiunile afectate trebuie să se angajeze să ia măsuri, să caute artefacte RAT, să rotească acreditările, să fixeze versiuni securizate de Axios și să își consolideze lanțul de aprovizionare, CI/CD și controalele de gestionare a dependențelor.
Comunitatea dezvoltatorilor JavaScript tocmai a trecut prin una dintre acele situații de alarmă care te fac să te răzgândești cât de multă încredere ai în dependențele tale, după cum demonstrează problemele de vulnerabilitate ale bibliotecilor . Axios, una dintre cele mai utilizate biblioteci HTTP din ecosistem, a fost manipulată pe npm pentru a distribui un troian de acces la distanță (RAT) prin versiuni aparent legitime. Incidentul a durat doar câteva ore, dar a arătat clar că lanțul de aprovizionare cu software atârnă de un fir mult mai subțire decât credeau mulți.
Problema serioasă nu este doar că atacatorii au reușit să strecoare malware într-un pachet descărcat de zeci sau sute de milioane de ori pe săptămână. Adevărata problemă este că au făcut-o prin deturnarea contului npm al administratorului principal, publicând versiuni „oficiale” care păreau normale și nu atingeau nicio linie din codul sursă Axios . Întregul comportament malițios rezida într-o dependență fantomă special concepută pentru atac.
Cum a apărut angajamentul Axios față de npm
Pentru a înțelege amploarea incidentului, trebuie să începem cu punctul de intrare. Atacatorul a reușit să preia controlul asupra contului npm al lui „jasonsaayman”, principalul administrator al Axios, și a schimbat adresa de e-mail asociată cu una aflată sub controlul său , găzduită pe Proton Mail. Din acel moment, a avut mână liberă să publice noi versiuni ale pachetului ca și cum ar fi administratorul.
Folosind aceste acreditări, el a încărcat două versiuni malițioase ale Axios: 1.14.1 și 0.30.4 , acoperind ambele ramuri majore ale proiectului. Încărcările au fost efectuate la doar 39 de minute distanță și, conform analizei StepSecurity, au fost făcute direct din npm folosind un token clasic de lungă durată, ocolind complet canalul CI/CD obișnuit bazat pe GitHub Actions.
Cu optsprezece ore înainte de atacul final, actorul publicase deja o versiune „curată” legată de dependența malițioasă din registrul npm . Acest pas preliminar a servit la generarea unui istoric și la prevenirea declanșării unor verificări automate atunci când apărea un pachet complet nou în momentul atacului.
Ceea ce este surprinzător este că atacatorii nu au modificat codul sursă al Axios și nici nu au făcut modificări vizibile în depozitul GitHub . De fapt, versiunile 1.14.1 și 0.30.4 nu aveau commit-uri sau etichete corespunzătoare pe GitHub; acestea existau doar pe npm. Diferența cheie consta în fișierul de dependențe al pachetului, care era publicat în registru.
În circumstanțe normale, Axios declară doar trei dependențe: follow-redirects, form-data și proxy-from-env . Cu toate acestea, în versiunile compromise, a apărut o a patra dependență, una care anterior nu exista în proiect: plain-crypto-js, versiunea 4.2.1. Această bibliotecă fantomă nu a fost utilizată nicăieri în baza de cod Axios, dar includea un script post-instalare care rula automat la instalarea pachetului cu npm, pnpm sau instrumente similare.
plain-crypto-js: dependența fantomă implementată de RAT
Cheia atacului consta în acea dependență suplimentară. plain-crypto-js a fost publicat pe npm de către un utilizator numit „nrwise”, tot cu o adresă de e-mail Proton Mail, iar unicul său scop era să execute un script post-instalare ofuscat în Node.js (setup.js) . Scriptul respectiv a acționat ca un dropper, adică ca instalator inițial pentru a doua fază a malware-ului.
La instalarea Axios într-una dintre versiunile sale otrăvite, ciclul de viață post-instalare npm a declanșat automat codul plain-crypto-js fără a fi necesară nicio acțiune specială din partea dezvoltatorului . Dropper-ul s-a conectat la un server de comandă și control (C2) activ în domeniul sfrclakcom, ascultând pe portul 8000, și a descărcat o sarcină utilă specifică sistemului de operare al mașinii afectate; acest comportament poate fi identificat prin analiza traficului de rețea.
Cercetătorii de la StepSecurity și alte echipe de analiză descriu un comportament foarte atent. După executarea payload-ului malițios, dropper-ul și-a eliminat propriile urme: a șters scriptul postinstalare, a înlocuit fișierul package.json cu o versiune „curată” și a lăsat un fișier node_modules care, la prima vedere, părea inofensiv . În acest fel, o inspecție manuală ulterioară nu a găsit codul malițios direct în Axios.
Pentru a identifica manipularea, singurul indiciu fiabil se afla în fișierele de blocare (package-lock.json, pnpm-lock.yaml, yarn.lock) și prezența unor versiuni specifice: axios 1.14.1 sau 0.30.4 și plain-crypto-js 4.2.1, pe lângă două versiuni ale acelui pachet cu numere intermediare (4.2.0, 4.2.2) legate în unele analize. Socket, la rândul său, a detectat ulterior că același malware era distribuit și prin pachetele @shadanai/openclaw (diverse versiuni 2026.3.xx) și @qqbrowser/openclaw-qbot (0.0.130), iar tehnicile de securitate precum honeypot-urile pot ajuta, de asemenea, la identificarea campaniilor similare.
RAT multiplatformă: Windows, macOS și Linux în centrul atenției
Odată executat, scriptul setup.js a acționat ca un orchestrator capabil să detecteze sistemul de operare și să urmeze o cale de atac specifică platformei . Campania a fost în mod clar pregătită dinainte: conform StepSecurity, atacatorii aveau precompilate trei sarcini separate, câte una pentru fiecare sistem.
Pe sistemele macOS, procesul post-instalare a lansat un AppleScript care a descărcat un fișier binar troianizat de pe serverul sfrclakcom:8000 . Acest fișier binar a fost salvat pe calea /Library/Caches/com.apple.act.mond, permisiunile sale au fost ajustate pentru a-l face executabil și, în final, a fost pornit în fundal folosind /bin/zsh. Odată ce RAT rula, AppleScript-ul în sine a fost șters pentru a complica și mai mult analiza criminalistică.
Pe mașinile Windows, malware-ul a localizat fișierul binar PowerShell al sistemului, l-a copiat în %PROGRAMDATA%\wt.exe pentru a-l deghiza drept terminal Windows și a generat un VBScript temporar . Acest VBScript a contactat apoi serverul C2 pentru a descărca un script PowerShell RAT suplimentar, l-a executat și apoi a șters fișierul descărcat. În plus, varianta Windows a creat fișierul %PROGRAMDATA%\system.bat cu o rutină de descărcare care a permis malware-ului să se regăsească la fiecare conectare și a adăugat o cheie de execuție în registry-ul Windows pentru a asigura persistența.
Pe Linux și alte sisteme de tip Unix, în afară de macOS, dropper-ul folosea execSync din Node.js pentru a lansa o comandă shell care descărca un script Python din sfrclakcom, îl salva ca /tmp/ld.py și îl executa cu nohup pentru a-l menține în fundal . Spre deosebire de Windows, această variantă nu prezenta un mecanism robust de persistență, sugerând o abordare mai rapidă, orientată spre exfiltrarea datelor, sau implementarea ocazională a persistenței prin comenzi ulterioare.
SafeDep și Elastic Security Labs au analizat sarcinile utile de nivel secund și au concluzionat că RAT-urile pentru macOS (binar C++ Mach-O) și Linux (script Python) au avut în comun același set de comenzi, protocol C2, format de mesaj și comportament operațional . Acest tip de analiză se bazează de obicei pe servicii de scanare precum VirusTotal , care facilitează corelarea eșantioanelor și a IOC-urilor.
În toate cazurile, fiecare gazdă compromisă a efectuat o recunoaștere imediată a sistemului: directoarele utilizatorilor, unitățile rădăcină, procesele active și alte metadate . Aceste informații au fost trimise către serverul de comandă și control, iar agentul a menținut o buclă de semnalizare de aproximativ 60 de secunde, așteptând noi instrucțiuni, inclusiv executarea de scripturi suplimentare sau injectarea de fișiere binare în memorie.
Fereastra de expunere, obiective și atribuire Coreei de Nord
Versiunile malițioase ale Axios au fost disponibile pe npm timp de aproximativ trei ore, într-un interval de timp atent ales. Pachetele compromise au fost publicate chiar înainte de miezul nopții de duminică (o oră care a maximizat timpul de reacție al apărătorilor), iar incidentul a fost ținut sub control luni dimineață devreme , după ce firmele de securitate au alertat autoritățile cu privire la comportamentul anormal.
În acea perioadă relativ scurtă, Huntress a detectat cel puțin 135 de sisteme care se conectau la serverul atacatorului . Având în vedere că Axios înregistrează peste 80-100 de milioane de descărcări pe săptămână (conform diverselor surse, chiar peste 300 de milioane în unele perioade), acest număr reprezintă probabil doar vârful aisbergului, limitat la sistemele care ajung în atenția firmelor de analiză care și-au făcut publice datele.
Google, prin intermediul echipei sale de Threat Intelligence, a atribuit atacul unui presupus actor nord-coreean, numit UNC1069 . Elastic Security Labs a întărit această ipoteză descoperind o similaritate puternică între RAT-ul livrat pe macOS și WAVESHAPER, un backdoor C++ descoperit de Mandiant și, de asemenea, legat de același grup de amenințări.
Analiștii Google au subliniat că grupurile cu legături nord-coreene s-au specializat de ani de zile în atacuri asupra lanțului de aprovizionare și operațiuni de furt de criptomonede . Modelul este constant: compromiterea infrastructurii de dezvoltare, a bibliotecilor utilizate pe scară largă sau a software-ului de încredere, pentru a se deplasa apoi lateral către ținte care gestionează active de mare valoare, chei private sau acreditări.
Mai multe rapoarte au evidențiat, de asemenea, că moderarea și designul atacului sugerează o echipă bine coordonată : trei implementări paralele ale aceluiași RAT (PowerShell, C++ și Python), un protocol C2 consistent, un comportament aproape identic în toate variantele și o strategie clară de autocurățare pentru a evita lăsarea de urme. Elastic a subliniat că această consecvență indică un singur dezvoltator sau un grup care lucrează dintr-un document de design comun, departe de improvizație.
Dincolo de aspectele pur tehnice, unul dintre cele mai tulburătoare puncte ale cazului este modul în care a fost deturnat contul npm al administratorului principal. Însuși managerul Axios a explicat ulterior că avea activată autentificarea cu doi factori pe aproape toate serviciile sale și totuși a ajuns să acorde acces fără să-și dea seama.
Conform analizei post-mortem distribuite de echipă, atacatorii au pus la cale o operațiune de inginerie socială extrem de elaborată, susținută de instrumente bazate pe inteligență artificială, pentru a le câștiga încrederea . Au impersonat fondatorul unei companii, copiind identitatea vizuală, fotografia și chiar brandingul corporativ. Au creat un spațiu Slack real cu sigla companiei, canale cu postări presupus sincronizate cu LinkedIn și chiar profiluri false ale angajaților și ale altor administratori de software open-source.
În acel mediu, au programat o întâlnire prin Microsoft Teams la care părea să participe un grup complet de profesioniști . În timpul întâlnirii, au simulat o problemă tehnică și au indicat că o componentă a sistemului lor era învechită. Tehnicianul de întreținere, presupunând că era o cerință legitimă legată de instrumentul de videoconferință în sine, a descărcat și instalat fișierul sugerat.
Fișierul respectiv era, de fapt, troianul cu acces la distanță care le-a permis atacatorilor să acceseze datele de autentificare ale victimei și, în cele din urmă, să preia controlul asupra contului npm folosit pentru publicarea Axios . Întregul proces a fost atât de bine orchestrat, cu atât de multe detalii credibile, încât victima l-a descris ca fiind „perfect coordonat, profesional și complet convingător”.
Acest element uman al incidentului arată clar că până și măsurile tehnice precum 2FA sunt insuficiente atunci când ingineria socială la nivel înalt este combinată cu personificarea vizuală, deepfake-uri sau clonarea detaliată a organizațiilor . Veriga cea mai slabă, încă o dată, este interacțiunea umană.
Impactul asupra organizațiilor și dezvoltatorilor care utilizează Axios
Din punct de vedere practic, principala problemă este de a determina cine a fost de fapt afectat. Orice organizație care a instalat [email protected] sau [email protected] în fereastra în care acestea erau disponibile ar trebui să presupună că mașina sau canalul care a efectuat instalarea ar putea fi compromis.
Recomandările unor firme precum StepSecurity, Aikido, Huntress și Elastic sunt fără echivoc. În caz de suspiciune, este necesară o abordare proactivă, nu doar „ștergerea și reinstalarea node_modules ”. Acțiunea prudentă este reconstruirea mașinilor sau mediilor afectate din imagini de încredere și examinarea cu atenție a jurnalelor CI/CD pentru a identifica ce joburi sau conducte ar fi putut executa versiunile compromise.
În plus, este esențial să se rotească toate acreditările și secretele pe care RAT le-ar fi putut accesa de la acele noduri : token-uri npm, chei de furnizor cloud, secrete de pipeline, acreditări de bază de date, chei SSH etc. Lăsarea acestor acreditări în circulație după un astfel de atac lasă ușa deschisă pentru o mișcare laterală silențioasă.
La nivel tehnic, echipele ar trebui să își revizuiască fișierele de blocare (package-lock.json, pnpm-lock.yaml, yarn.lock) pentru referințe la versiunile compromise de Axios și plain-crypto-js . Dacă se găsesc aceste elemente, următorul pas este inspectarea sistemelor afectate pentru potențiale artefacte RAT: /Library/Caches/com.apple.act.mond pe macOS, %PROGRAMDATA%\wt.exe și %PROGRAMDATA%\system.bat pe Windows sau /tmp/ld.py pe Linux.
În paralel, se recomandă setarea explicită a unor versiuni securizate de Axios, cum ar fi 1.14.0 și 0.30.3, și utilizarea unor suprascrieri sau rezoluții pentru a preveni rezolvarea dependențelor tranzitive în versiuni nedorite . Blocarea traficului de ieșire către domeniul sfrclakcom este, de asemenea, o măsură sensibilă de izolare, cel puțin în timp ce se analizează întreaga amploare a atacului.
Lecții de securitate pentru lanțul de aprovizionare cu software
Incidentul Axios nu este un eveniment izolat, ci o altă verigă într-un lanț de atacuri asupra lanțului de aprovizionare care include cazuri precum SolarWinds, Kaseya, 3CX, Polyfill.io și vulnerabilități exploatate în Log4j. Ideea de bază este întotdeauna aceeași: compromiterea unei componente utilizate pe scară largă și de încredere pentru a maximiza acoperirea , în loc să se încerce atacarea mașinii cu mașini.
Una dintre cele mai frecvent repetate lecții de la experți este că încrederea nu se poate baza doar pe popularitatea unei biblioteci sau pe reputația unui responsabil de mentenanță . Dacă canalul de lansare (contul npm, canalul CI/CD, infrastructura de compilare) este compromis, tot ceea ce este lansat prin intermediul acestuia moștenește acel risc. Revizuirea manuală a codului este, de asemenea, insuficientă dacă malware-ul se ascunde în dependențe tranzitive și se șterge singur după execuție.
De asemenea, s-a subliniat faptul că „viteza implicită” pentru actualizările dependențelor are un cost în ceea ce privește suprafața de atac . Adoptarea automată și permanentă a celei mai recente versiuni este incredibil de convenabilă, dar deschide calea pentru răspândirea unei actualizări rău intenționate în câteva minute. Unele organizații iau deja în considerare politici precum impunerea ca o nouă versiune să fi fost în ecosistem o anumită perioadă înainte de adoptare sau impunerea ca modificările pachetelor critice să fie supuse unor revizuiri manuale suplimentare.
În ceea ce privește infrastructura de dezvoltare, mediile CI/CD trebuie tratate ca active extrem de sensibile . Orice RAT executat în timpul instalării dependențelor va căuta aproape sigur secrete de canal și acces la alte medii. Segmentarea acestor noduri, monitorizarea lor mai atentă și rotirea periodică a secretelor lor nu mai este o recomandare „ideală”, ci o necesitate.
În cele din urmă, detectarea acestor tipuri de atacuri necesită combinarea informațiilor din mai multe surse: versiuni instalate, fișiere de blocare, indicatori de compromitere ai sistemului de operare și telemetrie a rețelei . Instrumentele care generează și gestionează listele de materiale software (SBOM) ajută la urmărirea rapidă a proiectelor care utilizează anumite pachete, ceea ce este vital atunci când sunt declanșate alerte masive precum aceasta.
Întregul episod cu Axios ilustrează măsura în care ecosistemul de dependențe, oricât de matur și consolidat ar părea, se bazează încă în mare măsură pe încredere și vigilență constantă. O bibliotecă aparent inofensivă, întreținută de o singură persoană care cade victimă unui atac de inginerie socială bine executat, poate deveni, în câteva ore, un vector global pentru implementarea unor atacuri RAT multi-platformă împotriva companiilor, freelancerilor și organizațiilor de toate dimensiunile . Consolidarea controalelor în jurul conturilor de publicare, a conductelor și a dependențelor critice nu mai este o practică optimă opțională, ci o condiție prealabilă pentru dezvoltarea continuă într-un mediu în care atacatorii sunt din ce în ce mai răbdători, ingenioși și echipați cu instrumente mai bune.
