Złośliwe pakiety npm ukrywają infrastrukturę C2 z użyciem Ethereum

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania w ekosystemie npm należą dziś do najgroźniejszych zagrożeń dla zespołów developerskich i organizacji budujących aplikacje w oparciu o JavaScript oraz Node.js. W opisywanym scenariuszu złośliwe pakiety zostały przygotowane tak, aby po instalacji uruchamiać szkodliwą logikę, a elementy komunikacji z infrastrukturą command-and-control ukrywać przy pomocy mechanizmów powiązanych z siecią Ethereum.

Tego rodzaju technika znacząco utrudnia wykrywanie incydentu, ponieważ kluczowe parametry operacyjne nie muszą być zapisane bezpośrednio w kodzie pakietu ani powiązane z klasyczną infrastrukturą serwerową. Z perspektywy obrony oznacza to odejście od prostych wskaźników kompromitacji na rzecz bardziej rozproszonego i trudniejszego do zablokowania modelu sterowania malware.

W skrócie

Zidentyfikowano złośliwe pakiety npm wykorzystujące Ethereum do ukrywania kanału C2.
Atak ogranicza widoczność tradycyjnych IOC, takich jak statyczne domeny czy adresy IP.
Zagrożone są nie tylko stacje robocze programistów, ale też pipeline’y CI/CD, środowiska build i systemy przechowujące sekrety.
Kampania wpisuje się w trend bardziej odpornych operacyjnie ataków supply chain.

Kontekst / historia

Ekosystem npm od lat pozostaje atrakcyjnym celem dla cyberprzestępców z uwagi na skalę wykorzystania, złożoność zależności oraz powszechną automatyzację instalacji pakietów. W poprzednich kampaniach obserwowano między innymi typosquatting, przejmowanie kont maintainerów, nadużywanie skryptów postinstall oraz pakiety wykradające sekrety chmurowe, tokeny npm i dane portfeli kryptowalutowych.

Nowy element tej kampanii polega na wykorzystaniu Ethereum jako warstwy pośredniej do przechowywania lub pozyskiwania informacji niezbędnych do dalszej komunikacji z malware. To podejście pokazuje, że operatorzy zagrożeń coraz częściej przenoszą część infrastruktury sterującej do środowisk trudniejszych do jednoznacznego sklasyfikowania jako złośliwe oraz mniej podatnych na szybkie wyłączenie.

Analiza techniczna

Mechanizm ataku najczęściej rozpoczyna się na etapie instalacji pakietu. W npm kluczowym wektorem są skrypty cyklu życia, takie jak preinstall, install i postinstall, które mogą uruchamiać kod automatycznie podczas standardowej instalacji zależności. Dzięki temu użytkownik lub proces CI może nie zauważyć momentu aktywacji złośliwego komponentu.

W analizowanym przypadku pakiet pełni funkcję loadera lub stagera. Zamiast zawierać pełny malware, uruchamia logikę odpowiedzialną za pobranie parametrów operacyjnych z zewnętrznego źródła. Ethereum może w takim modelu służyć jako nośnik danych transakcyjnych, repozytorium konfiguracji albo pośredni wskaźnik do kolejnego etapu infrastruktury. W praktyce umożliwia to operatorom ukrycie adresu C2 poza samym pakietem.

To podejście utrudnia wykrywanie regułami opartymi o statyczne IOC. Pakiet może wyglądać na niegroźny, a jego kod bywa minimalny, rozproszony między modułami lub dodatkowo zaciemniony. W części przypadków aktywacja następuje tylko w określonych warunkach, na przykład po sprawdzeniu systemu operacyjnego, nazwy hosta, zmiennych środowiskowych lub obecności narzędzi CI. Taka selekcja ofiar ogranicza szansę szybkiego wykrycia kampanii przez analityków.

