Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających i dostarczających aplikacje. Najnowsza kampania powiązana z malware Miasma pokazuje, że cyberprzestępcy coraz skuteczniej łączą kompromitację pakietów open source, kradzież tokenów publikacyjnych oraz nadużycie zaufanych mechanizmów automatyzacji w GitHub Actions.
W praktyce nie chodzi już wyłącznie o infekcję pojedynczej stacji roboczej. Celem staje się przejęcie tożsamości deweloperów, uzyskanie dostępu do sekretów CI/CD oraz trwałe osadzenie się w całym procesie tworzenia, budowania i publikacji oprogramowania.
W skrócie
W czerwcu 2026 roku badacze opisali kolejną odsłonę kampanii Miasma, łączonej z wcześniejszymi wariantami Mini Shai-Hulud i Hades. Złośliwe wersje objęły wiele pakietów npm, w tym komponenty powiązane z LeoPlatform i RStreams, a ślady aktywności zauważono także poza ekosystemem Node.js.
- Kampania koncentruje się na kradzieży sekretów, tokenów i poświadczeń maintainerów.
- Napastnicy wykorzystują zarówno złośliwe pakiety npm, jak i mechanizmy GitHub Actions.
- Atak może prowadzić do dalszej propagacji przez repozytoria, rejestry pakietów i pipeline’y CI/CD.
- Ryzyko obejmuje nie tylko host dewelopera, ale cały workflow dostarczania oprogramowania.
Kontekst / historia
Kampanie wymierzone w npm od lat wykorzystują ten sam fundament operacyjny: wysokie zaufanie do popularnych bibliotek, automatyzację instalacji oraz szerokie uprawnienia tokenów deweloperskich. W takim modelu przejęcie konta publikującego pakiety może bardzo szybko przełożyć się na dystrybucję złośliwych wersji do szerokiej grupy odbiorców.
Obecna fala nie wygląda na odosobniony incydent, lecz na kontynuację większej kampanii, która zmienia techniki operacyjne, ale zachowuje ten sam strategiczny cel. Operatorzy odświeżają wskaźniki kompromitacji, modyfikują łańcuch uruchomienia i zmieniają artefakty używane do komunikacji, aby utrudnić korelację zdarzeń oraz obniżyć skuteczność starszych reguł detekcyjnych.
Szczególnie istotne jest rozszerzenie aktywności na GitHub Actions. Oznacza to przejście z poziomu zależności aplikacyjnych na poziom automatyzacji buildów, release’ów i publikacji, czyli do obszaru o bardzo wysokim poziomie zaufania w nowoczesnych środowiskach DevOps.
Analiza techniczna
W opisywanej kampanii złośliwe pakiety npm nie ograniczały się do klasycznych skryptów lifecycle definiowanych w pliku package.json. Zamiast tego wykorzystywały plik binding.gyp, aby doprowadzić do wykonania arbitralnego kodu podczas instalacji. To istotna zmiana taktyczna, ponieważ część zespołów bezpieczeństwa koncentruje kontrole głównie na skryptach takich jak preinstall czy postinstall.
Kolejny etap łańcucha wykonania prowadził do uruchomienia loadera JavaScript, który pobierał i instalował środowisko Bun, jeżeli nie było obecne w systemie. Dopiero potem aktywowany był właściwy moduł stealera odpowiedzialny za przechwytywanie sekretów, tokenów i poświadczeń. Taki model zwiększa elastyczność operatorów, ułatwia podmianę payloadu i utrudnia prostą analizę statyczną.
Próbki zawierały również elementy antyanalityczne. Malware sprawdzał obecność narzędzi ochronnych na endpointach oraz korzystał z mechanizmu killswitch dla rosyjskiej lokalizacji systemu. Równolegle wdrażany był workflow o nazwie „Run Copilot”, którego zadaniem było pozyskanie sekretów środowiska CI/CD bezpośrednio z pamięci runnera.
To oznacza, że atak nie kończył się na stacji roboczej programisty. Celem była także eskalacja do środowisk automatyzacji, gdzie przechowywane są tokeny OIDC, sekrety publikacyjne, dane dostępowe do chmur oraz inne wrażliwe poświadczenia wykorzystywane podczas buildów i wdrożeń.
Istotnym elementem kampanii była również eksfiltracja danych z wykorzystaniem publicznych zasobów w GitHub jako infrastruktury pośredniej. Z perspektywy obrońcy jest to szczególnie niebezpieczne, ponieważ ruch do zaufanych usług deweloperskich bywa traktowany jako normalny i rzadziej wzbudza alerty.
Badacze powiązali kampanię także z incydentem dotyczącym GitHub Action codfish/semantic-release-action, gdzie złośliwy commit i przekierowanie tagów wersji prowadziły do uruchamiania payloadu w runnerach workflow. W takim scenariuszu malware wyszukuje tokeny GitHub, kradnie dane uwierzytelniające, szyfruje zebrany materiał i podejmuje próby dalszej propagacji do repozytoriów dostępnych z użyciem przejętych poświadczeń.
Na uwagę zasługuje również rozszerzenie schematu działania poza npm. W projekcie powiązanym z ekosystemem Go zaobserwowano podobny model wykonania, choć bez użycia binding.gyp. Wskazuje to, że napastnicy coraz wyraźniej atakują cały workflow deweloperski, a nie tylko pojedynczy menedżer pakietów.
Konsekwencje / ryzyko
Skutki takiej kompromitacji są wielowarstwowe. Po pierwsze, zagrożone są stacje robocze deweloperów, na których często znajdują się klucze dostępowe do chmury, tokeny publikacyjne, sekrety aplikacyjne i dane sesyjne. Po drugie, przejęcie sekretów runnera CI/CD może umożliwić modyfikację procesu buildu, podpisywania artefaktów i publikacji nowych wydań.
Jeszcze poważniejszym scenariuszem jest kompromitacja maintainera lub popularnego pakietu, która może przełożyć się na infekcję organizacji korzystających z danej biblioteki. W praktyce oznacza to możliwość masowego skażenia środowisk developerskich, zasobów chmurowych, systemów serverless i repozytoriów kodu źródłowego.
- Ryzyko rośnie w projektach korzystających z automatycznych aktualizacji zależności.
- Szczególnie narażone są środowiska z rozbudowaną automatyzacją release automation.
- Wysokie zagrożenie dotyczy także organizacji używających tokenów o zbyt szerokich uprawnieniach.
- Detekcję utrudnia zmienność artefaktów, znaczników operacyjnych i kanałów eksfiltracji.
Dodatkowym problemem jest to, że kampania nie opiera się na pojedynczym, łatwo wykrywalnym IOC. Tradycyjna detekcja sygnaturowa może okazać się niewystarczająca wobec elastycznych TTP i wykorzystania zaufanych usług deweloperskich jako elementu infrastruktury ataku.
Rekomendacje
Organizacje powinny rozpocząć od przeglądu wykorzystania wskazanych pakietów oraz wszystkich zależności pochodnych. Konieczne jest sprawdzenie historii buildów, lockfile, cache’y runnerów i logów publikacyjnych pod kątem nietypowych instalacji, zmian wersji oraz anomalii w procesie release.
Kolejnym krokiem powinna być natychmiastowa rotacja oraz unieważnienie tokenów npm, GitHub PAT, sekretów CI/CD, kluczy chmurowych i innych poświadczeń, które mogły być dostępne na zainfekowanych hostach lub runnerach. Szczególną uwagę należy poświęcić tokenom z uprawnieniami publikacyjnymi, administracyjnymi i dostępem do repozytoriów prywatnych.
- Stosować zasadę najmniejszych uprawnień dla tokenów workflow.
- Chronić tagi i branche wykorzystywane przez GitHub Actions.
- Wymuszać zatwierdzanie zmian w workflow.
- Izolować runnerów i skracać czas życia środowisk wykonawczych.
- Skanować zależności oraz artefakty przed użyciem w buildzie.
Od strony developerskiej warto monitorować nietypowe pliki wykonywalne i konfiguracje w repozytoriach, a nie tylko wpisy w package.json. Mechanizmy detekcyjne powinny obejmować również binding.gyp, skrypty bootstrapujące, konfiguracje IDE oraz pliki inicjujące narzędzia wspierające programistów.
W działaniach huntingowych warto uwzględnić:
- uruchomienia Bun w nieoczekiwanych kontekstach,
- modyfikacje workflow GitHub Actions,
- dostęp do pamięci runnerów,
- niestandardowe próby pobierania lub publikacji do repozytoriów GitHub,
- nagłe publikacje wielu wersji pakietów w bardzo krótkim czasie.
Podsumowanie
Kampania Miasma potwierdza, że współczesne ataki na łańcuch dostaw coraz rzadziej ograniczają się do prostego zatrucia pojedynczego pakietu. Napastnicy łączą przejęcie tożsamości maintainerów, złośliwe aktualizacje zależności, nadużycie GitHub Actions oraz kradzież sekretów z pamięci runnerów, budując skalowalny model dalszej propagacji.
Najważniejszy wniosek dla zespołów bezpieczeństwa i DevSecOps jest jednoznaczny: ochrona samego menedżera pakietów już nie wystarcza. Zabezpieczenia muszą obejmować cały workflow deweloperski — od stacji roboczej, przez IDE i automatyzację, po pipeline CI/CD, rejestry pakietów i proces publikacji.
Źródła
- The Hacker News — Miasma Malware Targets npm Packages and GitHub Actions in Supply Chain Attack — https://thehackernews.com/2026/06/miasma-malware-targets-npm-packages-and.html
- Socket — research and analysis referenced in the incident coverage — https://socket.dev
- StepSecurity — analysis of malicious GitHub Actions activity — https://www.stepsecurity.io
- JFrog Security Research — supply chain threat research related to the campaign — https://research.jfrog.com
- Endor Labs — software supply chain security research and analysis — https://www.endorlabs.com