Samoreplikujący się robak w łańcuchu dostaw atakuje npm i kradnie tokeny deweloperskie

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla zespołów developerskich oraz środowisk CI/CD. Najnowsza kampania pokazuje, że przestępcy coraz częściej łączą kradzież poświadczeń z mechanizmami automatycznej propagacji, aby rozszerzać skalę kompromitacji bez konieczności ręcznego przejmowania kolejnych ofiar.

W opisywanym przypadku celem stał się ekosystem npm. Złośliwe pakiety uruchamiają malware podczas instalacji, wykradają sekrety z maszyn deweloperskich, a następnie wykorzystują przejęte tokeny do publikowania kolejnych zainfekowanych komponentów. To sprawia, że mamy do czynienia nie tylko ze stealerem, ale z robakiem supply chain.

W skrócie

• Złośliwy kod był uruchamiany automatycznie przez mechanizm postinstall w pakietach npm.
• Malware kradło m.in. pliki .npmrc, klucze SSH, poświadczenia Git, dane chmurowe, konfiguracje Dockera i Kubernetes oraz pliki środowiskowe.
• Przejęte tokeny npm mogły zostać użyte do publikacji kolejnych złośliwych wersji pakietów.
• Badacze wskazali również logikę mogącą wspierać propagację do ekosystemu PyPI.
• Ryzyko obejmuje zarówno deweloperów, jak i organizacje zależne od zainfekowanych bibliotek.

Kontekst / historia

Incydent wpisuje się w rosnącą falę ataków na otwarte rejestry pakietów oraz środowiska budowy oprogramowania. W ostatnim czasie cyberprzestępcy coraz częściej wykorzystują zaufanie do bibliotek open source, przejętych kont publikacyjnych i automatycznych procesów instalacji zależności.

Kampania określana jako CanisterSprawl pokazuje zmianę jakościową w tego typu operacjach. Zamiast jednorazowej infekcji i zwykłej kradzieży danych, atakujący próbują budować samonapędzający się mechanizm, który po udanym przejęciu środowiska deweloperskiego może prowadzić do kolejnych kompromitacji pakietów, projektów i użytkowników końcowych.

Szczególnie niebezpieczny jest fakt, że użytkownik nie musi wykonywać żadnych nietypowych działań. W wielu przypadkach wystarczy standardowa instalacja zależności, aby uruchomić złośliwy ładunek i rozpocząć proces eksfiltracji danych.

Analiza techniczna

Mechanizm infekcji opiera się na hooku postinstall, który wykonuje kod już po pobraniu pakietu przez menedżer zależności. To bardzo skuteczna technika, ponieważ uruchomienie złośliwej logiki następuje automatycznie i może zostać przeoczone w rutynowych procesach developerskich.

Po uruchomieniu malware przeszukuje lokalne środowisko w celu pozyskania materiału uwierzytelniającego i informacji konfiguracyjnych przydatnych do dalszej eskalacji dostępu oraz rozprzestrzeniania ataku.

• konfiguracje npm i zapisane tokeny publikacji,
• klucze SSH oraz konfiguracje SSH,
• poświadczenia Git i pliki .netrc,
• dane dostępowe do usług chmurowych,
• konfiguracje Kubernetes i Dockera,
• artefakty związane z Terraform, Pulumi i Vault,
• pliki .env i dane bazodanowe,
• historia poleceń powłoki.

Według analiz złośliwe oprogramowanie próbowało także uzyskiwać dostęp do danych z przeglądarek opartych na Chromium oraz artefaktów powiązanych z rozszerzeniami portfeli kryptowalutowych. Zebrane informacje były następnie wyprowadzane do zewnętrznej infrastruktury odbiorczej.

Najgroźniejszym elementem kampanii jest jednak automatyzacja propagacji. Jeśli atakujący przejmie token npm z odpowiednimi uprawnieniami, może opublikować kolejne zainfekowane pakiety lub nowe wersje istniejących bibliotek. W ten sposób pojedyncza kompromitacja stacji roboczej programisty może przerodzić się w szersze naruszenie integralności całego łańcucha dostaw.

