Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Kampania GlassWorm weszła w nową fazę, w której napastnicy wykorzystują skradzione tokeny GitHub do przejmowania kont deweloperów i modyfikowania legalnych repozytoriów Python. To wyjątkowo groźny scenariusz dla bezpieczeństwa łańcucha dostaw oprogramowania, ponieważ złośliwy kod trafia bezpośrednio do domyślnych gałęzi projektów uznawanych wcześniej za zaufane.
W praktyce oznacza to, że programiści, systemy CI/CD oraz użytkownicy instalujący kod z repozytorium mogą nieświadomie uruchomić malware. Atak nie wymaga publikacji fałszywego pakietu pod nową nazwą — wystarczy przejęcie istniejącego źródła i nadpisanie jego historii.
W skrócie
Badacze opisali aktywną kampanię, w której zainfekowane konta GitHub służą do wymuszania zmian w repozytoriach Python za pomocą force-push. Napastnicy dopisują zaciemniony ładunek do plików takich jak setup.py, main.py oraz app.py, a następnie wykorzystują je jako loader do pobierania kolejnych komponentów malware.
- atak bazuje na skradzionych tokenach GitHub,
- złośliwy kod trafia do legalnych repozytoriów Python,
- modyfikacje są wpychane bez standardowego procesu code review,
- payload wykorzystuje techniki ukrywania i mechanizmy antyanalityczne,
- celem jest kradzież danych oraz aktywów kryptowalutowych.
Kontekst / historia
GlassWorm był wcześniej łączony z kampaniami wymierzonymi w środowiska programistyczne, w tym w złośliwe rozszerzenia dla narzędzi deweloperskich. W poprzednich odsłonach operatorzy koncentrowali się na kompromitacji kont wydawców lub kanałów dystrybucji dodatków, aby dostarczać loader malware bezpośrednio do deweloperów.
Obecna odmiana rozszerza ten model o przejmowanie kont GitHub i manipulację historią repozytoriów. Zamiast klasycznego ataku przez pull request lub publikację nowego wydania pakietu, napastnicy nadpisują historię domyślnej gałęzi, co utrudnia wykrycie incydentu i może sprawiać wrażenie legalnej aktywności.
Dodatkowo kampania wpisuje się w szerszy trend nadużyć wobec ekosystemu open source, gdzie coraz częściej celem staje się nie tylko sam pakiet, ale również konto maintenera, proces publikacji i integralność repozytorium.
Analiza techniczna
Łańcuch ataku rozpoczyna się od kompromitacji systemu dewelopera lub przejęcia jego sekretów. Wcześniejsze warianty GlassWorm miały kraść tokeny GitHub, co dawało operatorom możliwość modyfikowania wszystkich repozytoriów dostępnych z poziomu przejętego konta.
Po uzyskaniu dostępu napastnik wykonuje rebase legalnych commitów na domyślnej gałęzi i dopisuje zaciemniony kod do wybranych plików Pythona. Następnie używa force-push, aby opublikować zmiany i nadpisać historię w taki sposób, by ograniczyć widoczność manipulacji.
Szczególnie niebezpieczne jest zachowanie pozornie prawidłowych metadanych commitów. Oryginalne komunikaty, autor lub data autora mogą wyglądać wiarygodnie, przez co szybki przegląd historii nie musi ujawnić incydentu.
Sam payload ma postać zakodowaną, między innymi z użyciem Base64, i zawiera elementy utrudniające analizę. Jednym z obserwowanych mechanizmów jest sprawdzanie ustawień regionalnych systemu i pomijanie wykonania na hostach z konfiguracją rosyjską. Jeśli warunki zostaną spełnione, malware pobiera dane sterujące z pola memo transakcji powiązanego z portfelem Solana, wykorzystując nietypowy kanał C2 do dynamicznej aktualizacji kolejnego adresu pobrania.
Późniejsze etapy obejmują dostarczenie dodatkowych komponentów odpowiedzialnych za kradzież danych i zasobów kryptowalutowych. Taki model modułowy sprawia, że zainfekowane repozytorium pełni rolę nośnika początkowego loadera, a właściwa funkcjonalność malware może być zmieniana po stronie operatora.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem kampanii jest kompromitacja łańcucha dostaw oprogramowania. Zaufane repozytorium open source lub wewnętrzny projekt firmowy może stać się punktem wejścia do środowisk developerskich, pipeline’ów CI/CD, serwerów aplikacyjnych oraz stacji roboczych.
- kradzież poświadczeń i tokenów dostępowych,
- przejęcie portfeli kryptowalutowych,
- wyciek danych z przeglądarek i środowisk pracy,
- dalszy ruch boczny w infrastrukturze organizacji,
- opóźnione wykrycie z powodu legalnie wyglądającej historii Git.
Ryzyko jest szczególnie wysokie w przypadku projektów Python instalowanych bezpośrednio z repozytoriów, pakietów później publikowanych do zewnętrznych rejestrów oraz zespołów, które ufają integralności historii Git bez dodatkowej walidacji.
Rekomendacje
Organizacje oraz maintainerzy repozytoriów powinni traktować ten scenariusz jako incydent wysokiego ryzyka i wdrożyć zarówno zabezpieczenia prewencyjne, jak i mechanizmy detekcyjne.
- wymusić MFA dla wszystkich kont GitHub,
- ograniczyć stosowanie długowiecznych tokenów i regularnie je rotować,
- wdrożyć zasadę najmniejszych uprawnień dla tokenów, aplikacji i botów,
- zablokować force-push na domyślnych gałęziach wszędzie tam, gdzie nie jest konieczny,
- egzekwować branch protection, obowiązkowe przeglądy zmian i podpisywanie commitów,
- monitorować przepisywanie historii Git oraz nagłe zmiany w plikach
setup.py,main.pyiapp.py, - wykrywać zaciemniony kod, nietypowe ciągi Base64 i podejrzane wywołania sieciowe,
- audytować rozszerzenia IDE oraz skanować stacje deweloperskie pod kątem kradzieży sekretów,
- stosować weryfikację integralności artefaktów, pinning commitów i szybkie wycofywanie zaufania do przejętych źródeł.
W przypadku podejrzenia kompromitacji należy natychmiast unieważnić tokeny, przejrzeć powiązane repozytoria, porównać historię z lokalnymi klonami i zaufanymi mirrorami oraz odtworzyć integralny stan projektu z potwierdzonych źródeł.
Podsumowanie
Nowa odsłona GlassWorm pokazuje, że współczesne ataki na software supply chain coraz częściej uderzają bezpośrednio w konta deweloperów i historię repozytoriów, a nie tylko w same pakiety czy rejestry. Połączenie skradzionych tokenów GitHub, force-push na domyślne gałęzie i dynamicznego kanału sterowania opartego na danych z łańcucha Solana tworzy skuteczny i trudny do wykrycia model operacyjny.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że zaufanie do repozytorium nie może być traktowane jako stan trwały. Ochrona tokenów, kontrola rozszerzeń developerskich, walidacja integralności historii Git i monitoring krytycznych plików buildowych powinny stać się standardem w nowoczesnym procesie wytwarzania oprogramowania.
Źródła
- The Hacker News — GlassWorm Attack Uses Stolen GitHub Tokens to Force-Push Malware Into Python Repos — https://thehackernews.com/2026/03/glassworm-attack-uses-stolen-github.html
- Socket — GlassWorm Loader Hits Open VSX via Developer Account Compromise — https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise
- Aikido Security — The Return of the Invisible Threat: Hidden PUA Unicode Hits GitHub Repositories — https://www.aikido.dev/blog/the-return-of-the-invisible-threat-hidden-pua-unicode-hits-github-repositorties