Co to jest CVE (Common Vulnerabilities and Exposures)?
CVE (Common Vulnerabilities and Exposures) to międzynarodowy standard nazewnictwa publicznie znanych luk bezpieczeństwa w oprogramowaniu i sprzęcie. Mówiąc prościej, jest to lista unikatowych identyfikatorów podatności oraz związany z nią system ich katalogowania. Dzięki CVE specjaliści ds. cyberbezpieczeństwa na całym świecie mogą mówić jednym językiem o konkretnych lukach – niezależnie od platformy czy producenta.
Aktywna kampania PhantomRaven celuje w programistów ekosystemu JavaScript, publikując dziesiątki złośliwych paczek w rejestrze npm. Ich celem jest kradzież tokenów uwierzytelniających (npm, GitHub Actions, GitLab, Jenkins, CircleCI), sekretów CI/CD oraz poświadczeń do repozytoriów, co otwiera drogę do wtórnych ataków na łańcuch dostaw oprogramowania. Kampania rozpoczęła się w sierpniu 2025 r., obejmuje 126 paczek i przekroczyła 86 000 pobrań. Zidentyfikowali ją badacze Koi Security; część paczek w momencie publikacji raportów była wciąż dostępna w npm.
Technika ukrycia:Remote Dynamic Dependencies (RDD) – paczki deklarują 0 zależności, a właściwy ładunek dociągają z zewnętrznego serwera podczas npm install.
Egzekucja: wykorzystanie skryptów lifecycle (np. preinstall) do automatycznego uruchomienia payloadu bez interakcji użytkownika.
Kradzione dane: tokeny npm/GitHub/GitLab/Jenkins/CircleCI, fingerprinting systemu i środowiska CI/CD, adresy e-mail.
Exfiltracja: redundancja kanałów (HTTP GET z danymi w URL, HTTP POST/JSON, WebSocket).
Socjotechnika nazw:slopsquatting – wykorzystywanie halucynacji LLM do rejestrowania nieistniejących, lecz „wiarygodnie brzmiących” nazw paczek.
Kontekst / historia / powiązania
Ukrywanie złośliwego kodu w pakietach open source nie jest nowe, jednak PhantomRaven łączy kilka trendów: nadużycie rzadko używanej funkcji npm (URL-owe specyfikatory zależności), automatyczne skrypty instalacyjne i LLM-asystowanych rekomendacji paczek. Media branżowe opisują to jako ataki z „niewidzialnymi zależnościami”, które omijają statyczne skanery rejestrów i klasyczne analizatory SBOM.
Analiza techniczna / szczegóły luki
Remote Dynamic Dependencies (RDD)
Zamiast standardowych wpisów w "dependencies", złośliwe paczki wskazują HTTP URL (np. http://packages.storeartifact.com/...). Taki komponent nie znajduje się w npmjs.com, więc wiele narzędzi SCA/SAST go nie analizuje – interfejs npm pokazuje „0 dependencies”, co uśpiwa czujność. Podczas npm install pobierany jest zdalny pakiet, który zawiera preinstall uruchamiający złośliwy kod.
Łańcuch ataku
Deweloper instaluje pozornie czystą paczkę z npm.
Npm dociąga „niewidzialną” zależność z kontrolowanego przez atakującego hosta.
Skrypt preinstall uruchamia się automatycznie, bez pytań.
Malware wykonuje profilowanie systemu, enumerację e-maili i zbieranie sekretów CI/CD.
Dane są eksfiltrowane wieloma kanałami (GET/POST/WebSocket).
Fingerprinting: IP publiczny i lokalny, hostname, OS, wersja Node.js, bieżący katalog.
Artefakty identyfikacyjne: adresy e-mail z env, .gitconfig, .npmrc, package.json.
Infrastruktura i IoC
Domena/C2:packages.storeartifact.com
IP:54.173.15.59
Endpoint exfiltracyjny:jpd.php
Wzorce kont/e-maili publikujących:jpdtester0X@..., m.in. jpdtester07@outlook[.]com, jpdtester12@gmail[.]com itd.
Przykładowe nazwy paczek:unused-imports, eslint-comments, transform-react-remove-prop-types, @gitlab-lsp/*, artifactregistry-login, crowdstrike, react-async-component-lifecycle-hooks, syntax-dynamic-import i wiele innych (pełna lista w raporcie Koi).
Slopsquatting (LLM-assisted naming)
Atakujący rejestrują nieistniejące wcześniej, lecz „wiarygodne” nazwy, które LLM potrafią podpowiadać jako rzekomo właściwe („unused-imports” vs. prawidłowe eslint-plugin-unused-imports, itp.). To omija proste reguły typosquattingu i zwiększa skuteczność socjotechniki wobec developerów polegających na asystentach AI.
Praktyczne konsekwencje / ryzyko
Przejęcie pipeline’ów i możliwość dorzucenia złośliwych commitów/releasów (supply-chain).
Kradzież sekretów skutkująca lateral movement do chmur, rejestrów artefaktów i środowisk produkcyjnych.
Trudna detekcja w klasycznych skanerach – ładunek nie jest obecny w artefakcie z npm, a zależności wyglądają na puste.
Rekomendacje operacyjne / co zrobić teraz
Natychmiastowa reakcja (IR):
Blokada IoC: zablokuj packages.storeartifact.com i powiązane IP na egressie; monitoruj ruch HTTP/WS do niezatwierdzonych hostów.
Hunting: przeszukaj logi o instalacjach paczek z listy Koi; sprawdź wywołania npm install z nietypowymi URL-ami w package.json/package-lock.json.
Rotacja sekretów:unieważnij tokeny npm/GitHub/GitLab/Jenkins/CircleCI, klucze API i hasła; wymuś ponowną autoryzację runnerów/agentów.
Przegląd repozytoriów: audit ostatnich commitów/tagów/CI workflows pod kątem nieautoryzowanych zmian.
Twardnienie (hardening) na przyszłość:
Wyłącz skrypty lifecycle podczas CI: uruchamiaj npm ci z --ignore-scripts (lub npm config set ignore-scripts true w pipeline’ach, a w razie potrzeby whitelistuj pojedyncze przypadki). Uzupełnij o izolację sieciową stepów instalacyjnych. (Zasada wynika z analizy mechanizmu preinstall.)
Blokada zależności z URL: polityki DevSecOps/SCA powinny odrzucać HTTP(S) dependencies w package.json. Monitoruj PR-y pod kątem zmian w sekcji dependencies/scripts.
Wymuś 2FA i OIDC-based tokens dla dostępu do rejestrów/kont CI/CD; minimalne uprawnienia i krótkie TTL tokenów.
SBOM + detekcja behawioralna: klasyczny SBOM nie pokaże RDD; uzupełnij go o dynamiczną analizę instalacji (wykrywanie połączeń sieciowych podczas npm install).
Repozytoria lustrzane/air-gap: rozważ wewnętrzne mirrorowanie uznanych paczek i blokadę instalacji z internetu w CI (allowlist).
Edukacja dot. LLM: wprowadź guideline’y nt. weryfikacji nazw paczek sugerowanych przez AI; wymagaj sprawdzenia istnienia i reputacji projektu.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Klasyczny typosquatting: złośliwy kod siedzi w paczce na rejestrze; tutaj kod jest poza rejestrem (RDD), więc omija wiele skanerów.
Kampanie 2023–2025 (npm/PyPI) nierzadko używały postinstall do exfiltracji; PhantomRaven dodaje „niewidzialne” zależności i slopsquatting, co utrudnia detekcję i zwiększa skuteczność dystrybucji.
Podsumowanie / kluczowe wnioski
PhantomRaven pokazuje, jak łatwo połączyć niszowe funkcje npm, automatyczne skrypty instalacyjne i błędy poznawcze (zaufanie do LLM) w skuteczny atak na łańcuch dostaw. Krytyczne są: blokada HTTP-owych zależności, wyłączenie skryptów lifecycle w CI, rotacja i krótkie TTL tokenów, monitoring ruchu podczas instalacji oraz dyscyplina weryfikacji paczek – szczególnie tych „poleconych” przez asystentów AI.
Greenbone Vulnerability Management (GVM) to otwartoźródłowy pakiet narzędzi do skanowania i zarządzania podatnościami w sieciach komputerowych. Projekt ten narodził się jako OpenVAS (Open Vulnerability Assessment System) – pierwotnie sam skaner podatności wywodzący się z otwartej wersji Nessusa. Z czasem firma Greenbone rozbudowała go o dodatkowe komponenty (zarządzanie wynikami, bazę danych, interfejs WWW) i przemianowała cały ekosystem na GVM, począwszy od wersji po OpenVAS 9.
Jestem przekonany, że nie ma bardziej odpowiedniej osoby do rozmowy o bezpieczeństwie chmury niż człowiek, który tworzy platformę Cloud Computing – Kacper Dąbrowski – CEO vmgen . Zapraszam Was do ciekawej rozmowy, którą przeprowadziliśmy. Wciągniecie z niej wiele wartości i mam nadzieję, że lepiej poznacie nie tylko jego samego, ale również całą ideę stojącą za vmgen i ich wizję.
Największy interdyscyplinarny festiwal technologiczny dla programistów w Polsce!
„4Developers to jedno z najbardziej rozpoznawalnych wydarzeń dla programistów w Polsce. Ogólnopolski, interdyscyplinarny Festiwal technologiczny zrzesza polską społeczność IT już od ponad 13 lat. Pod szyldem marki kryją się także lokalne edycje Festiwalu, które odbywają się w różnych miastach Polski.” W edycji jesiennej przeniesiony został całkowicie zdalnie.
Znasz to pytanie? Usłyszałem je w ostatnim czasie dziesiątki razy. Od kolegów, którzy mają swoje określenie, ale szukają opcji do żywej dyskusji; od specjalistów z branży IT, którzy szukają odpowiedzi dla samych siebie; ale również od dyrektorów IT.
