Wprowadzenie do problemu / definicja
Ekosystem npm od lat pozostaje jednym z kluczowych elementów łańcucha dostaw oprogramowania dla projektów JavaScript i Node.js. Ta popularność sprawia jednak, że publiczny rejestr pakietów staje się atrakcyjnym celem dla cyberprzestępców, którzy próbują ukrywać złośliwy kod w bibliotekach wyglądających na nieszkodliwe moduły pomocnicze.
Opisana kampania pokazuje, że zagrożenie nie ogranicza się wyłącznie do podatności w kodzie open source. W tym przypadku atakujący wykorzystali pakiety npm do dystrybucji zdalnego trojana dostępowego Overlord RAT oraz komponentów kradnących dane z systemów Windows, aktywowanych już na etapie instalacji zależności.
W skrócie
Badacze powiązali aktywność oznaczoną jako MALFEX z operatorem, który od sierpnia 2023 roku publikował pakiety zawierające złośliwe mechanizmy instalacyjne. Łącznie zidentyfikowano 12 pakietów, z czego osiem uznano za bezpośrednio złośliwe.
Według ujawnionych danych podejrzane biblioteki zostały pobrane 40 767 razy. Największy udział w tej liczbie miał pakiet function-flag, a część komponentów pozostawała aktywna jeszcze pod koniec września 2026 roku, co wskazuje na długi czas życia zagrożenia w publicznym rejestrze.
- Zidentyfikowano osiem złośliwych pakietów npm.
- Kampania wykorzystywała hooki instalacyjne, w tym postinstall.
- Payloady obejmowały Overlord RAT oraz stealer ukierunkowany na dane użytkowników.
- Zagrożone były stacje deweloperskie, serwery buildów oraz środowiska CI/CD.
Kontekst / historia
Ataki na łańcuch dostaw oprogramowania nie są nowym zjawiskiem, ale przypadek MALFEX wyróżnia się długotrwałą aktywnością oraz wielowarstwowym sposobem dystrybucji malware. Operator publikował pakiety pod różnymi nazwami, a część z nich wykorzystywała zależności pośrednie do uruchamiania kolejnych etapów infekcji.
Na liście analizowanych pakietów znalazły się między innymi tlxbnhd, tldriver, mxdriver, img-to-native, native-runner, function-flag, function-color oraz cdn-img-fetch. Taka architektura utrudnia wykrycie incydentu, ponieważ złośliwa funkcjonalność może zostać aktywowana nie tylko po bezpośredniej instalacji pakietu, ale również poprzez pobranie go jako zależności w większym projekcie.
Kampania wpisuje się w szerszy trend nadużywania zaufania do publicznych rejestrów paczek. Dla organizacji oznacza to konieczność traktowania bezpieczeństwa zależności jako stałego procesu, a nie jednorazowego skanowania projektu.
Analiza techniczna
Analiza techniczna wskazuje na co najmniej trzy odrębne ścieżki infekcji. Pierwsza z nich obejmowała pakiety pełniące funkcję loaderów dla Overlord RAT. Złośliwa logika była uruchamiana za pomocą hooków cyklu życia npm, które pobierały i wykonywały plik przeznaczony dla systemu Windows.
Drugi wariant opierał się na łańcuchu zależności, w którym pakiet img-to-native korzystał z cdn-img-fetch do pobrania i uruchomienia binariów napisanych w Go. Następnie aktywowany był stealer dla Node.js określany jako movinlike, którego zadaniem była kradzież danych z Discorda, przeglądarek, Telegrama oraz portfeli kryptowalutowych.
Trzecia ścieżka była związana z pakietem function-flag, zawierającym skrypt postinstall. W analizowanych wersjach wykonywany był kod JavaScript pobierający kolejny ładunek z infrastruktury zdalnej. Poszczególne wersje korzystały z różnych lokalizacji dostarczania payloadów, co sugeruje rotację infrastruktury i świadome utrudnianie detekcji.
Warto podkreślić, że function-color nie zawierał własnego payloadu, lecz deklarował function-flag jako zależność. Tego typu konstrukcja zwiększa zasięg kampanii i pozwala atakującym ukryć złośliwą aktywność głębiej w drzewie zależności.
Z perspektywy obronnej jest to klasyczny przykład nadużycia hooków takich jak preinstall, install i postinstall. Jeśli organizacja nie kontroluje, jakie skrypty są uruchamiane podczas instalacji pakietów, złośliwy kod może uzyskać dostęp do hosta jeszcze przed uruchomieniem aplikacji.
Konsekwencje / ryzyko
Skutki takiej kompromitacji mogą być bardzo poważne, zwłaszcza dla zespołów programistycznych i środowisk automatyzujących budowanie aplikacji. Overlord RAT daje atakującemu zdalny dostęp do zainfekowanej maszyny, co może prowadzić do dalszego ruchu bocznego w sieci, przejęcia repozytoriów, kradzieży sekretów oraz instalacji dodatkowych backdoorów.
Równolegle komponent stealer zwiększa ryzyko wycieku danych uwierzytelniających, tokenów sesyjnych i informacji biznesowych. Szczególnie groźne są sytuacje, w których runner CI/CD lub stacja deweloperska mają dostęp do kluczy API, kont chmurowych, prywatnych rejestrów i systemów wdrożeniowych.
Dodatkowym problemem jest długi czas obecności części pakietów w rejestrze. Oznacza to, że organizacje nieprowadzące ciągłego monitoringu zależności mogły przez wiele miesięcy korzystać z aktywnego malware, nie zdając sobie z tego sprawy.
Rekomendacje
W pierwszej kolejności organizacje powinny przeprowadzić audyt plików package.json, package-lock.json oraz innych lockfile’i wykorzystywanych w projektach. Należy sprawdzić, czy wskazane pakiety lub ich pośrednie zależności pojawiły się w środowiskach deweloperskich, buildowych albo CI/CD.
Kolejnym krokiem powinna być analiza logów pod kątem uruchamiania skryptów instalacyjnych. W praktyce warto ograniczyć możliwość wykonywania hooków postinstall, preinstall i install tam, gdzie nie są one niezbędne z punktu widzenia procesu wytwórczego.
- Skanować zależności pod kątem znanych IOC oraz nietypowych hooków instalacyjnych.
- Monitorować tworzenie i uruchamianie binariów w katalogach użytkownika.
- Analizować połączenia wychodzące inicjowane przez procesy node oraz nieznane pliki wykonywalne.
- Segmentować środowiska deweloperskie i ograniczać uprawnienia runnerów CI/CD.
- Przechowywać sekrety poza zasięgiem procesów instalacji zależności.
- Rotować tokeny, klucze i poświadczenia po wykryciu podejrzanego pakietu.
Jeżeli którykolwiek z pakietów został zainstalowany, system należy traktować jako potencjalnie skompromitowany. Sama deinstalacja biblioteki nie daje pewności usunięcia zagrożenia, ponieważ wcześniejsze etapy ataku mogły już pobrać dodatkowe komponenty i utrwalić obecność napastnika.
Podsumowanie
Kampania MALFEX potwierdza, że bezpieczeństwo łańcucha dostaw oprogramowania pozostaje jednym z najtrudniejszych wyzwań współczesnej cyberobrony. Atakujący wykorzystali zaufanie do publicznego rejestru npm, automatyczne skrypty instalacyjne oraz wieloetapowe zależności do dystrybucji Overlord RAT i narzędzi kradnących dane.
Dla zespołów bezpieczeństwa i deweloperów kluczowy wniosek jest jednoznaczny: kontrola zależności, monitoring hooków instalacyjnych oraz ochrona środowisk buildowych powinny być traktowane jako podstawowy element higieny bezpieczeństwa. Zaniedbania w tym obszarze mogą prowadzić nie tylko do infekcji pojedynczej stacji, ale również do kompromitacji całego procesu wytwarzania oprogramowania.
Źródła
- The Hacker News — https://thehackernews.com/2026/10/eight-malicious-npm-packages-downloaded.html
- CloudSEK — MALFEX – A malicious npm postinstall no advisory has caught for fourteen months — https://www.cloudsek.com/blog/malfex-malicious-npm-postinstall-supply-chain-campaign?78dcd286_page=2
- Checkmarx — MALFEX npm Malware Campaign: Three Payloads And An Adversary That Signs Their Work — https://checkmarx.com/zero-post/malfex-npm-malware-campaign-three-payloads-and-an-adversary-that-signs-their-work/