Prawie 800 złośliwych pakietów npm rozprowadzało wieloplatformowego RAT-a i infostealera

Wprowadzenie do problemu

Ekosystem npm odgrywa kluczową rolę w nowoczesnym rozwoju aplikacji JavaScript, ale jednocześnie pozostaje jednym z najczęściej nadużywanych elementów łańcucha dostaw oprogramowania. Najnowsza kampania pokazuje, że cyberprzestępcy coraz skuteczniej wykorzystują zaufanie programistów do publicznych rejestrów pakietów, publikując złośliwe moduły podszywające się pod legalne zależności.

W opisanym przypadku chodzi o niemal 800 pakietów npm, których zadaniem było dostarczenie wieloplatformowego malware. Złośliwe komponenty działały jako downloader, a następnie wdrażały odpowiedni ładunek dla systemów Windows, macOS i Linux, umożliwiając zdalną kontrolę hosta oraz kradzież danych.

W skrócie

W npm wykryto blisko 800 złośliwych pakietów powiązanych z jedną kampanią.
Pakiety uruchamiały złośliwy kod po załadowaniu przez funkcję require(), a nie wyłącznie przez klasyczne skrypty instalacyjne.
Downloader identyfikował system operacyjny i architekturę procesora, a następnie pobierał odpowiedni payload.
Do dostarczania drugiego etapu wykorzystywano zarówno infrastrukturę webową, jak i rekordy DNS TXT.
Kampania obejmowała mechanizmy persistence, unikania analizy oraz funkcje RAT i infostealera.

Kontekst i historia

Ataki na publiczne repozytoria open source nie są nowym zjawiskiem, jednak ich skala i poziom automatyzacji wyraźnie rosną. W ostatnich miesiącach badacze wielokrotnie informowali o złośliwych paczkach publikowanych w npm i PyPI, które służyły do kradzieży sekretów środowiskowych, tokenów CI/CD, danych chmurowych czy poświadczeń użytkowników.

Obecna operacja wpisuje się w ten trend, ale wyróżnia się rozmiarem oraz techniką działania. Zamiast ograniczać się do prostych skryptów wykonywanych podczas instalacji, operatorzy kampanii przygotowali bardziej rozbudowany łańcuch infekcji, z profilowaniem środowiska, alternatywnym kanałem dostarczania payloadu i mechanizmami utrudniającymi wykrycie.

Analiza techniczna

Najważniejszą cechą kampanii było odejście od klasycznych hooków instalacyjnych, takich jak preinstall czy postinstall. Zamiast tego złośliwe pakiety były projektowane tak, aby uruchamiać malware po załadowaniu modułu przez require(). To podejście mogło zmniejszać szansę na szybką detekcję, ponieważ wiele narzędzi i procedur bezpieczeństwa koncentruje się przede wszystkim na analizie skryptów instalacyjnych.

Po wykonaniu kodu uruchamiany był downloader określany jako WEL1DROPPER. Jego zadaniem było rozpoznanie systemu operacyjnego i architektury CPU ofiary, pobranie odpowiedniego ładunku oraz uruchomienie go przy użyciu natywnych mechanizmów systemowych. Jeśli podstawowa ścieżka pobrania zawodziła, malware przełączało się na alternatywny kanał dostarczania.

Istotnym elementem kampanii było wykorzystanie rekordów DNS TXT jako kanału awaryjnego. Złośliwy kod odpytywał rekordy TXT, pobierał fragmenty payloadu, scalał je, dekodował i odtwarzał końcowy plik binarny. Tego typu technika utrudnia blokowanie ruchu oraz pozwala omijać część zabezpieczeń sieciowych skoncentrowanych głównie na protokołach HTTP i HTTPS.

Na Windows malware wykorzystywało dodatkowe techniki antyanalityczne, w tym próby ingerencji w mechanizmy monitorowania oraz ochrony skryptów. Obserwowano także sprawdzanie obecności środowisk wirtualnych i sandboxów, konfigurację persistence przez klucze Run w rejestrze oraz zadania harmonogramu. W wariancie macOS trwałość uzyskiwano przy użyciu LaunchAgent, natomiast na Linuksie analizowany łańcuch infekcji prowadził do wdrożenia komponentów powiązanych z frameworkiem Sliver.

Dodatkowym elementem maskowania był plik telemetryczny obecny w części pakietów. Z pozoru wyglądał jak zwykły moduł analityczny, ale w rzeczywistości zawierał tę samą logikę downloadera. Taka technika miała utrudnić pobieżną analizę kodu i zwiększyć szansę, że złośliwa funkcjonalność pozostanie niezauważona.

Konsekwencje i ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ obejmuje zarówno stacje robocze programistów, jak i środowiska automatycznego budowania aplikacji. Wieloplatformowy charakter malware oznacza, że atakujący nie ograniczali się do jednego systemu operacyjnego, lecz celowali w szeroki przekrój środowisk wykorzystywanych w procesie wytwarzania oprogramowania.

kradzież poświadczeń i sekretów środowiskowych,
przejęcie tokenów dostępowych i sesji deweloperskich,
uzyskanie zdalnego dostępu do hosta,
utrzymanie trwałości w systemie,
ruch lateralny do innych zasobów organizacji,
kompromitacja pipeline’u CI/CD i infrastruktury build.

Szczególnie niebezpieczny jest scenariusz, w którym złośliwy pakiet zostaje użyty podczas kompilacji, testów lub publikacji artefaktów. W takim przypadku atak może doprowadzić do wycieku kluczy API, danych dostępowych do rejestrów, sekretów chmurowych, a nawet materiału wykorzystywanego do podpisywania oprogramowania.

Rekomendacje

Organizacje korzystające z npm powinny wzmacniać ochronę łańcucha dostaw oprogramowania i traktować nowe zależności jako potencjalny wektor ataku. W praktyce warto wdrożyć zestaw działań ograniczających zarówno ryzyko pobrania złośliwego pakietu, jak i skutki ewentualnej kompromitacji.

ograniczyć użycie niezweryfikowanych pakietów z publicznych rejestrów,
stosować listy dozwolonych zależności oraz lockfile,
wprowadzić proces zatwierdzania nowych bibliotek przed użyciem,
analizować pakiety pod kątem podejrzanych zachowań, a nie tylko znanych podatności,
monitorować wywołania powłoki, dynamiczne pobieranie kodu i nietypowy ruch DNS,
ograniczyć uprawnienia środowisk developerskich i build serwerów,
rotować sekrety i udostępniać je tylko wtedy, gdy są niezbędne,
segmentować środowiska CI/CD i izolować je od wrażliwych zasobów,
prowadzić regularne threat hunting w oparciu o IOC, TTP i artefakty persistence,
szkolić zespoły programistyczne w zakresie bezpiecznego doboru zależności.

Podsumowanie

Kampania obejmująca prawie 800 złośliwych pakietów npm potwierdza, że ataki na łańcuch dostaw open source stają się coraz bardziej dojrzałe, wieloetapowe i trudniejsze do wykrycia. Wykorzystanie require() zamiast klasycznych hooków instalacyjnych, fallbacku przez DNS TXT oraz mechanizmów persistence pokazuje, że atakujący dobrze rozumieją zarówno zachowania programistów, jak i ograniczenia obecnych narzędzi ochronnych.

Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia monitoringu poza znane CVE i proste wskaźniki kompromitacji. Skuteczna obrona musi obejmować cały cykl życia zależności, od weryfikacji pakietu po analizę telemetrii endpointów, ruchu sieciowego i zachowań procesów uruchamianych w środowiskach developerskich.