Wprowadzenie do problemu / definicja
Ekosystem npm odgrywa kluczową rolę w procesie budowy aplikacji JavaScript i Node.js, dlatego pozostaje jednym z najważniejszych elementów współczesnego łańcucha dostaw oprogramowania. Jednocześnie jego otwarty charakter sprawia, że stanowi atrakcyjny cel dla operatorów kampanii malware, którzy mogą ukrywać złośliwy kod w pozornie zwykłych bibliotekach.
Kampania MALFEX pokazuje, że zagrożenia w npm nie muszą mieć charakteru krótkotrwałego. W tym przypadku złośliwe pakiety były utrzymywane przez długi czas, zdobywały zaufanie liczbą pobrań i wykorzystywały różne techniki uruchamiania kodu, aby utrudnić wykrycie oraz analizę.
W skrócie
Według ustaleń badaczy kampania MALFEX trwa od sierpnia 2023 roku i obejmuje 12 pakietów powiązanych z jednym operatorem. Osiem z nich miało charakter złośliwy, a łączna liczba pobrań przekroczyła 40 tys.
Szczególną rolę odegrał pakiet function-flag, który od lipca 2025 roku miał zawierać złośliwy kod i odpowiadać za większość instalacji. Na początku października 2026 roku część pakietów nadal pozostawała możliwa do pobrania, co dodatkowo podkreśla skalę problemu.
- Kampania wykorzystywała trzy odrębne ścieżki infekcji.
- Payloady obejmowały loader dla Overlord RAT, stealera informacji oraz downloader.
- Największe ryzyko dotyczyło hostów z systemem Windows.
Kontekst / historia
Ataki na łańcuch dostaw w repozytoriach open source nie są nowym zjawiskiem, jednak MALFEX wyróżnia się czasem trwania i konsekwentnym rozwojem infrastruktury. Zamiast pojedynczego incydentu badacze opisali wieloetapową operację prowadzoną przez długi okres, z wykorzystaniem kolejnych publikacji i modyfikacji pakietów.
Istotnym problemem okazała się również niepełna widoczność zagrożenia. Część ostrzeżeń i wpisów w bazach podatności obejmowała jedynie wybrane wersje bibliotek, podczas gdy operator zmieniał warianty pakietów, wersjonowanie i lokalizacje pobierania ładunków. W praktyce oznacza to, że samo monitorowanie advisory nie zawsze daje pełny obraz ryzyka.
Analiza techniczna
Pierwsza ścieżka infekcji opierała się na skryptach wykonywanych w trakcie instalacji npm. Wśród nich znajdowały się zaciemnione komponenty pełniące rolę loadera dla Overlord RAT. Mechanizm mógł zostać uruchomiony na różnych systemach operacyjnych, jednak końcowy ładunek był skuteczny przede wszystkim w środowiskach Windows.
Overlord RAT zapewniał operatorowi szerokie możliwości zdalnej kontroli, w tym monitorowanie aktywności użytkownika, przechwytywanie ekranu, keylogging, zdalną powłokę oraz dostęp do plików. Tego typu funkcjonalność wskazuje, że celem nie była wyłącznie jednorazowa kradzież danych, ale także dalsza eksploatacja zainfekowanego systemu.
Druga ścieżka była bardziej podstępna, ponieważ złośliwy kod aktywował się nie tylko podczas instalacji, ale także przy załadowaniu pakietu przez aplikację. Taki model utrudnia obronę opartą wyłącznie na blokowaniu skryptów preinstall i postinstall. W tym wariancie dostarczany był stealer movinlike, napisany dla Node.js i ukierunkowany na kradzież danych z klientów Discorda, przeglądarek oraz portfeli kryptowalutowych.
Trzecia ścieżka dotyczyła pakietu function-flag i była najdłużej utrzymywaną częścią kampanii. Każda złośliwa wersja zawierała osobny downloader pobierający payload z innej lokalizacji. Co istotne, procedura instalacji była zaprojektowana tak, aby zakończyć się powodzeniem nawet wtedy, gdy pobranie właściwego ładunku nie doszło do skutku, co zmniejszało szansę wzbudzenia podejrzeń po stronie dewelopera lub pipeline’u CI/CD.
W praktyce kampania łączyła kilka metod wykonania kodu: złośliwe skrypty instalacyjne, aktywację przy imporcie modułu oraz zmienne źródła pobierania ładunków. Takie podejście znacząco utrudnia tworzenie prostych reguł detekcji i sprzyja długiemu utrzymaniu operacji poniżej progu alarmowego.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko wynika z tego, że npm jest centralnym elementem procesu budowy nowoczesnych aplikacji. Zainfekowany pakiet może zostać zainstalowany nie tylko na stacji roboczej programisty, lecz także na serwerze buildowym, w środowisku testowym lub w pipeline CI/CD.
Skutki potencjalnej kompromitacji obejmują wyciek danych uwierzytelniających, kradzież tokenów dostępowych, przejęcie sesji użytkownika, eksfiltrację sekretów i możliwość dalszego ruchu bocznego w środowisku organizacji. W przypadku hostów Windows ryzyko jest szczególnie wysokie, ponieważ to właśnie ten system był głównym celem analizowanych payloadów.
Warto podkreślić, że ekspozycja nie musiała wynikać z popularnych zależności pośrednich. Według analizy największe zagrożenie dotyczyło środowisk, które instalowały konkretne nazwy pakietów bezpośrednio. To ogranicza szerokość zasięgu, ale jednocześnie zwiększa znaczenie błędów operacyjnych, testów proof-of-concept i pobierania mało znanych bibliotek bez rygorystycznej weryfikacji.
Rekomendacje
Organizacje korzystające z Node.js powinny traktować ryzyko supply chain w npm jako stały element modelu zagrożeń. Pierwszym krokiem powinno być zablokowanie wskazanych pakietów na poziomie prywatnych rejestrów, proxy oraz polityk zarządzania zależnościami.
Następnie warto przeprowadzić przegląd historii instalacji na stacjach deweloperskich i w pipeline’ach CI/CD. Analizie powinny podlegać pliki lockfile, cache menedżera pakietów, logi buildów oraz artefakty tymczasowe. Każdy host Windows, na którym zainstalowano podejrzany pakiet, należy potraktować jako potencjalnie skompromitowany.
- Ograniczyć lub wyłączyć wykonywanie skryptów instalacyjnych tam, gdzie jest to możliwe.
- Wdrożyć listy dozwolonych zależności i formalny proces ich akceptacji.
- Korzystać z prywatnych rejestrów lub mirrorów z dodatkowymi kontrolami reputacji.
- Monitorować uruchomienia procesów
node,npm,powershellicmdinicjowanych przez narzędzia buildowe. - Skanować pakiety również pod kątem zachowań wykonywanych przy imporcie modułu.
- Regularnie rotować tokeny deweloperskie, sekrety CI/CD i poświadczenia do repozytoriów.
Z perspektywy detekcji ważne jest także rozszerzenie telemetryki EDR/XDR o aktywność narzędzi deweloperskich. Jeżeli procesy związane z npm lub Node.js nawiązują nietypowe połączenia sieciowe, pobierają pliki wykonywalne albo uzyskują dostęp do danych przeglądarek i portfeli, taki incydent powinien zostać potraktowany priorytetowo.
Podsumowanie
Kampania MALFEX potwierdza, że ataki na łańcuch dostaw w ekosystemie npm stają się coraz bardziej dojrzałe, długotrwałe i wielowarstwowe. Dla zespołów bezpieczeństwa to wyraźny sygnał, że samo skanowanie zależności nie wystarcza, jeśli nie towarzyszy mu ścisłe zarządzanie zaufaniem do pakietów, monitoring zachowań wykonawczych oraz szybka reakcja na nawet niszowe biblioteki.
W praktyce skuteczna ochrona środowisk Node.js wymaga połączenia polityk prewencyjnych, analizy behawioralnej i regularnej weryfikacji źródeł oprogramowania. Tylko takie podejście pozwala ograniczyć ryzyko, że pozornie niegroźna biblioteka stanie się punktem wejścia do poważnej kompromitacji.
Źródła
- https://www.securityweek.com/long-running-npm-malware-campaign-accumulates-40000-downloads/
- https://checkmarx.com/zero-post/malfex-npm-malware-campaign-three-payloads-and-an-adversary-that-signs-their-work/