PhantomRaven powraca: nowa fala złośliwych pakietów npm uderza w deweloperów i CI/CD - Security Bez Tabu

PhantomRaven powraca: nowa fala złośliwych pakietów npm uderza w deweloperów i CI/CD

Cybersecurity news

Wprowadzenie do problemu / definicja

PhantomRaven to kampania ataków na łańcuch dostaw oprogramowania wymierzona w ekosystem npm. Jej operatorzy publikują złośliwe pakiety podszywające się pod legalne biblioteki JavaScript, a następnie wykorzystują je do pobrania kolejnego etapu malware i kradzieży danych z maszyn deweloperskich oraz środowisk automatyzacji.

Najnowsza odsłona tej operacji pokazuje, że zagrożenie dla deweloperów pozostaje aktywne i jest rozwijane w sposób utrudniający klasyczne metody wykrywania. Problem nie dotyczy wyłącznie pojedynczych stacji roboczych, lecz całego procesu tworzenia i dostarczania oprogramowania.

W skrócie

W marcu 2026 roku opisano trzy nowe fale kampanii PhantomRaven, w których zidentyfikowano 88 złośliwych pakietów npm publikowanych z użyciem ponad 50 jednorazowych kont. Atakujący zastosowali technikę Remote Dynamic Dependencies, dzięki której właściwy złośliwy kod nie musiał znajdować się bezpośrednio w opublikowanej paczce.

Po instalacji malware zbierał między innymi adresy e-mail, dane systemowe, informacje konfiguracyjne oraz tokeny powiązane z usługami deweloperskimi i CI/CD. Następnie dane były eksfiltrowane do infrastruktury kontrolowanej przez napastników.

  • 88 złośliwych pakietów npm w nowych falach kampanii
  • Ponad 50 kont wykorzystanych do publikacji
  • Kradzież danych z plików konfiguracyjnych i zmiennych środowiskowych
  • Celowanie w tokeny GitHub, GitLab, Jenkins i CircleCI
  • Obchodzenie detekcji poprzez zewnętrzne zależności i rotację infrastruktury

Kontekst / historia

PhantomRaven został ujawniony jesienią 2025 roku jako szeroko zakrojona kampania wymierzona w użytkowników npm. Już wtedy badacze wskazywali, że atak nie jest jednorazową akcją, lecz elementem szerszego modelu operacyjnego opartego na wielokrotnym publikowaniu nowych paczek, zmianie domen C2 i szybkim porzucaniu użytych kont.

Nowe fale aktywności obserwowano od listopada 2025 do lutego 2026 roku. Z perspektywy obrońców szczególnie istotne jest to, że operatorzy nie opierali się wyłącznie na ukrywaniu złośliwego kodu w samym archiwum npm, lecz konsekwentnie przenosili właściwy ładunek do zależności pobieranej z zewnętrznego adresu URL. Taki model utrudnia analizę statyczną i pozwala utrzymywać kampanię przez dłuższy czas.

Analiza techniczna

Rdzeń techniczny kampanii opiera się na mechanizmie Remote Dynamic Dependencies. W praktyce oznacza to, że wpis w pliku package.json może odwoływać się nie tylko do paczki z oficjalnego rejestru, ale również do zewnętrznego zasobu kontrolowanego przez napastnika. Gdy ofiara uruchamia standardową instalację zależności, narzędzie pobiera komponent spoza zaufanego źródła i wykonuje zawarty w nim kod.

Takie podejście daje atakującym kilka istotnych przewag. Złośliwy kod nie musi być wprost obecny w paczce widocznej w rejestrze, co zmniejsza szansę wykrycia przez automatyczne skanery. Dodatkowo ładunek może być modyfikowany po publikacji, bez konieczności aktualizowania pakietu npm, a infrastruktura eksfiltracji może być rotowana niemal niezależnie od samej paczki.

Według analiz złośliwy kod wykonywał po uruchomieniu kilka działań rozpoznawczych i eksfiltracyjnych. Obejmowały one zbieranie danych z plików takich jak .gitconfig i .npmrc, odczyt zmiennych środowiskowych oraz wyszukiwanie tokenów i sekretów związanych z popularnymi platformami developerskimi oraz systemami CI/CD.

  • pobieranie danych konfiguracyjnych z maszyny ofiary
  • odczyt informacji z plików użytkownika i ustawień npm
  • pozyskiwanie zmiennych środowiskowych
  • wyszukiwanie tokenów GitHub, GitLab, Jenkins i CircleCI
  • zbieranie telemetrii systemowej, w tym adresu IP, nazwy hosta, systemu operacyjnego i wersji Node.js
  • przesyłanie danych do serwerów C2

Eksfiltracja była realizowana głównie przez żądania HTTP GET, ale obserwowano również wykorzystanie HTTP POST oraz WebSocket jako metod zapasowych. Sugeruje to, że operatorzy dbali o odporność kanałów wycieku i chcieli zwiększyć skuteczność działania także w środowiskach z częściowo ograniczonym ruchem sieciowym.

