Wprowadzenie do problemu / definicja
Ekosystem npm od lat pozostaje jednym z głównych celów ataków na łańcuch dostaw oprogramowania. Najnowsza kampania pokazuje, że cyberprzestępcy szybko dostosowują swoje techniki do zmian w mechanizmach ochronnych i rezygnują z klasycznych skryptów instalacyjnych na rzecz aktywacji złośliwego kodu dopiero w czasie działania aplikacji.
To istotna zmiana taktyczna. W praktyce oznacza, że sam proces instalacji pakietu może wyglądać całkowicie poprawnie, a zagrożenie ujawnia się dopiero po zaimportowaniu biblioteki i wywołaniu określonej funkcji przez aplikację lub środowisko deweloperskie.
W skrócie
Badacze wykryli złośliwy pakiet indexed-btree, który podszywa się pod legalne narzędzie i uruchamia szkodliwy kod dopiero podczas normalnego użycia biblioteki. Dzięki temu omija część zabezpieczeń skoncentrowanych na etapie npm install.
- złośliwy kod ukryto w podstawowej metodzie biblioteki,
- malware zbiera dane o hoście i środowisku,
- eksfiltracja odbywa się m.in. przez Slack i Telegram,
- mechanizm C2 wykorzystuje smart contract w sieci Ethereum Sepolia,
- kampania objęła także inne pakiety powiązane z tym samym operatorem.
Kontekst / historia
W czerwcu 2026 roku zapowiedziano istotne zmiany bezpieczeństwa w npm v12, których celem było ograniczenie skuteczności ataków opartych na skryptach cyklu życia, takich jak preinstall, install i postinstall. Rozwiązanie miało utrudnić złośliwym pakietom automatyczne wykonywanie kodu już na etapie instalacji zależności.
Zmiany te były odpowiedzią na wcześniejsze incydenty, w których przestępcy wykorzystywali instalację pakietów do kradzieży tokenów, danych uwierzytelniających i informacji o środowisku deweloperskim. Nowa kampania pokazuje jednak, że zagrożenie nie zniknęło, lecz przeniosło się do kolejnej fazy działania aplikacji, gdzie wykrycie jest znacznie trudniejsze.
Analiza techniczna
W opisywanym przypadku złośliwy pakiet nie korzysta ze skryptów uruchamianych podczas instalacji. Zamiast tego loader osadzono w metodzie BTree.prototype.set(), czyli w funkcji wyglądającej na standardowy element pracy biblioteki. Taki zabieg pozwala uniknąć wzbudzania alarmów podczas pobierania i instalowania zależności.
Po spełnieniu odpowiednich warunków wykonywany jest kolejny komponent zawierający zaciemniony pierwszy etap malware. Taki model działania utrudnia analizę statyczną oraz wykrywanie oparte na prostych sygnaturach, ponieważ szkodliwa logika została wpleciona w pozornie legalny przepływ kodu aplikacji.
Po aktywacji malware wykonuje fingerprinting hosta. Zbiera informacje o architekturze systemu, nazwie hosta, procesorze, pamięci RAM oraz czasie pracy systemu. Następnie dane są przesyłane do zewnętrznych kanałów komunikacyjnych wykorzystywanych przez operatorów kampanii.
Na szczególną uwagę zasługuje warstwa dowodzenia i kontroli. Zamiast tradycyjnego serwera C2 malware odpytywał smart contract w sieci Ethereum Sepolia, aby pobrać dane konfiguracyjne. Następnie wykorzystywał wymianę kluczy X25519 do wyprowadzenia klucza AES i odszyfrowania drugiego etapu ładunku. Takie podejście utrudnia blokowanie infrastruktury i komplikuje szybkie unieszkodliwienie kampanii.
Badacze wskazali również, że operatorzy zadbali o wiarygodność projektu. Przygotowano przekonujące repozytorium, historię commitów i konta deweloperskie, co miało zwiększyć zaufanie potencjalnych ofiar. To coraz częstszy element współczesnych ataków supply chain, w których liczy się nie tylko skuteczność techniczna, ale również pozorna reputacja pakietu.
Do tej samej operacji przypisano także inne pakiety, w tym ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map oraz sliding-score-window. Skala pobrań sugeruje, że kampania mogła objąć znaczną liczbę środowisk deweloperskich i pipeline’ów buildowych.
Konsekwencje / ryzyko
Najważniejszy wniosek jest prosty: ochrona skoncentrowana wyłącznie na etapie instalacji nie jest już wystarczająca. Brak złośliwych skryptów install nie oznacza, że pakiet jest bezpieczny. Zagrożenie może ujawnić się dopiero po uruchomieniu określonej ścieżki wykonania.
Ryzyko dotyczy kilku obszarów jednocześnie. Po pierwsze, atakujący mogą pozyskać dane o środowisku i wykorzystać je do dalszego profilowania ofiary. Po drugie, jeśli pakiet działa w środowisku developerskim lub CI/CD, może stać się punktem wejścia do kradzieży sekretów, tokenów i poświadczeń. Po trzecie, wykorzystanie blockchaina jako elementu C2 zwiększa odporność kampanii na zakłócenie i utrudnia klasyczne działania obronne.
Dodatkowym zagrożeniem jest pozorna legalność takich pakietów. Sensowna nazwa, aktywność w repozytorium, realistyczna historia rozwoju i brak alarmujących zachowań przy instalacji mogą wywołać fałszywe poczucie bezpieczeństwa, zwłaszcza w organizacjach automatycznie aktualizujących zależności.
Rekomendacje
Organizacje korzystające z npm powinny rozszerzyć model ochrony poza sam moment instalacji. Niezbędne staje się monitorowanie rzeczywistego zachowania pakietów podczas ich użycia w środowiskach testowych, developerskich i buildowych.
- przeprowadzić inwentaryzację zależności i sprawdzić obecność wskazanych pakietów,
- potraktować ich wykrycie jako potencjalny incydent bezpieczeństwa,
- obrócić sekrety, tokeny i poświadczenia dostępne w zagrożonym środowisku,
- odtworzyć środowiska deweloperskie i buildowe z czystych, zaufanych obrazów,
- wdrożyć analizę runtime, sandboxing i monitoring połączeń wychodzących,
- stosować polityki allowlist dla zależności i kontrolę źródeł pakietów,
- ograniczyć uprawnienia środowisk CI/CD zgodnie z zasadą najmniejszych uprawnień,
- monitorować nietypowe połączenia do komunikatorów i niestandardowych źródeł konfiguracji,
- korzystać z nowych mechanizmów bezpieczeństwa dostępnych w nowszych wersjach npm.
Z perspektywy AppSec i DevSecOps warto uzupełnić ocenę pakietów o analizę reputacji maintainerów, historii publikacji, wzorców commitów oraz anomalii pojawiających się po zaimportowaniu biblioteki do projektu.
Podsumowanie
Opisana kampania potwierdza, że ataki na łańcuch dostaw JavaScript bardzo szybko adaptują się do nowych zabezpieczeń. Złośliwe pakiety npm nie muszą już polegać na skryptach instalacyjnych, aby uzyskać wykonanie kodu i ominąć część współczesnych mechanizmów ochronnych.
Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia uwagi z samego bezpiecznego procesu instalacji na pełną obserwowalność zależności w czasie działania. W praktyce to analiza runtime, segmentacja środowisk, kontrola zaufania do pakietów oraz rotacja sekretów stają się dziś fundamentem skutecznej ochrony przed nowoczesnymi kampaniami supply chain.
Źródła
- https://www.bleepingcomputer.com/news/security/malicious-npm-packages-evade-install-script-defenses-at-runtime/
- https://checkmarx.com/zero-post/npm-btree-malware-campaign-affects-millions-of-downloads-no-need-for-install-script/
- https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
- https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/