Obecność logiki ukierunkowanej na PyPI sugeruje, że operatorzy kampanii chcą wyjść poza ekosystem JavaScript i Node.js. To istotny sygnał dla organizacji rozwijających oprogramowanie wielojęzyczne, gdzie na jednej stacji roboczej współistnieją narzędzia npm, pip, Docker, Git i usługi chmurowe.

Konsekwencje / ryzyko

Ryzyko dla organizacji ma charakter wielowarstwowy. Pierwszą konsekwencją jest bezpośrednia utrata sekretów z maszyn deweloperskich, systemów build i środowisk automatyzacji. Drugą jest możliwość wykorzystania skradzionych tokenów do publikowania złośliwych wersji legalnych pakietów, co rozszerza skutki incydentu na klientów, partnerów i użytkowników końcowych.

Dodatkowo wyciek konfiguracji chmurowych, danych do kontenerów i narzędzi infrastruktury jako kodu może umożliwić ruch boczny, utrzymanie trwałej obecności oraz dalszą kompromitację pipeline’ów release.

• przejęcie kont deweloperskich i repozytoriów,
• publikacja złośliwych bibliotek w oficjalnych rejestrach,
• kompromitacja środowisk CI/CD,
• utrata integralności procesu build i release,
• wyciek sekretów organizacyjnych,
• rozszerzenie ataku na odbiorców korzystających z zakażonych zależności.

Najbardziej dotkliwy może być jednak wpływ na zaufanie. Nawet jeśli produkcja nie zostanie naruszona bezpośrednio, kompromitacja pakietów open source powiązanych z organizacją może wymusić kosztowny proces rotacji sekretów, przeglądu wydań, odtwarzania zaufania do artefaktów i audytu całego łańcucha dostaw.

Rekomendacje

Organizacje powinny potraktować tego typu incydent jako priorytet dla zespołów AppSec, DevSecOps i administratorów środowisk developerskich. Każdy system, na którym zainstalowano podejrzane wersje pakietów, należy uznać za potencjalnie skompromitowany do czasu pełnej weryfikacji.

• natychmiast wycofać i zablokować wskazane wersje pakietów,
• przeprowadzić pełną rotację tokenów npm, kluczy SSH, poświadczeń Git i sekretów chmurowych,
• zweryfikować historię publikacji pakietów pod kątem nieautoryzowanych wydań,
• przeanalizować logi CI/CD i zmiany w konfiguracjach automatyzacji,
• przeskanować hosty pod kątem artefaktów persistence, nietypowych hooków i zmian w katalogach użytkownika,
• wymusić zasadę najmniejszych uprawnień oraz krótkie życie tokenów,
• ograniczyć publikację pakietów do wydzielonych, zaufanych środowisk release,
• monitorować instalacje zależności i blokować podejrzane skrypty postinstall,
• przechowywać sekrety w dedykowanych menedżerach zamiast w lokalnych plikach,
• wdrożyć dodatkową walidację pakietów, sygnatur artefaktów i polityk dopuszczania zależności.

Dobrą praktyką pozostaje również rozdzielenie środowisk developerskich od kont produkcyjnych i publikacyjnych. Jedna stacja robocza nie powinna przechowywać pełnego zestawu sekretów potrzebnych jednocześnie do programowania, publikacji i administracji infrastrukturą.

Podsumowanie

Opisana kampania potwierdza, że ataki na łańcuch dostaw oprogramowania rozwijają się w kierunku bardziej agresywnych i zautomatyzowanych modeli działania. Połączenie hooków instalacyjnych, kradzieży tokenów publikacyjnych i samoreplikacji przez rejestry pakietów znacząco zwiększa zagrożenie dla organizacji korzystających z npm i PyPI.

Najskuteczniejszą odpowiedzią pozostają szybka identyfikacja ekspozycji, pełna rotacja sekretów, twarda kontrola procesu publikacji oraz wzmocnienie ochrony środowisk deweloperskich i pipeline’ów CI/CD. W praktyce to właśnie bezpieczeństwo stacji roboczych programistów staje się dziś jednym z kluczowych elementów obrony całego łańcucha dostaw.

Źródła

1. The Hacker News — https://thehackernews.com/2026/04/self-propagating-supply-chain-worm.html
2. Socket — https://socket.dev
3. StepSecurity — https://www.stepsecurity.io
4. JFrog Security Research — https://research.jfrog.com
5. Wiz Research — https://www.wiz.io