Badacze zauważyli ponadto charakterystyczne cechy infrastruktury: spójne wzorce nazewnictwa domen zawierających słowo „artifact”, hostowanie na AWS EC2, brak certyfikatów TLS oraz niewielkie różnice między payloadami kolejnych fal. Oznacza to, że mimo zmian domen i kont publikujących model operacyjny kampanii pozostawał w dużej mierze niezmienny.

Dodatkowym elementem ryzyka jest stosowanie nazw pakietów wyglądających wiarygodnie i przypominających legalne projekty. Mechanizm ten bywa porównywany do slopsquattingu, czyli wykorzystywania nazw, które mogą zostać błędnie zasugerowane przez narzędzia AI lub bezrefleksyjnie skopiowane przez dewelopera z podpowiedzi czy niezweryfikowanego wpisu.

Konsekwencje / ryzyko

Skutki kampanii PhantomRaven mogą być znacznie poważniejsze niż zwykły incydent na pojedynczej stacji roboczej. Kompromitacja środowiska deweloperskiego daje atakującym możliwość pozyskania sekretów, które następnie mogą zostać użyte do dalszego ruchu bocznego, przejęcia pipeline’ów, dostępu do repozytoriów oraz potencjalnego skażenia procesu wydawniczego.

Największe ryzyko wynika z tego, że nawet jednorazowa instalacja złośliwego pakietu może otworzyć drogę do szerszego ataku na organizację. W przypadku przejęcia tokenów CI/CD lub danych dostępowych do repozytoriów incydent może szybko przerodzić się w naruszenie integralności kodu i artefaktów produkcyjnych.

  • przejęcie tokenów i sekretów używanych w procesach CI/CD
  • nieautoryzowany dostęp do repozytoriów i systemów build
  • ryzyko dalszego skażenia artefaktów i paczek
  • wyciek danych identyfikujących deweloperów i infrastrukturę
  • eskalacja do pełnowymiarowego ataku na łańcuch dostaw

Rekomendacje

Organizacje rozwijające oprogramowanie w ekosystemie JavaScript powinny traktować podobne kampanie jako trwałe zagrożenie operacyjne. Sama analiza podatności nie wystarczy, ponieważ problem dotyczy złośliwych pakietów i zależności pobieranych dynamicznie z niezaufanych lokalizacji.

  • blokować lub ściśle monitorować zależności wskazujące na zewnętrzne adresy URL w package.json
  • egzekwować korzystanie wyłącznie z zatwierdzonych rejestrów i zaufanych publisherów
  • wdrożyć skanowanie pakietów pod kątem złośliwych zachowań, nie tylko znanych CVE
  • analizować skrypty preinstall, postinstall i inne hooki instalacyjne
  • ograniczać uprawnienia tokenów deweloperskich i CI/CD zgodnie z zasadą najmniejszych uprawnień
  • rotować sekrety po każdym podejrzeniu instalacji niezweryfikowanej paczki
  • monitorować ruch wychodzący ze stacji deweloperskich i runnerów CI
  • szkolić zespoły, aby weryfikowały nazwy pakietów sugerowane przez narzędzia AI i poradniki zewnętrzne
  • utrzymywać wewnętrzny allowlist pakietów oraz mirror zależności dla projektów produkcyjnych
  • włączyć detekcję wskaźników kompromitacji związanych z nietypowymi domenami i ruchem HTTP bez TLS

W przypadku podejrzenia kompromitacji należy przeanalizować logi instalacji zależności, sprawdzić historię użycia tokenów, zweryfikować integralność pipeline’ów oraz odtworzyć listę pakietów instalowanych w okresie ryzyka. Reakcja powinna obejmować zarówno stacje robocze, jak i środowiska automatyzacji.

Podsumowanie

PhantomRaven potwierdza, że współczesne ataki na łańcuch dostaw w npm nie muszą wykorzystywać szczególnie skomplikowanego malware, aby były skuteczne. Wystarczy połączenie dobrze dobranej techniki ukrywania drugiego etapu, rotacji infrastruktury i wykorzystania zaufania deweloperów do popularnego ekosystemu pakietów.

Dla zespołów bezpieczeństwa kluczowe staje się dziś nie tylko monitorowanie tego, jakie biblioteki są instalowane, ale również skąd są pobierane i jakie działania wykonują podczas procesu instalacji. Kontrola pochodzenia zależności, ochrona sekretów i telemetria z procesów build pozostają podstawą obrony przed takimi kampaniami.

Źródła

  1. BleepingComputer — New PhantomRaven NPM attack wave steals dev data via 88 packages — https://www.bleepingcomputer.com/news/security/new-phantomraven-npm-attack-wave-steals-dev-data-via-88-packages/
  2. Endor Labs — The Return of PhantomRaven: Detecting Three New Waves of npm Supply Chain Attacks — https://www.endorlabs.com/learn/return-of-phantomraven