- Atakujący włamał się na konto npm głównego administratora platformy Axios i opublikował wersje 1.14.1 i 0.30.4 z pozorną zależnością plain-crypto-js, która podczas instalacji wdrażała wieloplatformowe narzędzie RAT.
- Szkodliwe oprogramowanie nawiązało kontakt z serwerem C2 (sfrclak[.]com) i pobrało określone ładunki dla systemów Windows, macOS i Linux, przeprowadzając rozpoznanie systemu, utrzymując okresowe sygnały nawigacyjne, a w niektórych przypadkach ustanawiając trwałość.
- Atak, który Google i inni badacze przypisują północnokoreańskiemu cyberprzestępcy UNC1069, łączył w sobie okres ekspozycji trwający około trzech godzin z wyrafinowaną kampanią socjotechniczną skierowaną przeciwko administratorowi systemu, mającą na celu kradzież jego danych uwierzytelniających.
- Organizacje, którym udało się zainstalować zagrożone wersje, muszą zobowiązać się do podjęcia działań, poszukiwania artefaktów RAT, rotacji danych uwierzytelniających, przypinania bezpiecznych wersji platformy Axios oraz wzmocnienia kontroli łańcucha dostaw, CI/CD i zarządzania zależnościami.
Społeczność programistów JavaScript właśnie doświadczyła jednego z tych problemów, które zmuszają do ponownego przemyślenia, na ile ufa się swoim zależnościom, co potwierdzają luki w zabezpieczeniach bibliotek . Axios, jedna z najpopularniejszych bibliotek HTTP w ekosystemie, została zmanipulowana w npm w celu dystrybucji trojana zdalnego dostępu (RAT) za pośrednictwem pozornie legalnych wersji. Incydent trwał zaledwie kilka godzin, ale pokazał wyraźnie, że łańcuch dostaw oprogramowania wisi na włosku, niż wielu przypuszczało.
Poważny problem nie polega tylko na tym, że atakującym udało się przemycić złośliwe oprogramowanie do pakietu pobieranego dziesiątki, a nawet setki milionów razy tygodniowo. Prawdziwy problem polega na tym, że dokonali tego, przechwytując konto npm głównego administratora i publikując „oficjalne” wersje, które wyglądały normalnie i nie zmieniały ani jednej linijki kodu źródłowego Axios . Całe złośliwe zachowanie było oparte na pozornej zależności zaprojektowanej specjalnie na potrzeby ataku.
Jak doszło do zaangażowania firmy Axios w npm
Aby zrozumieć skalę incydentu, musimy zacząć od punktu wejścia. Atakujący zdołał przejąć kontrolę nad kontem npm „jasonsaaymana”, głównego opiekuna Axios, i zmienił powiązany z nim adres e-mail na kontrolowany przez siebie , hostowany w Proton Mail. Od tego momentu mógł swobodnie publikować nowe wersje pakietu, tak jakby był jego opiekunem.
Korzystając z tych danych uwierzytelniających, wgrał dwie złośliwe wersje Axios: 1.14.1 i 0.30.4 , obejmujące obie główne gałęzie projektu. Wgrania nastąpiły w odstępie zaledwie 39 minut i, według analizy StepSecurity, zostały wykonane bezpośrednio z npm przy użyciu klasycznego, długowiecznego tokena, całkowicie omijając standardowy proces CI/CD oparty na GitHub Actions.
Osiemnaście godzin przed ostatecznym atakiem, sprawca opublikował już „czystą” wersję związaną ze szkodliwą zależnością w rejestrze npm . Ten wstępny krok miał na celu wygenerowanie historii i zapobiegnięcie uruchomieniu niektórych automatycznych sprawdzeń, gdy w momencie ataku pojawił się zupełnie nowy pakiet.
Uderzające jest to, że atakujący nie zmodyfikowali kodu źródłowego Axios ani nie wprowadzili żadnych widocznych zmian w repozytorium GitHub . W rzeczywistości wersje 1.14.1 i 0.30.4 nie miały żadnych odpowiadających im commitów ani tagów w GitHubie; istniały jedynie w npm. Kluczowa różnica tkwiła w pliku zależności pakietu, który został opublikowany w rejestrze.
Axios, w normalnych okolicznościach, deklaruje tylko trzy zależności: follow-redirects, form-data i proxy-from-env . Jednak w skompromitowanych wersjach pojawiła się czwarta zależność, która wcześniej nie istniała w projekcie: plain-crypto-js w wersji 4.2.1. Ta biblioteka-widmo nie była nigdzie używana w bazie kodu Axios, ale zawierała skrypt poinstalacyjny, który uruchamiał się automatycznie podczas instalacji pakietu za pomocą npm, pnpm lub podobnych narzędzi.
plain-crypto-js: zależność fantomowa wdrażana przez RAT
Klucz do ataku tkwił w tej dodatkowej zależności. Plik plain-crypto-js został opublikowany na platformie npm przez użytkownika o nazwie „nrwise”, również posiadającego adres e-mail w usłudze Proton Mail, a jego jedynym celem było wykonanie zaciemnionego skryptu poinstalacyjnego w Node.js (setup.js) . Skrypt ten działał jako dropper, czyli początkowy instalator drugiej fazy złośliwego oprogramowania.
Podczas instalacji Axios w jednej z jego zatrutych wersji, cykl życia npm po instalacji automatycznie uruchomił kod plain-crypto-js bez konieczności podejmowania żadnych specjalnych działań przez programistę . Dropper połączył się z serwerem poleceń i kontroli (C2) aktywnym w domenie sfrclakcom, nasłuchującym na porcie 8000, i pobrał ładunek specyficzny dla systemu operacyjnego zainfekowanej maszyny; to zachowanie można zidentyfikować poprzez analizę ruchu sieciowego.
Badacze z StepSecurity i innych zespołów analitycznych opisują bardzo ostrożne zachowanie. Po uruchomieniu złośliwego kodu dropper usunął swoje ślady: usunął skrypt postinstall, zastąpił plik package.json „czystą” wersją i pozostawił plik node_modules, który na pierwszy rzut oka wydawał się nieszkodliwy . W ten sposób późniejsza ręczna inspekcja nie wykryła złośliwego kodu bezpośrednio w systemie Axios.
Jedynym wiarygodnym tropem pozwalającym zidentyfikować manipulację były pliki blokady (package-lock.json, pnpm-lock.yaml, yarn.lock) oraz obecność konkretnych wersji: axios 1.14.1 lub 0.30.4 oraz plain-crypto-js 4.2.1, a także dwóch wersji tego pakietu o numerach pośrednich (4.2.0, 4.2.2) powiązanych w niektórych analizach. Socket z kolei wykrył później, że to samo złośliwe oprogramowanie było również dystrybuowane za pośrednictwem pakietów @shadanai/openclaw (różne wersje 2026.3.xx) i @qqbrowser/openclaw-qbot (0.0.130), a techniki bezpieczeństwa, takie jak honeypoty, również mogą pomóc w identyfikacji podobnych kampanii.
Międzyplatformowy RAT: Windows, macOS i Linux w centrum uwagi
Po uruchomieniu skrypt setup.js działał jak koordynator zdolny do wykrycia systemu operacyjnego i śledzenia ścieżki ataku specyficznej dla danej platformy . Kampania była ewidentnie przygotowana: według StepSecurity atakujący mieli trzy oddzielne pakiety danych wstępnie skompilowane, po jednym dla każdego systemu.
W systemach macOS proces poinstalacyjny uruchomił skrypt AppleScript, który pobrał z serwera sfrclakcom:8000 plik binarny z trojanem . Plik binarny został zapisany w ścieżce /Library/Caches/com.apple.act.mond, jego uprawnienia zostały dostosowane, aby umożliwić jego wykonywanie, a następnie został uruchomiony w tle za pomocą /bin/zsh. Po uruchomieniu narzędzia RAT sam skrypt AppleScript został usunięty, co dodatkowo skomplikowało analizę kryminalistyczną.
Na komputerach z systemem Windows złośliwe oprogramowanie zlokalizowało plik binarny programu PowerShell, skopiowało go do pliku %PROGRAMDATA%\wt.exe, aby ukryć go pod terminalem Windows, i wygenerowało tymczasowy skrypt VBScript . Skrypt ten następnie kontaktował się z serwerem C2 w celu pobrania dodatkowego skryptu RAT programu PowerShell, uruchamiał go, a następnie usuwał pobrany plik. Co więcej, wariant dla systemu Windows utworzył plik %PROGRAMDATA%\system.bat z procedurą pobierania, która umożliwiała złośliwemu oprogramowaniu pobieranie samego siebie przy każdym logowaniu, i dodawał klucz wykonania do rejestru systemu Windows, aby zapewnić jego trwałość.
W systemie Linux i innych systemach uniksopodobnych (oprócz macOS), dropper wykorzystywał funkcję execSync Node.js do uruchomienia polecenia powłoki, które pobierało skrypt Pythona z sfrclakcom, zapisywało go w pliku /tmp/ld.py i uruchamiało w środowisku Nohup, aby utrzymać go w tle . W przeciwieństwie do systemu Windows, ta wersja nie wykazywała solidnego mechanizmu utrwalania, co sugeruje szybsze podejście zorientowane na eksfiltrację danych lub sporadyczne wdrażanie utrwalania za pomocą kolejnych poleceń.
SafeDep i Elastic Security Labs przeanalizowały ładunki drugiego poziomu i doszły do wniosku, że narzędzia RAT dla systemu macOS (plik binarny C++ Mach-O) i Linuksa (skrypt Python) mają ten sam zestaw poleceń, protokół C2, format komunikatów i sposób działania . Ten typ analizy zazwyczaj opiera się na usługach skanowania, takich jak VirusTotal , które ułatwiają korelację próbek i wskaźników IOC.
We wszystkich przypadkach każdy zainfekowany host przeprowadzał natychmiastowy rekonesans systemu: katalogi użytkowników, katalogi główne dysków, aktywne procesy i inne metadane . Informacje te były przesyłane do serwera poleceń i kontroli, a agent utrzymywał pętlę sygnału przez około 60 sekund, oczekując na nowe instrukcje, w tym wykonanie dodatkowych skryptów lub wstrzyknięcie plików binarnych do pamięci.
Okno ekspozycji, cele i przypisanie Korei Północnej
Złośliwe wersje Axios były dostępne w npm przez około trzy godziny, w starannie dobranym przedziale czasowym. Zainfekowane pakiety zostały opublikowane tuż przed północą w niedzielę (co maksymalizowało czas reakcji obrońców), a incydent został opanowany wczesnym rankiem w poniedziałek , po tym jak firmy ochroniarskie powiadomiły władze o nietypowym zachowaniu.
W tym stosunkowo krótkim okresie Huntress wykrył co najmniej 135 systemów łączących się z serwerem atakującego . Biorąc pod uwagę, że Axios rejestruje ponad 80-100 milionów pobrań tygodniowo (według różnych źródeł, nawet ponad 300 milionów w niektórych okresach), liczba ta prawdopodobnie stanowi jedynie wierzchołek góry lodowej, ograniczając się do systemów, które zostały zauważone przez firmy analityczne i upublicznione.
Google, za pośrednictwem swojego zespołu ds. analizy zagrożeń, przypisał atak podejrzewanemu północnokoreańskiemu hakerowi o nazwie UNC1069 . Elastic Security Labs wzmocniło tę hipotezę, znajdując silne podobieństwo między RAT dostarczanym na macOS a WAVESHAPER, backdoorem w C++ odkrytym przez Mandiant i również powiązanym z tą samą grupą cyberprzestępczą.
Analitycy Google podkreślili, że grupy powiązane z Koreą Północną od lat specjalizują się w atakach na łańcuchy dostaw i kradzieżach kryptowalut . Schemat jest spójny: naruszają infrastrukturę programistyczną, powszechnie używane biblioteki lub zaufane oprogramowanie, a następnie atakują cele zarządzające wartościowymi aktywami, kluczami prywatnymi lub danymi uwierzytelniającymi.
W kilku raportach podkreślono również, że moderacja i projekt ataku sugerowały dobrze skoordynowany zespół : trzy równoległe implementacje tego samego narzędzia RAT (PowerShell, C++ i Python), spójny protokół C2, niemal identyczne zachowanie we wszystkich wariantach oraz przejrzystą strategię samooczyszczania, aby uniknąć pozostawiania śladów. Elastic podkreślił, że ta spójność wskazuje na pracę pojedynczego programisty lub grupy nad wspólnym dokumentem projektowym, a nie na improwizację.
Poza czysto technicznymi aspektami, jednym z najbardziej niepokojących punktów sprawy jest sposób, w jaki doszło do przejęcia konta npm głównego administratora. Sam menedżer Axios wyjaśnił później, że miał włączone uwierzytelnianie dwuskładnikowe w niemal wszystkich swoich usługach , a mimo to przyznał dostęp, nie zdając sobie z tego sprawy.
Według analizy pośmiertnej udostępnionej przez zespół, atakujący przeprowadzili wysoce skomplikowaną operację socjotechniczną, wspieraną przez narzędzia oparte na sztucznej inteligencji, aby zdobyć zaufanie użytkowników . Podszywali się pod założyciela firmy, kopiując jej identyfikację wizualną, zdjęcie, a nawet markę. Stworzyli prawdziwą przestrzeń na Slacku z logo firmy, kanałami z postami rzekomo zsynchronizowanymi z LinkedIn, a nawet fałszywymi profilami pracowników i innych osób odpowiedzialnych za rozwój oprogramowania open source.
W tym środowisku zaplanowali spotkanie za pośrednictwem Microsoft Teams, w którym najwyraźniej uczestniczyła cała grupa specjalistów . Podczas spotkania zasymulowali problem techniczny i wskazali, że jeden z komponentów ich systemu jest nieaktualny. Technik ds. konserwacji, uznając to za uzasadniony wymóg związany z samym narzędziem do wideokonferencji, pobrał i zainstalował sugerowany plik.
Plik ten był w rzeczywistości trojanem zdalnego dostępu, który umożliwił atakującym przechwycenie danych uwierzytelniających ofiary i ostatecznie przejęcie kontroli nad kontem npm używanym do publikacji Axios . Cały proces był tak dobrze zorganizowany i zawierał tak wiele wiarygodnych szczegółów, że ofiara opisała go jako „doskonale skoordynowany, profesjonalny i całkowicie przekonujący”.
Ten ludzki aspekt tego incydentu jasno pokazuje, że nawet środki techniczne, takie jak 2FA, są niewystarczające, gdy zaawansowana socjotechnika łączy się z podszywaniem się pod kogoś, deepfake'ami lub szczegółowym klonowaniem organizacji . Najsłabszym ogniwem, po raz kolejny, jest interakcja międzyludzka.
Wpływ na organizacje i programistów korzystających z Axios
Z praktycznego punktu widzenia głównym problemem jest ustalenie, kto faktycznie został zainfekowany. Każda organizacja, która zainstalowała [email protected] lub [email protected] w okresie, w którym były one dostępne, powinna założyć, że maszyna lub potok, który przeprowadził instalację, może być zainfekowany.
Zalecenia firm takich jak StepSecurity, Aikido, Huntress i Elastic są jednoznaczne. W przypadku podejrzeń konieczne jest proaktywne podejście, a nie tylko „usunięcie i ponowna instalacja node_modules ”. Rozsądnym rozwiązaniem jest odbudowa zainfekowanych maszyn lub środowisk z zaufanych obrazów i dokładne przejrzenie dzienników CI/CD w celu zidentyfikowania zadań lub potoków, które mogły wykonać zainfekowane wersje.
Co więcej, niezwykle ważne jest rotowanie wszystkich poświadczeń i sekretów, do których RAT mógł uzyskać dostęp z tych węzłów : tokenów npm, kluczy dostawców usług w chmurze, sekretów potoku, poświadczeń bazy danych, kluczy SSH itd. Pozostawienie tych poświadczeń w obiegu po takim ataku otwiera drzwi do cichego przemieszczania się.
Na poziomie technicznym zespoły powinny przejrzeć swoje pliki blokad (package-lock.json, pnpm-lock.yaml, yarn.lock) pod kątem odniesień do zainfekowanych wersji Axios i plain-crypto-js . Jeśli te elementy zostaną znalezione, kolejnym krokiem będzie sprawdzenie zainfekowanych systemów pod kątem potencjalnych artefaktów RAT: /Library/Caches/com.apple.act.mond w systemie macOS, %PROGRAMDATA%\wt.exe i %PROGRAMDATA%\system.bat w systemie Windows lub /tmp/ld.py w systemie Linux.
Równocześnie zaleca się jawne ustawienie bezpiecznych wersji Axios, takich jak 1.14.0 i 0.30.3, oraz stosowanie nadpisów lub rozwiązań, aby zapobiec przechodzeniu zależności przechodnich na niepożądane wersje . Blokowanie ruchu wychodzącego do domeny sfrclakcom jest również rozsądnym środkiem zapobiegawczym, przynajmniej na czas analizy pełnego zakresu ataku.
Lekcje bezpieczeństwa dla łańcucha dostaw oprogramowania
Incydent na Axios nie jest odosobnionym przypadkiem, ale kolejnym ogniwem w łańcuchu ataków na łańcuch dostaw, obejmującym przypadki takie jak SolarWinds, Kaseya, 3CX, Polyfill.io oraz luki w zabezpieczeniach wykorzystane w Log4j. Główna idea jest zawsze ta sama: skompromitować powszechnie używany, zaufany komponent, aby zmaksymalizować zasięg , zamiast próbować atakować maszynę po maszynie.
Jedną z najczęściej powtarzanych lekcji ekspertów jest to, że zaufanie nie może opierać się wyłącznie na popularności biblioteki lub reputacji osoby ją utrzymującej . Jeśli kanał wydania (konto npm, potok CI/CD, infrastruktura kompilacji) zostanie naruszony, wszystko, co zostanie za jego pośrednictwem wydane, dziedziczy to ryzyko. Ręczny przegląd kodu jest również niewystarczający, jeśli złośliwe oprogramowanie ukrywa się w zależnościach przechodnich i usuwa się po uruchomieniu.
Podkreślono również, że „domyślna prędkość” aktualizacji zależności wiąże się z kosztami w postaci powierzchni ataku . Automatyczne wdrażanie najnowszej wersji jest niezwykle wygodne, ale otwiera drogę do rozprzestrzeniania się złośliwej aktualizacji w ciągu kilku minut. Niektóre organizacje rozważają już wprowadzenie zasad, takich jak wymóg, aby nowa wersja była obecna w ekosystemie przez określony czas przed wdrożeniem, lub wymóg, aby zmiany w krytycznych pakietach podlegały dodatkowej, ręcznej weryfikacji.
W kontekście infrastruktury programistycznej, środowiska CI/CD należy traktować jako zasoby o wysokim stopniu wrażliwości . Każde RAT wykonywane podczas instalacji zależności niemal na pewno będzie poszukiwać sekretów potoku i dostępu do innych środowisk. Segmentacja tych węzłów, ich dokładniejsze monitorowanie i okresowa rotacja ich sekretów nie są już „idealnym” zaleceniem, lecz koniecznością.
Wreszcie, wykrywanie tego typu ataków wymaga połączenia informacji z wielu źródeł: zainstalowanych wersji, plików blokady, wskaźników zagrożenia w systemie operacyjnym oraz telemetrii sieciowej . Narzędzia generujące i zarządzające zestawieniami materiałowymi oprogramowania (SBOM) pomagają szybko śledzić, które projekty korzystają z których pakietów, co jest kluczowe w przypadku wystąpienia masowych alertów, takich jak ten.
Cały ten odcinek z Axios ilustruje, w jakim stopniu ekosystem zależności, niezależnie od tego, jak dojrzały i skonsolidowany może się wydawać, wciąż w dużej mierze opiera się na zaufaniu i nieustannej czujności. Pozornie niegroźna biblioteka, zarządzana przez jedną osobę, która padnie ofiarą dobrze przeprowadzonego ataku socjotechnicznego, może w ciągu kilku godzin stać się globalnym wektorem wdrażania wieloplatformowych ataków RAT skierowanych przeciwko firmom, freelancerom i organizacjom każdej wielkości . Wzmocnienie kontroli nad kontami publikacji, potokami i krytycznymi zależnościami nie jest już opcjonalną, najlepszą praktyką, lecz warunkiem wstępnym do dalszego rozwoju w środowisku, w którym atakujący są coraz bardziej cierpliwi, pomysłowi i wyposażeni w lepsze narzędzia.
