18 złośliwych pakietów npm uderza w użytkowników narzędzi Alibaba i dostarcza wieloplatformowego RAT-a - Security Bez Tabu

18 złośliwych pakietów npm uderza w użytkowników narzędzi Alibaba i dostarcza wieloplatformowego RAT-a

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających i wdrażających aplikacje. Najnowsza kampania wykazała, że cyberprzestępcy potrafią skutecznie wykorzystać zaufanie do ekosystemu npm, publikując złośliwe pakiety podszywające się pod komponenty kojarzone z narzędziami Alibaba. Celem operacji było dostarczenie wieloplatformowego trojana zdalnego dostępu, który działa na Windows, Linux i macOS.

Tego typu incydenty są szczególnie niebezpieczne, ponieważ uderzają bezpośrednio w środowiska deweloperskie, gdzie często znajdują się poświadczenia uprzywilejowane, tokeny CI/CD, dostęp do repozytoriów kodu oraz dane potrzebne do dalszej penetracji infrastruktury firmy.

W skrócie

Badacze bezpieczeństwa wykryli 18 złośliwych pakietów npm powiązanych z ukierunkowaną kampanią wymierzoną w użytkowników narzędzi i zależności związanych z ekosystemem Alibaba. Pakiety wykorzystywały nazewnictwo przypominające prywatne komponenty, co zwiększało szanse na ich nieświadomą instalację przez deweloperów.

  • atak obejmował 18 pakietów npm,
  • kampania miała charakter wieloetapowy,
  • końcowy ładunek pełnił funkcję wieloplatformowego RAT-a,
  • zagrożone były systemy Windows, Linux i macOS,
  • celem były przede wszystkim środowiska deweloperskie i korporacyjne.

Kontekst / historia

Jednym z kluczowych elementów kampanii był pakiet lib-mtop, który występował jako publiczny pakiet o nazwie zbieżnej z prywatnym komponentem funkcjonującym w innym zakresie. Z ustaleń wynika, że pakiet był obecny już od listopada 2023 roku, natomiast złośliwe zmiany pojawiły się dopiero w wydaniach opublikowanych w marcu i kwietniu 2026 roku. Taki schemat odpowiada modelowi „uśpionego” pakietu, który przez długi czas nie wzbudza podejrzeń, a następnie zostaje wykorzystany do przeprowadzenia ataku.

Nie jest jednoznacznie potwierdzone, czy doszło do przejęcia konta maintenera, czy też złośliwy kod został dodany świadomie przez autora. Niezależnie od źródła kompromitacji, incydent wpisuje się w rosnący trend nadużywania zaufania do publicznych rejestrów pakietów oraz do narzędzi używanych w codziennej pracy zespołów programistycznych.

Analiza techniczna

Łańcuch infekcji został zbudowany warstwowo. Na najwyższym poziomie znajdowały się pakiety-przynęty, których zadaniem było uruchomienie zależności prowadzących do kolejnych modułów. Dzięki temu początkowe paczki mogły wyglądać niegroźnie, a właściwa logika ataku była rozbita na kilka komponentów, co utrudniało wykrycie podczas analizy statycznej.

Warstwę pośrednią stanowiły pakiety pełniące funkcję pomostu między przynętą a właściwym loaderem. Jednym z opisywanych przykładów był smart-config-manager, odpowiedzialny za przekazanie sterowania do modułów pobierających dalszą konfigurację i kod wykonywalny. Taka architektura pozwalała rozproszyć zachowanie malware i ograniczyć liczbę jednoznacznych wskaźników kompromitacji w pojedynczym pakiecie.

Kluczowy loader pobierał zdalny kod JavaScript z wykorzystaniem narzędzi systemowych, takich jak curl, zapisywał go lokalnie, a następnie uruchamiał. W końcowym etapie używany był moduł vm w Node.js, dzięki któremu możliwe było wykonanie logiki dopasowanej do systemu operacyjnego ofiary.

  • na Windows malware miało kończyć działanie wybranych aplikacji bezpieczeństwa, VPN i narzędzi biurowych, a następnie podmieniać ich komponenty,
  • na Linux pobierany był binarny payload do katalogu tymczasowego, uruchamiany jako proces odłączony, po czym plik był usuwany,
  • na macOS złośliwy kod dopisywał skrypt do ~/.zshrc oraz konfigurował cykliczne uruchamianie przez Launch Agent.

