Kopie robaka Shai-Hulud atakują npm po wycieku kodu źródłowego

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Wyciek kodu źródłowego złośliwego oprogramowania często prowadzi do szybkiego pojawienia się nowych wariantów i kampanii naśladowczych. Taki scenariusz obserwujemy obecnie w ekosystemie npm, gdzie po ujawnieniu kodu robaka Shai-Hulud zaczęły pojawiać się pakiety zawierające jego klony lub uproszczone wersje, ukierunkowane na przejęcie sekretów deweloperskich oraz dalszą propagację w łańcuchu dostaw oprogramowania.

Shai-Hulud to malware typu worm wykorzystywane w atakach supply chain przeciwko społeczności open source. Jego głównym celem jest kradzież poświadczeń, tokenów publikacyjnych, kluczy API i innych sekretów z maszyn deweloperskich, a następnie użycie przejętych kont do publikowania kolejnych zainfekowanych paczek.

W skrócie

Po wycieku kodu źródłowego Shai-Hulud pojawiły się aktywne kopie malware w rejestrze npm.
Atakujący publikowali złośliwe pakiety przeznaczone do kradzieży tokenów, kluczy API i innych sekretów.
Część kampanii wykorzystywała typo-squatting, podszywając się pod znane biblioteki.
Jeden z wariantów miał dodatkowo próbować wykorzystywać zainfekowane systemy do działań DDoS.
Incydent zwiększa ryzyko kolejnych ataków supply chain wymierzonych w deweloperów i pipeline’y CI/CD.

Kontekst / historia

Pierwsze publiczne informacje o aktywności Shai-Hulud pojawiły się we wrześniu 2025 roku, kiedy zagrożenie powiązano z atakami na otwarty ekosystem pakietów. W kolejnych miesiącach malware był łączony z kompromitacją licznych pakietów npm, co mogło oddziaływać na szeroką grupę deweloperów oraz środowisk automatycznego budowania i wdrażania oprogramowania.

Istotnym momentem eskalacji było powiązanie kampanii z grupą TeamPCP. Następnie doszło do krótkotrwałego ujawnienia repozytoriów zawierających pełny kod źródłowy Shai-Hulud. Taki wyciek znacząco obniżył próg wejścia dla mniej zaawansowanych aktorów zagrożeń, którzy zamiast tworzyć własne narzędzia mogli po prostu zaadaptować gotowy kod do własnych operacji.

W efekcie zagrożenie przestało być problemem związanym wyłącznie z jedną grupą i zaczęło funkcjonować jako model ataku możliwy do łatwego powielania. To szczególnie niebezpieczne w ekosystemach opartych na automatycznym pobieraniu zależności, gdzie pojedyncza pomyłka w nazwie pakietu może doprowadzić do uruchomienia złośliwego kodu.

Analiza techniczna

Z technicznego punktu widzenia Shai-Hulud należy do klasy malware atakującego software supply chain poprzez przejęcie zaufanych kanałów dystrybucji. Po instalacji złośliwego pakietu robak koncentruje się na pozyskaniu wrażliwych danych z systemu ofiary, a następnie na ich eksfiltracji do infrastruktury kontrolowanej przez operatora kampanii.

Najczęściej celem są:

tokeny publikacyjne npm,
poświadczenia do repozytoriów kodu,
klucze API,
sekrety środowisk chmurowych,
dane uwierzytelniające używane w CI/CD.

Według analiz jednym z wykrytych wariantów był pakiet „chalk-tempalte”, który zachowywał kluczowe elementy działania oryginalnego Shai-Hulud, w tym mechanizm przesyłania przejętych poświadczeń do nowej infrastruktury kontrolowanej przez atakującego. Oznacza to, że nawet uproszczone kopie malware mogą zachować najbardziej niebezpieczne funkcje pierwotnej kampanii.

Atakujący wykorzystywali także typo-squatting, publikując pakiety o nazwach łudząco podobnych do legalnych bibliotek. Wśród zidentyfikowanych nazw znalazły się między innymi:

@deadcode09284814/axios-util,
axois-utils,
chalk-tempalte,
color-style-utils.