Po uzyskaniu danych potrzebnych do dalszej komunikacji drugi etap ataku może realizować klasyczne cele: pobierać kolejny payload, wykonywać polecenia, wykradać sekrety, enumerować środowisko developerskie lub próbować uzyskać dostęp do kluczy prywatnych i danych portfeli. W organizacjach rozwijających rozwiązania Web3 szczególnie cenne dla napastników są pliki konfiguracyjne, zmienne .env, tokeny dostępowe oraz poświadczenia chmurowe i wydawnicze.

Konsekwencje / ryzyko

Ryzyko biznesowe takich incydentów jest wysokie, ponieważ atak uderza w zaufany element procesu wytwarzania oprogramowania. Kompromitacja pojedynczego pakietu może rozprzestrzenić się na wiele projektów przez zależności bezpośrednie i tranzytywne, a nietypowy sposób ukrycia C2 obniża skuteczność tradycyjnych kontroli bezpieczeństwa opartych wyłącznie na monitorowaniu ruchu do znanych domen lub adresów IP.

Dla firm działających w obszarze blockchain skutki mogą obejmować kradzież kluczy prywatnych, przejęcie portfeli, podpisanie złośliwych transakcji i utratę dostępu do zasobów on-chain. W środowiskach enterprise bardziej prawdopodobne są kradzież sekretów CI/CD, przejęcie tokenów repozytoryjnych, dostępów do chmury i możliwość dalszego ruchu bocznego. Jeśli atakujący zdobędzie poświadczenia publikacyjne, może rozwinąć incydent do pełnego kompromisu łańcucha dostaw.

Dodatkowym wyzwaniem pozostaje trwałość operacyjna kampanii. Jeżeli konfiguracja C2 jest pobierana dynamicznie, usunięcie pojedynczego wskaźnika kompromitacji nie gwarantuje neutralizacji zagrożenia. Konieczne jest pełne zrozumienie logiki inicjalizacji, zależności i artefaktów uruchomieniowych użytych przez pakiet.

Rekomendacje

Organizacje powinny traktować instalację pakietów npm jako operację uprzywilejowaną i zabezpieczać ją podobnie jak uruchamianie nieznanego kodu. Szczególnie ważna jest kontrola automatycznie wykonywanych skryptów instalacyjnych oraz przegląd pakietów, które rzeczywiście wymagają użycia preinstall lub postinstall.

Ograniczać lub audytować skrypty cyklu życia pakietów npm.
Skanować zależności pod kątem typosquattingu, obfuskacji, dynamicznego eval i prób pobierania kodu podczas instalacji.
Monitorować nietypowe połączenia wychodzące procesów node i npm w trakcie buildów.
Separować środowiska build oraz CI/CD od kluczy produkcyjnych i sekretów o wysokiej wartości.
Stosować krótkotrwałe poświadczenia, zasadę minimalnych uprawnień i menedżery sekretów.
Przygotować procedury reakcji obejmujące rotację sekretów, unieważnianie tokenów npm i weryfikację integralności artefaktów.

W środowiskach o wyższym poziomie dojrzałości bezpieczeństwa warto dodatkowo uruchamiać instalację zależności w odseparowanych workerach lub piaskownicach. Pozwala to ograniczyć skutki potencjalnej kompromitacji i lepiej obserwować zachowanie pakietu przed dopuszczeniem go do produkcyjnego procesu build.

Podsumowanie

Kampania pokazuje, że ataki na npm stają się coraz bardziej zaawansowane i odporne na klasyczne metody detekcji. Wykorzystanie Ethereum do ukrywania lub dostarczania parametrów C2 stanowi wyraźny sygnał, że ochrona łańcucha dostaw wymaga dziś analizy nie tylko kodu pakietu, ale także jego zachowania, zależności oraz powiązań z zewnętrzną infrastrukturą.

Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia kontroli poza samo skanowanie CVE. Skuteczna obrona wymaga nadzoru nad procesem pobierania, budowania i publikacji oprogramowania, a także stałej oceny ryzyka związanego z pakietami uruchamiającymi kod już na etapie instalacji.