Końcowy backdoor zapewniał szerokie możliwości operatorskie, w tym zdalne wykonywanie poleceń, transfer plików, zbieranie informacji o hoście, pobieranie kolejnych ładunków oraz ruch boczny. Dodatkowo potrafił utrzymywać trwałość przez modyfikację popularnych aplikacji używanych w środowiskach korporacyjnych, co wskazuje na zamiar długotrwałego utrzymania dostępu.

Konsekwencje / ryzyko

Największe ryzyko dotyczy kompromitacji stacji deweloperskich, które zwykle mają dostęp do kodu źródłowego, kluczy API, sekretów chmurowych, danych logowania do rejestrów pakietów oraz systemów wdrożeniowych. Przejęcie takiego hosta może stać się punktem wyjścia do naruszenia repozytoriów, systemów buildowych i środowisk produkcyjnych.

Incydent ma cechy ataku ukierunkowanego, a jego znaczenie nie powinno być oceniane wyłącznie przez pryzmat liczby pobrań. Nawet pojedyncza infekcja w odpowiedniej organizacji może umożliwić napastnikom dostęp do wysoce wrażliwych zasobów oraz dalszą eskalację uprawnień. Dodatkowym problemem jest wieloplatformowość malware, która komplikuje działania związane z analizą śledczą, izolacją oraz odbudową zaufania do pipeline’ów deweloperskich.

Rekomendacje

Organizacje powinny traktować obecność któregokolwiek z wykrytych pakietów jako potencjalną pełną kompromitację systemu, na którym został zainstalowany. W pierwszej kolejności należy ustalić, które hosty, kontenery buildowe i pipeline’y CI/CD miały styczność z podejrzanymi zależnościami, a następnie odizolować je od sieci i rozpocząć analizę incydentu.

  • przeprowadzić inwentaryzację pakietów w package.json, lockfile’ach oraz cache menedżerów pakietów,
  • zrotować wszystkie poświadczenia dostępne z potencjalnie zainfekowanych hostów,
  • przeanalizować historię skryptów instalacyjnych i anomalii w drzewie zależności,
  • sprawdzić mechanizmy trwałości, w tym wpisy w ~/.zshrc, Launch Agents i procesy z katalogów tymczasowych,
  • monitorować nietypowe połączenia wychodzące do zewnętrznych repozytoriów i serwerów konfiguracji,
  • wdrożyć listy dozwolonych zależności, scope’ów i rejestrów,
  • wzmocnić kontrolę integralności oraz skanowanie zależności w procesie budowania.

W dłuższej perspektywie warto ograniczyć możliwość instalowania nieautoryzowanych pakietów z publicznych rejestrów, stosować prywatne proxy dla npm oraz wdrażać narzędzia wykrywające dependency confusion i typosquatting. Kluczowe znaczenie ma również monitorowanie zmian wersji pakietów, które przez długi czas pozostawały nieaktywne, a następnie nagle otrzymały nowe wydania z dodatkowymi skryptami instalacyjnymi.

Podsumowanie

Opisana kampania pokazuje, że współczesne ataki na ekosystem npm są coraz bardziej precyzyjne i wielowarstwowe. Zamiast pojedynczego złośliwego komponentu napastnicy wykorzystali rozproszony łańcuch zależności, pakiety-wabiki i logikę aktywowaną dopiero na późnym etapie infekcji. Taki model znacząco utrudnia wykrycie i zwiększa skuteczność ataku przeciwko zespołom deweloperskim.

Dla organizacji oznacza to konieczność rozszerzenia podejścia do bezpieczeństwa łańcucha dostaw. Sama analiza znanych podatności nie wystarcza, jeśli nie towarzyszą jej kontrola źródeł pakietów, monitoring zachowań zależności, weryfikacja skryptów instalacyjnych i gotowość do szybkiego reagowania na oznaki kompromitacji środowisk programistycznych.

Źródła