Tego typu nazwy bazują na typowych literówkach, przestawieniu znaków lub zastosowaniu ogólnych członów brzmiących wiarygodnie. To technika szczególnie skuteczna w środowiskach deweloperskich, gdzie instalacja zależności bywa wykonywana szybko i bez pełnej weryfikacji autora, historii pakietu czy zawartości skryptów instalacyjnych.

Szczególnie niepokojący jest fakt, że jeden z wykrytych pakietów miał nie tylko kraść sekrety, ale również próbować włączać zainfekowane systemy do botnetu DDoS. Wskazuje to na testowanie różnych modeli monetyzacji — od przejmowania kont maintainerskich, przez kradzież dostępu do środowisk chmurowych, po wykorzystywanie zasobów ofiar do operacji zakłócających.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko związane z kopiami Shai-Hulud wynika ze skali i szybkości replikacji tego modelu ataku. Po upublicznieniu kodu źródłowego nie trzeba już dysponować dużym doświadczeniem w tworzeniu malware, aby uruchomić kampanię wymierzoną w deweloperów npm. Wystarczą podstawowe modyfikacje kodu, własna infrastruktura odbioru danych i odpowiednio dobrane nazwy pakietów.

Dla organizacji rozwijających oprogramowanie skutki mogą być bardzo poważne. Kompromitacja jednej stacji deweloperskiej może prowadzić do przejęcia tokenów publikacyjnych, naruszenia kont maintainerskich, modyfikacji legalnych pakietów, wycieku sekretów środowiskowych, naruszenia pipeline’ów CI/CD oraz dalszego rozprzestrzeniania incydentu na klientów i partnerów.

Z perspektywy bezpieczeństwa łańcucha dostaw jest to klasyczny przykład zagrożenia, w którym zaufanie do rejestru pakietów i automatyzacji buildów staje się wektorem wejścia. Ryzyko dodatkowo rośnie, gdy atakujący łączą kilka technik jednocześnie: typo-squatting, kradzież sekretów, publikację złośliwych aktualizacji i wtórne wykorzystanie przejętych zasobów.

Rekomendacje

Zespoły bezpieczeństwa i organizacje rozwijające oprogramowanie powinny potraktować ten incydent jako sygnał do zaostrzenia kontroli nad zależnościami oraz poświadczeniami używanymi w procesie wytwarzania oprogramowania.

Weryfikować nowe pakiety przed instalacją, zwłaszcza pod kątem autora, historii publikacji i podobieństwa nazwy do popularnych bibliotek.
Monitorować rejestry pakietów pod kątem typo-squattingu, podejrzanych skryptów instalacyjnych i nietypowych zmian maintainerów.
Ograniczać użycie długowiecznych tokenów i tam, gdzie to możliwe, korzystać z mechanizmów trusted publishing.
Wymuszać 2FA dla kont maintainerskich i administracyjnych odpowiedzialnych za publikację pakietów.
Regularnie rotować i segmentować sekrety, w tym tokeny npm, klucze API i poświadczenia do repozytoriów.
Prowadzić inspekcję stacji deweloperskich oraz runnerów buildów pod kątem oznak eksfiltracji danych i nietypowego ruchu sieciowego.
Wdrożyć polityki dopuszczania zależności oraz listy zatwierdzonych źródeł i wersji pakietów.
Analizować logi publikacji i zmian w pakietach, aby szybko wykrywać nieautoryzowane działania.

Podsumowanie

Pojawienie się kopii Shai-Hulud po wycieku kodu źródłowego potwierdza znany mechanizm eskalacji zagrożeń w cyberprzestrzeni: gdy skuteczne narzędzie trafia do szerszego obiegu, szybko zaczyna być adaptowane przez kolejnych aktorów. W tym przypadku celem pozostaje ekosystem npm oraz szeroko rozumiany software supply chain.

Największym problemem nie jest wyłącznie sam malware, lecz łatwość jego ponownego użycia, połączenie z typo-squattingiem oraz koncentracja na sekretach deweloperskich i kontach maintainerskich. Obrona przed podobnymi kampaniami wymaga jednoczesnego wzmacniania kontroli tożsamości, higieny sekretów, monitorowania zależności i szybkiego reagowania na anomalie w procesie publikacji oprogramowania.