Złośliwy pakiet npm indexed-btree ukrywał loader w kodzie uruchamianym dopiero w runtime

Wprowadzenie do problemu / definicja

Bezpieczeństwo łańcucha dostaw oprogramowania pozostaje jednym z największych wyzwań dla organizacji rozwijających aplikacje w oparciu o otwarte ekosystemy pakietów. Przypadek złośliwego pakietu indexed-btree pokazuje, że napastnicy odchodzą od dobrze znanych technik opartych na skryptach instalacyjnych i coraz częściej ukrywają szkodliwą logikę w kodzie wykonywanym dopiero podczas działania aplikacji.

To istotna zmiana, ponieważ wiele mechanizmów ochronnych koncentruje się na etapie npm install. Jeżeli złośliwe zachowanie aktywuje się dopiero po wywołaniu konkretnej funkcji bibliotecznej, detekcja staje się znacznie trudniejsza.

W skrócie

• Pakiet indexed-btree podszywał się pod legalną bibliotekę do pracy ze strukturami B-tree.
• Zamiast używać hooków preinstall lub postinstall, aktywował złośliwy ładunek dopiero w runtime.
• Loader miał być ukryty w metodzie BTree.prototype.set().
• Łańcuch infekcji obejmował profilowanie hosta, komunikację z infrastrukturą operatora i pobieranie dalszych komponentów.
• W kampanii wskazano również użycie technik powiązanych z EtherHiding.

Kontekst / historia

Ataki na ekosystem npm od lat bazują na podobnych schematach: publikacji pakietu o wiarygodnej nazwie, typosquattingu albo przejęciu zaufanego konta dewelopera. W klasycznym modelu złośliwy kod uruchamiał się automatycznie podczas instalacji zależności, co pozwalało szybko kompromitować stacje robocze i środowiska CI/CD.

W miarę jak rejestry pakietów i narzędzia bezpieczeństwa zaczęły skuteczniej wykrywać nadużycia związane z lifecycle scripts, operatorzy malware zaczęli przesuwać moment wykonania ataku. Zamiast aktywacji przy instalacji, infekcja następuje dopiero wtedy, gdy aplikacja rzeczywiście korzysta z określonej funkcji biblioteki. Taki model lepiej maskuje złośliwe działanie i utrudnia analizę statyczną.

Incydent z indexed-btree wpisuje się właśnie w ten trend. Pakiet wyglądał jak użyteczne narzędzie programistyczne, ale jego prawdziwa funkcja ujawniała się dopiero podczas normalnej pracy aplikacji.

Analiza techniczna

Z dostępnych ustaleń wynika, że indexed-btree naśladował zachowanie legalnych bibliotek związanych z indeksowaniem danych i strukturami B-tree. Kluczowa różnica polegała na osadzeniu szkodliwego mechanizmu w metodzie BTree.prototype.set(), czyli w miejscu, które może być naturalnie wywoływane przez aplikację bez wzbudzania podejrzeń.

Po aktywacji metoda miała uruchamiać komponent sharedLoad.min.js, zawierający zaciemniony pierwszy etap ładunku. Następnie uruchamiany był wieloetapowy łańcuch infekcji, którego celem było rozpoznanie środowiska, pobranie dalszych komponentów i utrudnienie analizy incydentu.

• Identyfikacja i fingerprinting hosta.
• Zbieranie informacji o środowisku uruchomieniowym.
• Komunikacja z kanałami kontrolowanymi przez operatora.
• Pobieranie zaszyfrowanych lub podzielonych na fragmenty komponentów.
• Scalanie dalszych etapów malware w pamięci lub lokalnie.
• Usuwanie artefaktów i modyfikacja kodu w celu zatarcia śladów.

Szczególnie niepokojącym elementem kampanii było powiązanie z techniką EtherHiding. W takim modelu część infrastruktury potrzebnej do sterowania atakiem lub przechowywania danych jest ukrywana z wykorzystaniem mechanizmów związanych z blockchainem, co utrudnia klasyczne blokowanie domen i serwerów C2.

Analizy sugerują również, że nie był to odosobniony przypadek, lecz element szerszej operacji obejmującej więcej niż jedną bibliotekę. To wskazuje na skoordynowane działania ukierunkowane na projekty JavaScript i Node.js.

Konsekwencje / ryzyko

Największe ryzyko wynika z faktu, że wiele zespołów koncentruje zabezpieczenia wyłącznie na etapie instalacji pakietów. Jeśli złośliwy kod nie uruchamia się podczas pobierania zależności, może ominąć część kontroli i aktywować się dopiero w środowisku deweloperskim, testowym lub buildowym.

• Kompromitacja stacji roboczych programistów.
• Wyciek metadanych hosta i informacji o środowisku.
• Pobranie dodatkowych ładunków w kolejnych etapach ataku.
• Ryzyko przeniknięcia do pipeline’ów CI/CD.
• Utrudnione dochodzenie po incydencie z powodu zaciemniania i autousuwania artefaktów.

Dla przedsiębiorstw oznacza to zagrożenie dla integralności całego procesu wytwarzania oprogramowania. Jeżeli zainfekowana biblioteka zostanie osadzona w obrazie builda, kontenerze lub środowisku testowym, skutki mogą objąć nie tylko pojedynczego dewelopera, ale również kolejne etapy publikacji aplikacji.

Rekomendacje

Organizacje korzystające z npm powinny rozszerzyć model ochrony poza sam etap instalacji zależności. W praktyce warto połączyć kontrolę statyczną, dynamiczną i behawioralną, a także objąć monitoringiem rzeczywiste użycie bibliotek w czasie działania aplikacji.

• Analizować biblioteki także w runtime, a nie tylko podczas instalacji.
• Monitorować nietypowe połączenia wychodzące ze środowisk developerskich i CI/CD.
• Stosować allowlisty pakietów oraz proces akceptacji nowych zależności.
• Weryfikować biblioteki pod kątem typosquattingu i funkcjonalnych imitacji.
• Łączyć SCA z analizą statyczną i dynamiczną na różnych etapach pipeline’u.
• Izolować środowiska deweloperskie od sekretów i zasobów produkcyjnych.
• Rejestrować wywołania procesów potomnych oraz próby pobierania dodatkowych payloadów.
• Wymuszać silne uwierzytelnianie dla maintainerów i kontrolować publikacje pakietów.
• Regularnie przeglądać także zależności pośrednie, nie tylko bezpośrednie.

Z perspektywy SOC i zespołów reagowania na incydenty ważne jest również budowanie detekcji pod zachowania charakterystyczne dla ataków supply chain, takie jak warunkowo ładowane skrypty, wieloetapowe payloady czy modyfikacje kodu po wykonaniu.

Podsumowanie

Incydent z indexed-btree pokazuje, że napastnicy aktywnie dostosowują techniki do nowych zabezpieczeń w ekosystemie npm. Odejście od skryptów instalacyjnych na rzecz aktywacji złośliwego kodu dopiero w runtime to ważna ewolucja ataków na łańcuch dostaw oprogramowania.

Dla obrońców oznacza to konieczność zmiany podejścia: bezpieczeństwo pakietów open source nie może być już oceniane wyłącznie przez pryzmat tego, co dzieje się podczas instalacji. Potrzebny jest model warstwowy, obejmujący ocenę biblioteki przed wdrożeniem, podczas jej działania oraz po uruchomieniu w środowisku organizacji.

Źródła

1. https://thehackernews.com/2026/09/malicious-npm-package-indexed-btree-hid.html
2. https://checkmarx.com/
3. https://www.npmjs.com/
4. https://sepolia.etherscan.io/