IronWorm i nowy wariant Miasma atakują npm. Rosnące zagrożenie dla łańcucha dostaw oprogramowania

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

Ekosystem npm po raz kolejny znalazł się w centrum zaawansowanych ataków na łańcuch dostaw oprogramowania. Badacze bezpieczeństwa opisali dwie powiązane kampanie — IronWorm oraz nowy wariant robaka Miasma — które wykorzystują zaufanie do legalnych pakietów i kont wydawców, aby dostarczać złośliwy kod do środowisk deweloperskich oraz potoków CI/CD.

To szczególnie niebezpieczny scenariusz, ponieważ złośliwe komponenty mogą aktywować się już podczas instalacji zależności. W praktyce oznacza to ryzyko nie tylko dla użytkowników końcowych, ale przede wszystkim dla deweloperów, systemów budowania i całego procesu publikacji artefaktów.

W skrócie

IronWorm był dystrybuowany przez skompromitowane konto npm i ukryty w legalnych pakietach jako złośliwe wydania.
Malware uruchamiał się za pomocą hooka instalacyjnego i kradł szeroki zakres sekretów oraz poświadczeń.
Nowy wariant Miasma wykorzystywał technikę „Phantom Gyp”, nadużywając pliku binding.gyp do uruchamiania kodu podczas instalacji.
Obie kampanie łączyły kradzież sekretów, manipulację workflow CI/CD oraz mechanizmy samoreplikacji.
Zagrożenie dotyczy nie tylko pojedynczych maszyn, ale całego łańcucha dostaw oprogramowania.

Kontekst / historia

Ataki supply chain wymierzone w npm nie są nowym zjawiskiem, ale obecna fala pokazuje wyraźną zmianę skali i technik działania. Zamiast prostego typosquattingu lub jednorazowego osadzenia backdoora w fałszywym pakiecie, napastnicy coraz częściej przejmują legalne konta wydawców, modyfikują zaufane namespace’y i automatycznie rozprzestrzeniają infekcję do kolejnych repozytoriów.

W przypadku Miasma wcześniejsze analizy wskazywały na kompromitację pakietów związanych z namespace’em Red Hat. Ustalenia sugerowały, że źródłem incydentu było przejęte konto GitHub, które posłużyło do wprowadzenia nieautoryzowanych zmian do repozytoriów organizacji utrzymującej pakiety. Nowa odsłona kampanii pokazuje, że robak może być szybko adaptowany do kolejnych kont i kanałów dystrybucji.

IronWorm wpisuje się w ten sam trend, ale idzie krok dalej. Zamiast prostego stealera mamy do czynienia z bardziej rozbudowaną platformą ofensywną ukierunkowaną na środowisko deweloperskie i proces publikacji oprogramowania.

Analiza techniczna

IronWorm był dostarczany jako złośliwa wersja legalnych pakietów opublikowanych z wykorzystaniem skompromitowanego konta npm. Łańcuch wykonania rozpoczynał się od hooka preinstall, który uruchamiał binarny ładunek napisany w Rust. Malware przeszukiwał system ofiary pod kątem sekretów, takich jak zmienne środowiskowe, konfiguracje chmurowe, dane Docker i Kubernetes, tokeny npm, klucze SSH, a także artefakty związane z narzędziami AI i asystentami kodowania.

Kluczowym elementem IronWorm była samoreplikacja. Po zdobyciu poświadczeń atakujący mogli modyfikować repozytoria, wstrzykiwać złośliwe commity i przygotowywać kolejne pakiety do publikacji. Badacze opisali również manipulacje workflow GitHub Actions, w których sekrety mogły być zapisywane do pozornie nieszkodliwych plików i eksportowane jako artefakty buildu. Taki model ogranicza potrzebę używania klasycznej infrastruktury C2 i utrudnia wykrywanie nietypowego ruchu sieciowego.

Dodatkowo IronWorm wykorzystywał komponent eBPF działający jak rootkit na poziomie jądra, co miało ukrywać procesy i utrudniać analizę. To znacząco podnosi poziom zaawansowania kampanii i pokazuje, że złośliwy pakiet npm może stać się narzędziem głębokiej kompromitacji systemu deweloperskiego lub runnera CI.

