Wprowadzenie do problemu / definicja
Bezpieczeństwo łańcucha dostaw oprogramowania pozostaje jednym z kluczowych wyzwań dla organizacji korzystających z otwartych rejestrów pakietów. Najnowsza kampania wymierzona w ekosystem npm pokazuje, że cyberprzestępcy nadal skutecznie wykorzystują zaufanie do bibliotek JavaScript, publikując setki pozornie nieszkodliwych modułów, które po uruchomieniu instalują złośliwe oprogramowanie na systemach Windows, macOS i Linux.
W opisywanym przypadku celem atakujących było nie tylko dostarczenie pojedynczego ładunku, lecz zbudowanie elastycznego, wieloplatformowego łańcucha infekcji. Taka strategia zwiększa skuteczność kampanii i pozwala dopasować malware do środowiska ofiary.
W skrócie
Badacze ujawnili kampanię obejmującą blisko 800 złośliwych pakietów opublikowanych w rejestrze npm. Pakiety wykorzystywały nazwy przypominające literówki lub losowo generowane ciągi, a ich działanie opierało się na nakłanianiu ofiary do załadowania modułu przez funkcję require(), zamiast klasycznych skryptów instalacyjnych.
- kampania objęła setki pakietów npm,
- złośliwy kod działał na Windows, macOS i Linux,
- infekcja uruchamiała downloader pobierający właściwy ładunek,
- końcowy malware pełnił funkcję RAT-a oraz stealera danych,
- w łańcuchu dostarczania wykorzystano także rekordy DNS TXT jako mechanizm zapasowy.
Kontekst / historia
Ataki na npm nie są nowym zjawiskiem, jednak ta operacja wyróżnia się skalą i sposobem ukrywania złośliwej logiki. W wielu wcześniejszych incydentach dominowały techniki wykorzystujące skrypty preinstall lub postinstall, uruchamiane automatycznie podczas instalacji zależności. Tym razem napastnicy przyjęli inną metodę, umieszczając w pakietach instrukcje sugerujące ich bezpośrednie importowanie do projektu.
Taka zmiana taktyki ma istotne znaczenie operacyjne. Mechanizmy detekcyjne skoncentrowane wyłącznie na hookach instalacyjnych mogą nie wychwycić zagrożenia, jeśli złośliwa logika aktywuje się dopiero po użyciu modułu przez programistę lub proces budowania aplikacji.
Kampania wpisuje się również w szerszy trend automatyzacji ataków na łańcuch dostaw. Coraz częściej obserwuje się publikowanie dużych serii pakietów, które służą do profilowania środowiska, pobierania kolejnych etapów malware i maskowania rzeczywistej funkcji kodu wewnątrz legalnie wyglądających komponentów.
Analiza techniczna
Złośliwe pakiety zawierały downloader identyfikowany jako WEL1DROPPER. Po uruchomieniu kod rozpoznawał system operacyjny i architekturę procesora, a następnie próbował pobrać odpowiedni ładunek z infrastruktury zdalnej. W kampanii wykorzystywano między innymi hosty oparte na Cloudflare Workers jako warstwę dostarczania malware.
Jeżeli pobranie przez HTTPS kończyło się niepowodzeniem, malware przechodził do mechanizmu awaryjnego wykorzystującego rekordy DNS TXT. W praktyce oznaczało to pobieranie fragmentów ładunku w odpowiedziach DNS, ich łączenie po stronie ofiary oraz dekodowanie z Base64 do postaci binarnej. Taka technika utrudnia detekcję sieciową, ponieważ część komunikacji zostaje przeniesiona do kanału często monitorowanego mniej restrykcyjnie niż standardowy ruch HTTP lub HTTPS.
Po złożeniu końcowego ładunku malware zapisywał plik w katalogu tymczasowym i uruchamiał go lokalnie. Na Linux i macOS wykorzystywana była powłoka /bin/sh, a w środowisku Windows używano cmd.exe. Dalsze zachowanie zależało od platformy.
Wariant dla Windows zawierał mechanizmy utrudniające analizę i wykrycie, w tym działania związane z ETW i AMSI, kontrole środowisk sandbox i maszyn wirtualnych oraz ustanawianie trwałości przez klucze Run w rejestrze i zadania harmonogramu. Następnie pobierany był zaszyfrowany payload uruchamiany jako odłączony proces.
Łańcuch infekcji dla macOS realizował zbliżone cele: identyfikację artefaktów analitycznych, pobranie zgodnego ładunku, wykorzystanie DNS TXT jako ścieżki awaryjnej i utrzymanie obecności z użyciem LaunchAgent. Pokazuje to, że operatorzy przygotowali dojrzałe ścieżki działania dla wielu platform jednocześnie.
Wersja dla Linux została opisana jako binarium ELF spakowane UPX i skonfigurowane do pobierania dodatkowych komponentów. Jednym z możliwych efektów końcowych infekcji było wdrożenie frameworka Sliver, czyli otwartoźródłowego narzędzia C2 używanego do post-exploitation, zdalnego sterowania i rozwijania obecności w środowisku ofiary.
Istotnym elementem maskowania był także plik lib/telemetry.js, który sprawiał wrażenie legalnego modułu telemetrycznego, choć zawierał tę samą logikę downloadera. Tego rodzaju kamuflaż utrudnia szybki przegląd pakietu i może sugerować, że obserwowane połączenia sieciowe lub operacje systemowe wynikają z funkcji analitycznych, a nie z aktywności malware.
Konsekwencje / ryzyko
Ryzyko związane z taką kampanią jest wysokie, szczególnie dla zespołów deweloperskich, środowisk CI/CD i stacji roboczych programistów. Samo uruchomienie zainfekowanego pakietu może doprowadzić do pobrania kolejnych etapów malware oraz przejęcia hosta przez operatora ataku.
W praktyce oznacza to możliwość kradzieży sekretów środowiskowych, tokenów dostępowych, kluczy API, danych zapisanych w przeglądarce, a nawet wykorzystania zainfekowanej maszyny jako punktu wejścia do infrastruktury organizacji. Wieloplatformowy charakter kampanii dodatkowo zwiększa jej skuteczność, ponieważ te same pakiety mogą zagrozić użytkownikom Windows, macOS i Linux.
Dodatkowym problemem jest to, że malware nie ogranicza się do prostego wycieku danych. Obecność funkcji RAT i integracja z frameworkiem C2 otwierają drogę do dalszych działań po kompromitacji, takich jak uruchamianie poleceń, pobieranie nowych modułów, utrzymywanie trwałości czy poruszanie się lateralne po środowisku. Z perspektywy obrony jest to już pełnoprawny wektor wejścia do przedsiębiorstwa.
Rekomendacje
Organizacje korzystające z npm powinny wdrożyć wielowarstwowe kontrole bezpieczeństwa dla zależności open source i nie polegać wyłącznie na reputacji publicznego rejestru. Skuteczna ochrona wymaga zarówno prewencji, jak i monitorowania aktywności już po uruchomieniu pakietu.
- wymuszać korzystanie z zatwierdzonych mirrorów lub prywatnych proxy dla npm,
- automatycznie skanować zależności pod kątem malware, typosquattingu i anomalii w nazewnictwie,
- blokować lub dodatkowo weryfikować nowe i mało popularne pakiety przed dopuszczeniem ich do użycia,
- prowadzić analizę behawioralną bibliotek uruchamianych w środowiskach developerskich i buildowych,
- monitorować zapytania DNS TXT, nietypowe połączenia sieciowe i pobieranie plików wykonywalnych przez procesy powiązane z Node.js,
- izolować stacje robocze deweloperów oraz środowiska CI/CD od krytycznych zasobów,
- ograniczać dostęp do sekretów i rotować poświadczenia w razie podejrzenia kompromitacji,
- stosować listy dozwolonych zależności, pinowanie wersji i formalny przegląd nowych bibliotek.
Z perspektywy SOC i zespołów reagowania na incydenty warto przygotować reguły detekcyjne obejmujące uruchamianie powłoki przez procesy Node.js, tworzenie mechanizmów trwałości na stacjach deweloperskich, modyfikacje ETW i AMSI w Windows oraz nietypową aktywność LaunchAgent w macOS. Wskazane jest także przeanalizowanie historii instalowanych pakietów npm pod kątem nazw związanych z kampanią.
Podsumowanie
Kampania obejmująca niemal 800 złośliwych pakietów npm pokazuje, że ataki na łańcuch dostaw oprogramowania stają się coraz bardziej skalowalne, wieloplatformowe i trudniejsze do wykrycia. Wykorzystanie ładowania przez require(), mechanizmu DNS TXT do dostarczania kolejnych etapów oraz maskowania logiki w pozornie legalnych modułach to sygnał, że tradycyjne kontrole bezpieczeństwa nie są już wystarczające.
Dla organizacji oznacza to konieczność połączenia kontroli repozytoriów, monitoringu behawioralnego, segmentacji środowisk oraz ścisłego zarządzania zaufaniem do zależności zewnętrznych. W przeciwnym razie pojedyncza biblioteka może stać się początkiem pełnej kompromitacji środowiska developerskiego i firmowej infrastruktury.
Źródła
- Nearly 800 Malicious npm Packages Deliver Cross-Platform RAT and Infostealer — https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
- OpenSourceMalware research references cited in incident coverage — https://opensourcemalware.com/
- Sonatype analysis of malicious open source packages — https://www.sonatype.com/
- Sliver C2 Framework — https://github.com/BishopFox/sliver
- Unit 42 threat research on malicious npm and PyPI packages — https://unit42.paloaltonetworks.com/