Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla środowisk deweloperskich. W opisywanym incydencie wykryto 18 złośliwych pakietów npm, które podszywały się pod komponenty powiązane z ekosystemem Alibaba i służyły do dostarczenia wieloplatformowego trojana zdalnego dostępu, czyli RAT-a.
Tego rodzaju kampanie są szczególnie niebezpieczne, ponieważ wykorzystują zaufanie do menedżerów pakietów, automatyzacji CI/CD oraz procesów aktualizacji zależności. W praktyce pojedyncza instalacja pozornie niegroźnego pakietu może otworzyć napastnikom drogę do stacji roboczej programisty, a następnie do zasobów całej organizacji.
W skrócie
Badacze zidentyfikowali 18 pakietów npm powiązanych z kampanią wymierzoną w użytkowników narzędzi Alibaba. Część z nich pełniła rolę przynęty, imitując prywatne komponenty o nazwach zbliżonych do rzeczywistych pakietów używanych wewnętrznie.
Łańcuch infekcji był wieloetapowy i prowadził do pobrania końcowego ładunku działającego na systemach Windows, Linux i macOS. Malware zapewniał zdalne wykonywanie poleceń, transfer plików, rekonesans hosta, utrzymanie dostępu oraz możliwość dalszego rozprzestrzeniania się w środowisku firmowym.
- 18 złośliwych pakietów opublikowanych w npm,
- podszywanie się pod pakiety powiązane z Alibaba,
- wielopoziomowy łańcuch zależności utrudniający analizę,
- końcowy payload w postaci wieloplatformowego RAT-a,
- wysokie ryzyko kompromitacji środowisk deweloperskich i sekretów organizacji.
Kontekst / historia
Incydent wpisuje się w rosnący trend nadużyć repozytoriów open source, gdzie napastnicy wykorzystują popularność ekosystemów JavaScript i automatyczne pobieranie zależności. Szczególnie skuteczne okazują się kampanie, które naśladują prywatne pakiety przedsiębiorstw, ponieważ takie nazwy nie zawsze budzą podejrzenia w zespołach technicznych.
W tym przypadku jeden z pakietów początkowo nie zawierał szkodliwej funkcjonalności, a dopiero późniejsze wersje wprowadziły loader pobierający zdalny kod JavaScript. Taki model działania sugeruje próbę zbudowania wiarygodności przed uruchomieniem właściwego etapu ataku.
Dodatkowo złośliwa logika nie była skupiona w jednym komponencie. Została rozproszona pomiędzy pakietami wyższej i niższej warstwy, dzięki czemu analiza statyczna stawała się trudniejsza, a sam incydent mógł przez dłuższy czas pozostać niezauważony.
Analiza techniczna
Mechanizm ataku został podzielony na kilka etapów. Pakiety najwyższego poziomu działały jako wabiki i imitowały prywatne moduły. Kolejne zależności pełniły rolę pomostu do właściwych komponentów odpowiedzialnych za pobieranie i uruchamianie złośliwego kodu.
Na jednym z etapów infekcji pakiet łączył się z repozytorium kodu, aby pobrać konfigurację silnika reguł. Następnie konfiguracja była wykorzystywana do uruchomienia kolejnego etapu, który pobierał wtórny ładunek z domeny przypominającej infrastrukturę Alibaba. To pokazuje, że kampania nie opierała się wyłącznie na prostym skrypcie postinstall, lecz wykorzystywała bardziej elastyczny i trudniejszy do wykrycia model wykonania.
Końcowa faza używała modułu vm w Node.js do realizacji działań zależnych od systemu operacyjnego ofiary. Na Windows malware kończył działanie wybranych aplikacji firmowych, w tym narzędzi bezpieczeństwa, VPN i oprogramowania biurowego, po czym podmieniał ich kod na zmodyfikowaną wersję z trojanem. Na Linux pobierany był binarny payload do katalogu tymczasowego, uruchamiany jako proces odłączony, a następnie usuwany z dysku po załadowaniu do pamięci. Na macOS dodawano złośliwy skrypt do ~/.zshrc oraz konfigurowano mechanizm Launch Agent uruchamiany cyklicznie.
Sam RAT oferował funkcje typowe dla zaawansowanych backdoorów:
- zdalne wykonywanie poleceń,
- wysyłanie i pobieranie plików,
- profilowanie zainfekowanego hosta,
- dostarczanie kolejnych ładunków,
- utrzymanie dostępu i przemieszczanie boczne.
Do powiązanych pakietów zaliczono m.in. lib-mtop, aone-kit, aone-kit-cli, aone-sandbox, local-config-parser, smart-config-manager, cloud-config-fetcher, fast-transform-pipeline, aone-cloud-cli, colder-cli, def-open-client, feedback-ai-sdk, flight-compare-analyzer, lwp-web-client, lzd-unified-station-sdk, open-worker-cli, test-skill-zip oraz uniapi-bridge.
Konsekwencje / ryzyko
Największe zagrożenie w tego typu incydentach wynika z faktu, że stacje deweloperskie bardzo często mają dostęp do kluczowych zasobów organizacji. Mogą to być repozytoria kodu, tokeny CI/CD, klucze SSH, poświadczenia chmurowe, certyfikaty podpisu czy dostęp do środowisk produkcyjnych.
W praktyce oznacza to, że pojedyncza infekcja npm może doprowadzić do pełnoskalowego naruszenia bezpieczeństwa. Nawet jeśli liczba pobrań złośliwych pakietów była niewielka, nie zmniejsza to znaczenia zagrożenia, jeśli kampania była ukierunkowana na konkretne organizacje lub zespoły o wysokiej wartości operacyjnej.
Dodatkowe ryzyko wiąże się z trwałym osadzeniem malware w aplikacjach używanych codziennie przez pracowników. W takim scenariuszu samo usunięcie pakietu npm nie wystarcza, ponieważ złośliwe artefakty mogą pozostać w systemie, aplikacjach i mechanizmach persistence.
Rekomendacje
Organizacje powinny traktować instalację któregokolwiek z wymienionych pakietów jako potencjalną kompromitację hosta. W pierwszej kolejności należy odizolować podejrzane stacje od sieci, przeprowadzić analizę pamięci i artefaktów trwałości oraz zweryfikować historię instalacji pakietów zarówno na stacjach roboczych, jak i w pipeline’ach CI/CD.
Konieczna jest także natychmiastowa rotacja wszystkich sekretów z wykorzystaniem czystego urządzenia. Dotyczy to tokenów npm, poświadczeń Git, kluczy SSH, danych dostępowych do chmury, sekretów CI/CD, dostępu VPN oraz innych danych używanych przez narzędzia deweloperskie.
- blokowanie instalacji nieautoryzowanych pakietów i stosowanie list dozwolonych zależności,
- monitorowanie anomalii w drzewach zależności, zwłaszcza pakietów imitujących prywatne moduły,
- skanowanie pakietów pod kątem ryzykownych skryptów instalacyjnych i dynamicznego pobierania kodu,
- oddzielenie uprawnień deweloperów od sekretów produkcyjnych,
- podpisywanie i weryfikację artefaktów w łańcuchu dostaw,
- wdrożenie reguł EDR/XDR dla modyfikacji
~/.zshrc,Launch Agents, katalogów tymczasowych i procesów uruchamianych przez menedżery pakietów, - inspekcję połączeń wychodzących do nietypowych domen i repozytoriów używanych podczas instalacji zależności,
- utrzymywanie wewnętrznego mirroru pakietów oraz polityki pinowania wersji.
Podsumowanie
Wykrycie 18 złośliwych pakietów npm pokazuje, że ataki na łańcuch dostaw stają się coraz bardziej selektywne, wielowarstwowe i trudne do wykrycia. Kluczową rolę odegrało tu podszywanie się pod prywatne pakiety, rozproszenie logiki w zależnościach oraz dostarczenie wieloplatformowego RAT-a zdolnego do utrzymania dostępu i ruchu bocznego.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona środowisk deweloperskich, kontrola zależności open source i szybka reakcja na incydenty związane z npm muszą być traktowane priorytetowo. Zwłaszcza w organizacjach, gdzie stacje programistów stanowią pomost do systemów o krytycznym znaczeniu biznesowym.
Źródła
- 18 Malicious npm Packages Deliver Cross-Platform RAT to Alibaba Tool Users — https://thehackernews.com/2026/08/18-malicious-npm-packages-deliver-cross.html
- Socket Research on Malicious npm Packages — https://socket.dev
- npm Package Registry — https://www.npmjs.com/
- GitHub — https://github.com/