Nowy wariant Miasma zastosował odmienną ścieżkę wykonania. Zamiast klasycznych skryptów cyklu życia npm, atakujący użyli pliku binding.gyp, który uruchamiał kod za pośrednictwem node-gyp podczas npm install. To szczególnie groźne, ponieważ wiele polityk bezpieczeństwa koncentruje się na blokowaniu preinstall i postinstall, podczas gdy ta metoda może łatwo ominąć standardowe kontrole.

Po uruchomieniu Miasma pobierał środowisko Bun i wykorzystywał je do ładowania modułu przeznaczonego do masowego pozyskiwania sekretów. Zakres kradzieży obejmował poświadczenia do AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH oraz menedżerów haseł. Szczególnie niepokojąca była także zdolność do atakowania konfiguracji asystentów AI poprzez osadzanie trwałych plików backdoora w repozytoriach otwieranych w kompatybilnych środowiskach IDE.

W kampanii Miasma zaobserwowano również wykorzystanie publicznej infrastruktury GitHub do eksfiltracji danych i sterowania kolejnymi etapami infekcji. Taki model zmienia zaufaną usługę programistyczną w kanał komunikacyjny, który rzadko jest filtrowany lub blokowany w sieciach firmowych.

Konsekwencje / ryzyko

Skutki takich incydentów wykraczają daleko poza kompromitację pojedynczej stacji roboczej. Przejęcie tokenów npm, sekretów chmurowych, kluczy SSH lub poświadczeń do GitHub Actions może prowadzić do dalszej propagacji ataku na repozytoria źródłowe, rejestry pakietów, procesy wydawnicze i środowiska produkcyjne.

Najbardziej narażone są organizacje, które automatycznie instalują zależności bez rygorystycznej walidacji integralności, dopuszczają wykonywanie skryptów instalacyjnych i natywnych przebudów bez ograniczeń, przechowują długowieczne sekrety w CI/CD oraz nie stosują separacji uprawnień między deweloperami, runnerami i kontami publikacyjnymi.

Ryzyko ma charakter podwójny. Z jednej strony dochodzi do bezpośredniej utraty poufnych danych i dostępu. Z drugiej zainfekowany projekt może stać się wektorem dalszej dystrybucji malware do klientów, partnerów i kolejnych zespołów wewnętrznych.

Rekomendacje

Organizacje rozwijające oprogramowanie w ekosystemie Node.js powinny potraktować ten incydent jako wyraźny sygnał do natychmiastowego wzmocnienia bezpieczeństwa łańcucha dostaw.

Zweryfikować, czy w środowisku instalowano wskazane pakiety i złośliwe wersje.
Założyć możliwość wycieku poświadczeń i przeprowadzić pełną rotację tokenów npm, kluczy chmurowych, sekretów CI/CD, kluczy SSH oraz danych dostępowych do rejestrów.
Wyłączyć lub ściśle ograniczyć wykonywanie skryptów instalacyjnych.
Kontrolować użycie node-gyp i natywnych przebudów.
Pinować wersje zależności wraz z hashami integralności.
Wdrożyć prywatne proxy lub menedżery artefaktów z politykami blokującymi podejrzane wydania.
Wymusić krótkotrwałe tożsamości i federację zamiast długowiecznych sekretów.
Monitorować zmiany w workflow GitHub Actions oraz innych pipeline’ach buildowych.
Audytować projekty pod kątem nietypowych plików, takich jak binding.gyp, nowych hooków instalacyjnych, nieoczekiwanych binariów i zmian w konfiguracji narzędzi AI.

W środowiskach CI/CD warto także wdrożyć detekcje behawioralne dla nieautoryzowanych publikacji do npm, odczytów sekretów z pamięci runnerów, podejrzanych artefaktów buildów oraz zmian workflow pochodzących z kont o nietypowej historii aktywności.

Podsumowanie

IronWorm i nowy wariant Miasma potwierdzają, że ataki na npm weszły w fazę wysokiej dojrzałości operacyjnej. Napastnicy nie ograniczają się już do kradzieży sekretów, lecz aktywnie przejmują repozytoria, modyfikują pipeline’y, nadużywają mechanizmów publikacji i wdrażają funkcje robaków zdolnych do dalszego rozprzestrzeniania.

Najważniejszy wniosek jest prosty: tradycyjne zabezpieczenia skupione wyłącznie na skryptach preinstall i postinstall nie są już wystarczające. Środowiska deweloperskie i CI/CD należy dziś traktować jak zasoby krytyczne, ponieważ to właśnie tam coraz częściej rozpoczyna się realna kompromitacja łańcucha dostaw oprogramowania.