Złośliwe wersje node-ipc na npm wykradają sekrety deweloperów i dane chmurowe

Wprowadzenie do problemu / definicja

Ekosystem npm ponownie znalazł się w centrum incydentu z obszaru bezpieczeństwa łańcucha dostaw oprogramowania. Tym razem zagrożenie dotyczy pakietu node-ipc, dla którego wykryto złośliwe wydania zawierające komponent typu stealer i backdoor. Problem jest szczególnie poważny, ponieważ pakiet mógł być wykorzystywany zarówno na stacjach roboczych programistów, jak i w pipeline’ach CI/CD, gdzie dostępne są cenne sekrety, klucze oraz dane uwierzytelniające.

W praktyce oznacza to, że zwykłe załadowanie biblioteki mogło uruchomić kod zbierający informacje o hoście, przeszukujący system plików i przygotowujący dane do eksfiltracji. Taki scenariusz znacząco zwiększa ryzyko przejęcia tożsamości maszynowych oraz dalszej kompromitacji środowisk deweloperskich i chmurowych.

W skrócie

Badacze bezpieczeństwa wskazali, że złośliwy payload znajdował się w wersjach node-ipc@9.1.6, node-ipc@9.2.3 oraz node-ipc@12.0.1. Kod uruchamiał się podczas ładowania modułu i był zaprojektowany do pozyskiwania sekretów deweloperskich oraz danych dostępowych do usług chmurowych.

• Atak dotyczył pakietu publikowanego w npm.
• Payload aktywował się na etapie runtime, a nie przez klasyczne hooki instalacyjne.
• Celem były m.in. klucze SSH, tokeny Kubernetes, dane Terraform i konfiguracje CLI.
• Eksfiltracja mogła odbywać się przez HTTPS oraz DNS.
• Za bezpieczne punkty odniesienia wskazywano wersje 9.2.1 oraz 12.0.0.

Kontekst / historia

Incydent wpisuje się w szerszy trend ataków na open source, w których przeciwnicy wykorzystują zaufanie do zależności instalowanych automatycznie przez deweloperów i systemy build. Zamiast bezpośrednio włamywać się do infrastruktury organizacji, napastnicy próbują przeniknąć przez biblioteki używane w codziennej pracy programistycznej.

Sprawa node-ipc budzi dodatkowe zainteresowanie, ponieważ pakiet był już wcześniej kojarzony z kontrowersyjnymi zmianami. Obecny przypadek ma jednak inny charakter: zamiast destrukcji lub sabotażu widać bardziej ukierunkowane działanie nastawione na cichą kradzież sekretów i przygotowanie gruntu pod dalsze etapy ataku. To ważny sygnał, że współczesne operacje supply chain coraz częściej skupiają się na przejmowaniu dostępu i długofalowej obecności w środowisku ofiary.

Analiza techniczna

Jednym z najbardziej niebezpiecznych elementów tego incydentu był sposób aktywacji złośliwego kodu. Malware nie korzystał z typowych skryptów preinstall, install czy postinstall, które bywają monitorowane przez narzędzia bezpieczeństwa. Zamiast tego złośliwa logika została osadzona bezpośrednio w pliku CommonJS, przez co uruchamiała się podczas wykonania require('node-ipc').

Analizy wskazują, że payload rozpoczynał działanie od profilowania hosta i identyfikacji środowiska. Następnie przeszukiwał system plików w poszukiwaniu informacji o wysokiej wartości operacyjnej. Wśród potencjalnych celów znajdowały się poświadczenia chmurowe, konfiguracje narzędzi developerskich, tokeny dostępowe, historia powłoki, dane bazodanowe, pliki konfiguracyjne oraz inne artefakty mogące zawierać hasła lub klucze.

Zebrane dane były kompresowane do archiwum GZIP, dzielone na fragmenty i przygotowywane do wysyłki. Badacze odnotowali też obecność mechanizmów obfuskacji oraz logiki szyfrującej, co utrudniało szybką analizę działania pakietu. W jednym z wariantów malware wykorzystywał dodatkowo warunek oparty na skrócie SHA-256, co może sugerować selektywne uruchamianie części funkcji wobec konkretnych ofiar.

Istotnym elementem był również kanał eksfiltracji. Oprócz prób przesyłania danych przez HTTPS, złośliwy kod miał wykorzystywać DNS do transportu fragmentów skradzionych informacji. Dodatkowo modyfikował sposób rozwiązywania nazw, kierując zapytania do infrastruktury kontrolowanej przez operatora. To technika, która może ograniczać widoczność incydentu w organizacjach polegających głównie na logach z wewnętrznych resolverów.

Analizy zwracały też uwagę na próbę odseparowania złośliwego działania od procesu nadrzędnego. Tworzenie procesu potomnego działającego w tle mogło umożliwiać kontynuację eksfiltracji nawet po zakończeniu głównego procesu Node.js, co utrudnia korelację zdarzeń i śledzenie pełnego przebiegu incydentu.

Konsekwencje / ryzyko

Skutki użycia złośliwej wersji pakietu mogą być bardzo poważne. Na stacjach roboczych programistów zagrożone są lokalne klucze SSH, tokeny dostępu do repozytoriów, konfiguracje CLI, dane chmurowe oraz inne sekrety zapisane w plikach użytkownika. Uzyskanie takich informacji przez napastnika może prowadzić do przejęcia kont, nieautoryzowanych wdrożeń lub dalszego ruchu bocznego w środowisku organizacji.

Jeszcze większe ryzyko dotyczy systemów CI/CD. Jeśli podatne wersje zostały uruchomione w pipeline’ach, należy zakładać możliwość ujawnienia sekretów używanych do budowania, publikacji i wdrażania oprogramowania. Może to obejmować tokeny do repozytoriów, poświadczenia do rejestrów kontenerów, klucze dostępu do chmury, certyfikaty podpisujące oraz dane wykorzystywane do publikacji pakietów i artefaktów.

Niebezpieczeństwo zwiększa fakt, że atak nie polegał na łatwo wykrywalnych skryptach instalacyjnych. Organizacje monitorujące wyłącznie etap instalacji mogły nie zauważyć nic podejrzanego. To pokazuje, że detekcja musi obejmować także zachowania runtime, nietypowe odczyty plików, kompresję danych oraz anomalie w ruchu DNS i HTTPS.

Rekomendacje

W pierwszej kolejności organizacje powinny ustalić, czy w ich środowiskach pojawiały się wersje 9.1.6, 9.2.3 lub 12.0.1 pakietu node-ipc. Kontrola powinna objąć nie tylko kod źródłowy i pliki lock, ale również logi buildów, cache menedżerów pakietów, obrazy kontenerowe oraz historię pipeline’ów.

Jeżeli wykryto użycie którejkolwiek z tych wersji, host należy traktować jako potencjalnie skompromitowany. W takiej sytuacji warto podjąć następujące działania:

• usunąć złośliwe wersje pakietu i przejść na znane czyste wydania,
• przeprowadzić rotację wszystkich sekretów dostępnych na danej maszynie lub w danym pipeline’ie,
• sprawdzić logi dostawców chmurowych pod kątem nietypowych działań,
• przeanalizować ruch wychodzący pod kątem podejrzanych domen i anomalii DNS,
• zweryfikować aktywność publikacyjną w rejestrach pakietów i repozytoriach kodu,
• przeprowadzić przegląd workflow, konfiguracji automatyzacji i zmian w projektach.

Długoterminowo należy rozważyć pinowanie zależności, ograniczenie automatycznych aktualizacji krytycznych pakietów oraz rozszerzenie skanowania zależności o analizę zachowań wykonywanych po załadowaniu biblioteki. Istotne jest także stosowanie zasady najmniejszych uprawnień, segmentacja środowisk build, monitorowanie dostępu do wrażliwych plików oraz wdrażanie krótkowiecznych poświadczeń zamiast długoterminowych kluczy przechowywanych lokalnie.

Podsumowanie

Incydent związany z node-ipc pokazuje, że nowoczesne ataki na łańcuch dostaw oprogramowania coraz częściej koncentrują się na przejęciu sekretów i tożsamości używanych przez deweloperów oraz systemy CI/CD. Złośliwe wersje pakietu nie ograniczały się do prostego uruchomienia dodatkowego malware, lecz realizowały wieloetapową kradzież danych, korzystały z obfuskacji i sięgały po niestandardowe techniki eksfiltracji.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona zależności open source musi obejmować cały cykl użycia biblioteki, a nie tylko etap instalacji. Każde potwierdzenie obecności wskazanych wersji powinno uruchomić pełną procedurę incident response, obejmującą analizę śladów kompromitacji, rotację sekretów oraz ocenę wpływu na cały proces dostarczania oprogramowania.

Źródła

1. Stealer Backdoor Found in 3 Node-IPC Versions Targeting Developer Secrets — https://thehackernews.com/2026/05/stealer-backdoor-found-in-3-node-ipc.html
2. Active Supply Chain Attack: Malicious node-ipc Versions Published to npm — https://www.stepsecurity.io/blog/node-ipc-npm-supply-chain-attack
3. node-ipc package versions on npm — https://www.npmjs.com/package/node-ipc?activeTab=versions
4. node-ipc package versions on Socket — https://socket.dev/npm/package/node-ipc/versions