Kampania MALFEX w npm: złośliwe pakiety z Overlord RAT i stealerem pobrano ponad 40 tys. razy

Wprowadzenie do problemu / definicja

Ekosystem npm od lat pozostaje jednym z kluczowych elementów nowoczesnego procesu tworzenia aplikacji w JavaScript i Node.js, ale jednocześnie stanowi atrakcyjny cel dla ataków na łańcuch dostaw oprogramowania. Najnowszy przypadek związany z kampanią MALFEX pokazuje, jak pozornie niegroźne pakiety mogą zostać wykorzystane do uruchomienia złośliwego kodu już na etapie instalacji zależności.

W opisywanej kampanii napastnicy użyli złośliwych paczek npm do dostarczania trojana zdalnego dostępu Overlord RAT, stealera informacji movinlike oraz dodatkowych komponentów pobieranych dynamicznie z infrastruktury atakującego. Szczególnie niebezpieczne jest to, że mechanizm infekcji opierał się na standardowych funkcjach npm, co utrudniało wykrycie zagrożenia.

W skrócie

Kampania MALFEX była aktywna co najmniej od sierpnia 2023 roku.
Łącznie powiązano z nią 12 pakietów, z czego osiem uznano za złośliwe.
Analizowane paczki zostały pobrane ponad 40 767 razy.
Głównym celem były systemy Windows oraz środowiska developerskie i buildowe.
Wśród dostarczanych ładunków znalazły się Overlord RAT, stealer movinlike oraz downloadery kolejnych komponentów.

Kontekst / historia

Ataki supply chain w publicznych rejestrach pakietów stają się coraz częstszym narzędziem cyberprzestępców. Zamiast atakować bezpośrednio użytkowników końcowych, napastnicy publikują biblioteki udające pomocnicze moduły techniczne. Gdy deweloper lub system CI/CD instaluje takie zależności, złośliwy kod może uruchomić się automatycznie.

Kampania MALFEX wyróżnia się długim okresem aktywności, zmianami w infrastrukturze dostarczania ładunków oraz użyciem kilku równoległych ścieżek infekcji. Wśród identyfikowanych nazw znalazły się między innymi tlxbnhd, tldriver, mxdriver, img-to-native, native-runner, function-flag, function-color oraz cdn-img-fetch. Największą skalę pobrań odnotowano dla pakietu function-flag, który odpowiadał za większość zasięgu operacji.

Analiza techniczna

Technicznie kampania była zbudowana wokół nadużycia skryptów cyklu życia pakietów npm, w tym mechanizmów uruchamianych podczas instalacji. To właśnie one pozwalały na automatyczne pobieranie i wykonanie dodatkowych plików bez potrzeby dalszej interakcji użytkownika.

Pierwszy scenariusz dotyczył pakietów pełniących funkcję loaderów dla Overlord RAT. Po instalacji uruchamiany był kod odpowiedzialny za pobranie pliku wykonywalnego dla systemu Windows. Overlord RAT, napisany w Go, umożliwia przejęcie zdalnej kontroli nad hostem, wykonywanie poleceń i rozwijanie dalszej aktywności po kompromitacji.

Druga ścieżka infekcji była związana z pakietami img-to-native oraz cdn-img-fetch. W tym modelu pobierany był komponent napisany w Go, który następnie dostarczał stealera movinlike. Oprogramowanie to zostało zaprojektowane do kradzieży danych z przeglądarek, Discorda, Telegrama oraz portfeli kryptowalutowych, co wskazuje na szeroki zakres potencjalnych strat po stronie ofiary.

Trzecia ścieżka obejmowała pakiet function-flag, zawierający skrypt postinstall uruchamiający kod JavaScript odpowiedzialny za pobranie dalszego ładunku z serwera zdalnego. Istotną cechą tego podejścia była zmienność payloadów i infrastruktury pomiędzy wersjami pakietu. Oznacza to, że pojedyncza analiza nie musiała oddawać pełnego obrazu zagrożenia. Pakiet function-color działał jako pośrednik poprzez zależność od function-flag, zwiększając zasięg kampanii także przez zależności tranzytywne.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii MALFEX jest ryzyko kompromitacji stacji deweloperskich i środowisk budujących aplikacje. Jeśli złośliwy pakiet trafi na host z dostępem do repozytoriów kodu, sekretów CI/CD, tokenów npm, kluczy API lub poświadczeń chmurowych, atak może szybko wyjść poza pojedynczy system.

Overlord RAT daje napastnikowi trwały dostęp do hosta, co umożliwia dalszy rekonesans, ruch boczny i instalowanie kolejnych narzędzi. Z kolei stealer movinlike zwiększa prawdopodobieństwo wycieku danych uwierzytelniających, sesji aplikacyjnych, informacji z komunikatorów oraz zasobów finansowych powiązanych z portfelami kryptowalutowymi.

Dodatkowym problemem jest rotacja payloadów i zmienność infrastruktury, która utrudnia klasyczną detekcję opartą wyłącznie na wskaźnikach IOC. W praktyce oznacza to, że organizacje powinny patrzeć nie tylko na same nazwy pakietów, lecz także na ich zachowanie, wersje oraz kontekst użycia w procesie budowania.

Rekomendacje

Organizacje korzystające z npm powinny potraktować incydent MALFEX jako wyraźny sygnał do zaostrzenia kontroli nad zależnościami i bezpieczeństwem pipeline’ów developerskich. Ochrona przed podobnymi kampaniami wymaga połączenia działań technicznych, procesowych i organizacyjnych.

Przeprowadzić pełny przegląd plików package.json, package-lock.json, npm-shrinkwrap.json oraz innych lockfile pod kątem wskazanych pakietów i zależności tranzytywnych.
Ograniczyć lub monitorować wykonywanie skryptów preinstall, install i postinstall, szczególnie w środowiskach CI/CD.
Wdrożyć analizę bezpieczeństwa łańcucha dostaw obejmującą reputację pakietów, analizę behawioralną oraz detekcję anomalii w nowych zależnościach.
Sprawdzić systemy Windows pod kątem nietypowych procesów, plików wykonywalnych w katalogach użytkownika oraz podejrzanych połączeń wychodzących inicjowanych przez node.exe lub nieznane binaria Go.
Zresetować potencjalnie zagrożone sekrety, w tym tokeny npm, poświadczenia chmurowe, klucze API, dane dostępowe do repozytoriów i zapisane sesje.
Wzmocnić politykę zaufania do open source przez pinning wersji, wewnętrzne mirrory rejestrów, listy dozwolonych pakietów i obowiązkowy review zmian w zależnościach.

Podsumowanie

Kampania MALFEX pokazuje, że złośliwe pakiety npm pozostają skutecznym narzędziem ataków na łańcuch dostaw oprogramowania. Wykorzystanie hooków instalacyjnych, zależności pośrednich i rotujących payloadów pozwoliło napastnikom zbudować elastyczny mechanizm dostarczania zarówno trojana zdalnego dostępu, jak i stealera danych.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: ochrona procesu budowania aplikacji, kontrola zależności i monitoring zachowania pakietów powinny być traktowane jako element krytyczny, a nie jedynie dodatkowa warstwa obrony. To właśnie na styku wygody deweloperskiej i automatyzacji najłatwiej dziś ukryć skuteczny wektor kompromitacji.