Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem npm po raz kolejny znalazł się w centrum poważnego incydentu typu software supply chain. Najnowsza kampania, powiązana z rodziną malware Shai-Hulud, polega na publikowaniu złośliwych wersji legalnie wyglądających pakietów, które następnie trafiają do środowisk deweloperskich i pipeline’ów CI/CD w ramach zwykłego procesu instalacji zależności.
To szczególnie niebezpieczny scenariusz, ponieważ atakujący nie muszą przełamywać klasycznych mechanizmów ochrony na stacjach roboczych czy serwerach. Wystarczy, że złośliwy kod zostanie osadzony w bibliotece pobieranej z zaufanego rejestru, a następnie uruchomi się w kontekście dewelopera lub automatycznego procesu budowania.
W skrócie
- Nowa fala kampanii Shai-Hulud objęła setki pakietów npm w bardzo krótkim czasie.
- Atak był silnie skoncentrowany na ekosystemie @antv, ale nie ograniczał się wyłącznie do niego.
- Malware kradnie sekrety deweloperskie i CI/CD, w tym tokeny GitHub, npm, dane chmurowe, klucze SSH i poświadczenia do baz danych.
- Wykradzione dane są szyfrowane i eksfiltrowane przez sieć Session P2P, a czasem także publikowane w repozytoriach GitHub tworzonych na kontach ofiar.
- Kampania ma cechy samorozprzestrzeniania się dzięki przejętym tokenom publikacyjnym.
- Niepokojącym elementem jest także generowanie wiarygodnie wyglądających attestation związanych z pochodzeniem artefaktów.
Kontekst / historia
Shai-Hulud nie jest nowym zagrożeniem, lecz rozwijającą się kampanią, którą badacze obserwują od 2025 roku. W poprzednich odsłonach incydenty dotyczyły innych popularnych bibliotek i wskazywały, że malware działa jak robak zdolny do dalszego infekowania pakietów po przejęciu tokenów maintainerów lub poświadczeń publikacyjnych.
W najnowszej fali punktem wyjścia była kompromitacja konta odpowiedzialnego za publikację pakietów w przestrzeni nazw @antv. Następnie w krótkim oknie czasowym opublikowano dużą liczbę złośliwych wersji, co sugeruje wysoki poziom automatyzacji operacji. Skala problemu jest znacząca, ponieważ dotknięte biblioteki są szeroko wykorzystywane w projektach frontendowych, wizualizacji danych oraz aplikacjach biznesowych.
Analiza techniczna
Mechanizm ataku opiera się na wstrzyknięciu złośliwego kodu do legalnych pakietów npm. Ładunek był osadzany głównie w pliku index.js i dodatkowo zaciemniany, aby utrudnić analizę statyczną oraz szybkie wykrycie podczas przeglądu zmian. Po uruchomieniu malware rozpoczyna enumerację środowiska i poszukiwanie wartościowych sekretów.
Złośliwe pakiety celują w szeroki zakres danych, takich jak tokeny GitHub i npm, zmienne środowiskowe platform CI/CD, poświadczenia do usług chmurowych, konfiguracje Kubernetes, sekrety Vault, ustawienia Dockera, dane dostępowe do baz danych oraz klucze SSH. Szczególnie istotne jest to, że kampania została przygotowana z myślą o środowiskach automatyzacji budowania i publikacji, gdzie dostępne są uprzywilejowane sekrety oraz tokeny o wysokiej wartości operacyjnej.
Eksfiltracja danych została zaprojektowana w sposób utrudniający klasyczną detekcję sieciową. Skradzione informacje są serializowane, kompresowane, szyfrowane symetrycznie, a następnie dodatkowo opakowywane kryptograficznie przed wysyłką. Głównym kanałem wycieku jest infrastruktura oparta na Session P2P, co ogranicza skuteczność tradycyjnego blokowania ruchu na podstawie domen czy adresów IP.
Jeżeli malware uzyska dostęp do poświadczeń GitHub, potrafi tworzyć nowe repozytoria na koncie ofiary i przesyłać tam wykradzione dane jako alternatywny kanał eksfiltracji. To oznacza, że kompromitacja nie kończy się na samym wycieku sekretów, lecz może obejmować również nadużycia w ekosystemie kodu źródłowego i automatyzacji.
Jednym z najbardziej alarmujących elementów tej kampanii jest nadużycie tokenów OIDC przejętych ze środowisk CI do generowania pozornie poprawnych Sigstore provenance attestations. W praktyce złośliwe pakiety mogą wyglądać na poprawnie podpisane i zgodne z wymaganiami łańcucha dostaw, mimo że zawierają szkodliwy kod. To podważa zaufanie do modeli bezpieczeństwa opartych wyłącznie na podpisach i provenance bez głębszej analizy zawartości artefaktów.
Kampania wykazuje również cechy samoreplikacji. Po przejęciu tokenów npm malware może sprawdzać ich ważność, identyfikować pakiety należące do ofiary, pobierać ich archiwa, wstrzykiwać własny kod i publikować nowe zainfekowane wersje z podniesionym numerem wydania. Część analiz wskazuje również na próby utrwalania obecności poprzez modyfikacje konfiguracji narzędzi developerskich.
Konsekwencje / ryzyko
Ryzyko związane z tą falą ataków jest bardzo wysokie. Kompromitacja zależności npm może prowadzić do wycieku sekretów z maszyn deweloperskich, runnerów CI/CD i systemów produkcyjnych, a przejęte tokeny publikacyjne umożliwiają dalsze rozprzestrzenianie się zagrożenia na kolejne biblioteki i organizacje.
Dla firm korzystających z dotkniętych pakietów skutki mogą obejmować przejęcie repozytoriów kodu, nieautoryzowane publikacje, kompromitację infrastruktury chmurowej, utratę kluczy SSH oraz wtórne incydenty wynikające z dalszego ruchu bocznego napastników. Szczególnie narażone są środowiska, które automatycznie pobierają najnowsze wersje zależności bez rygorystycznego pinowania wersji i bez kontroli zmian między wydaniami.
Dodatkowym problemem pozostaje fałszywe poczucie bezpieczeństwa wynikające z obecności wiarygodnie wyglądających attestation. Jeśli organizacja traktuje podpisane provenance jako jedyny wskaźnik zaufania, może nie wykryć złośliwej aktualizacji odpowiednio wcześnie.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy podejrzane wersje pakietów zostały zainstalowane w środowiskach deweloperskich, buildach lub produkcji. Jeśli tak, należy natychmiast usunąć złośliwe wydania albo wycofać się do znanej, zaufanej wersji opublikowanej przed incydentem.
Równolegle trzeba założyć kompromitację wszystkich sekretów obecnych w systemie podczas instalacji lub użycia pakietu. Oznacza to konieczność rotacji tokenów GitHub i npm, kluczy SSH, sekretów chmurowych, danych CI/CD, poświadczeń do rejestrów i baz danych oraz innych danych uwierzytelniających dostępnych w środowisku.
- Wymusić pinowanie wersji zależności i ograniczyć automatyczne aktualizacje krytycznych bibliotek.
- Rozdzielić procesy build i publish oraz stosować zasadę minimalnych uprawnień.
- Ograniczyć zaufanie do samych podpisów i provenance, uzupełniając je analizą behawioralną pakietów.
- Monitorować nietypowe użycie GitHub API, tworzenie nowych repozytoriów i nagłe serie publikacji pakietów.
- Przeanalizować historię wydań oraz aktywność kont maintainerów pod kątem nieautoryzowanych zmian.
- Wdrożyć lepszą ochronę workflow CI/CD, w tym krótkotrwałe tokeny i kontrolę nadużyć OIDC.
Podsumowanie
Nowa fala Shai-Hulud pokazuje, że ataki na łańcuch dostaw oprogramowania w npm stają się coraz bardziej zautomatyzowane, skalowalne i trudniejsze do wykrycia. Zagrożenie nie ogranicza się do pojedynczego pakietu, lecz obejmuje masową kompromitację bibliotek, kradzież sekretów, trudną do wykrycia eksfiltrację danych oraz możliwość dalszego samorozprzestrzeniania się.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że zaufanie do rejestru pakietów, podpisów i deklarowanego pochodzenia artefaktów nie może być bezwarunkowe. Ochrona software supply chain wymaga dziś podejścia wielowarstwowego, obejmującego kontrolę publikacji, ochronę CI/CD, monitoring zachowania zależności i szybką reakcję na każdy sygnał kompromitacji.
Źródła
- New Shai-Hulud malware wave compromises 600 npm packages — https://www.bleepingcomputer.com/news/security/new-shai-hulud-malware-wave-compromises-600-npm-packages/
- Mini Shai-Hulud Returns: 42 Malicious npm Packages Fake Sigstore Badges in AntV Ecosystem Attack — https://www.endorlabs.com/learn/mini-shai-hulud-returns-42-malicious-npm-packages-fake-sigstore-badges-in-antv-ecosystem-attack
- Shai-Hulud Returns: npm Worm hits @antv in latest ongoing campaign — https://research.jfrog.com/post/shai-hulud-here-we-go-again-may19/
- A Mini Shai-Hulud Has Appeared — https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared