CrowdStrike, we współpracy z Google i Shadowserver Foundation, ogłosił skoordynowane przerwanie działania infrastruktury dowodzenia i kontroli (C2) używanej przez GlassWorm, uporczywą kampanię ataku na łańcuch dostaw oprogramowania, wymierzoną w deweloperów za pośrednictwem złośliwych pakietów i rozszerzeń edytorów kodu.
Operacja jednocześnie unieszkodliwiła wszystkie znane kanały dowodzenia i kontroli GlassWorm, uniemożliwiając zainfekowanym maszynom otrzymywanie nowych instrukcji lub dodatkowych ładunków.
Przerwanie działania infrastruktury ma duże znaczenie, ponieważ GlassWorm nie był prostą kampanią złośliwego oprogramowania. Była to odporna, wielowarstwowa operacja zaprojektowana, by kompromitować środowiska deweloperskie, kraść poświadczenia, zatruwać repozytoria i wykorzystywać zainfekowane maszyny jako ukrytą infrastrukturę do dalszych ataków.
Deweloperzy nadal są cennym celem
Co najmniej od początku 2025 roku operatorzy GlassWorm skupiali się w dużej mierze na twórcach oprogramowania.
To celowanie jest strategiczne.
Maszyny deweloperów często mają dostęp do:
- repozytoriów kodu źródłowego
- rejestrów pakietów npm i Python
- tokenów do publikowania w VS Code i Open VSX
- poświadczeń GitHub
- platform chmurowych
- potoków CI/CD
- portfeli kryptowalut
- kluczy SSH
- systemów wewnętrznych i środowisk budowania
Pojedyncza skompromitowana stacja robocza dewelopera może mieć znacznie większy wpływ niż typowe zainfekowane urządzenie końcowe. Atakujący mogą być w stanie publikować złośliwe pakiety, kompromitować repozytoria, uzyskiwać dostęp do infrastruktury chmurowej lub wstrzykiwać backdoory do narzędzi używanych przez tysiące użytkowników końcowych.
Dlatego ataki na łańcuch dostaw oprogramowania wciąż rosną w siłę. Kompromitacja ludzi i systemów, które wytwarzają oprogramowanie, może dać ogromny zasięg w dalszej części łańcucha.
Jak rozprzestrzeniał się GlassWorm
GlassWorm stosował wielotorowe podejście, aby dotrzeć do deweloperów.
Kampania opierała się na trojanizowanych rozszerzeniach VS Code publikowanych zarówno w Microsoft VS Code Marketplace, jak i w Open VSX. Pozwalało to atakującym celować nie tylko w użytkowników Visual Studio Code, ale także w użytkowników edytorów opartych na VS Code i ich forków, takich jak:
- Cursor
- Positron
- Windsurf
- VSCodium
Kampania wprowadzała też złośliwy kod przez skompromitowane pakiety npm i Python.
Dzięki tej kombinacji GlassWorm miał kilka ścieżek dystrybucji w ekosystemie deweloperskim. Zamiast polegać na jednym marketplace lub jednym repozytorium pakietów, operatorzy atakowali jednocześnie wiele zaufanych kanałów deweloperskich.
Co robiło złośliwe oprogramowanie
GlassWorm dostarczał framework do kradzieży danych, skoncentrowany na poświadczeniach deweloperów i kompromitacji systemów.
Jego możliwości obejmowały:
- zbieranie poświadczeń
- kradzież portfeli kryptowalut
- profilowanie systemu
- kradzież danych z przeglądarek
- wykonywanie dowolnego kodu
- przechwytywanie zrzutów ekranu
- rejestrowanie naciśnięć klawiszy
- monitorowanie schowka
- zdalny dostęp
- przekierowywanie ruchu przez zainfekowane maszyny (proxy)
Późniejsze wersje wdrażały oparty na WebSocket JavaScriptowy RAT znany jako GlassWormRAT. To narzędzie zdalnego dostępu mogło kraść dane z przeglądarek, uruchamiać dowolny kod i instalować złośliwe rozszerzenie Google Chrome, aby zbierać wrażliwe informacje z zainfekowanego systemu.
Po uaktywnieniu GlassWorm wyszukiwał poświadczenia deweloperów, takie jak tokeny GitHub, npm i OpenVSX, oraz dane portfeli kryptowalut.
Skradzione poświadczenia mogły następnie posłużyć do kompromitowania kolejnych repozytoriów, publikowania zatrutych pakietów lub dalszego rozprzestrzeniania kampanii.
Zamienianie maszyn deweloperów w infrastrukturę
Jednym z najbardziej niepokojących elementów GlassWorm była jego zdolność do przekształcania zainfekowanych systemów deweloperskich w ukrytą infrastrukturę.
Według analiz badaczy bezpieczeństwa skompromitowane hosty mogły być używane jako:
- proxy SOCKS
- ukryte serwery VNC
- węzły zdalnego wykonywania kodu
- punkty dostępu oparte na WebRTC
- środowiska wykonawcze Node.js
Dawało to atakującym zanonimizowany dostęp do sieci korporacyjnych i prywatnych.
Innymi słowy, zainfekowane systemy były nie tylko ofiarami. Stawały się zasobami operacyjnymi, które mogły wspierać dalszą kompromitację, przemieszczanie się po sieci i ukrywanie aktywności atakujących.
To czyni GlassWorm groźniejszym niż zwykły złodziej poświadczeń.
Ponad 300 repozytoriów GitHub zatrutych
Dzięki skradzionym poświadczeniom deweloperów aktywność GlassWorm zatruła według doniesień ponad 300 repozytoriów GitHub.
To kluczowe ryzyko dla łańcucha dostaw.
Jeśli atakujący zdobędą dostęp do konta GitHub dewelopera lub tokenów do publikowania pakietów, mogą modyfikować zaufany kod, publikować złośliwe wydania lub wprowadzać subtelne backdoory, które użytkownicy końcowi później zainstalują.
Skutki mogą rozprzestrzenić się daleko poza pierwotną ofiarę. Skompromitowane konto dewelopera może stać się punktem wyjścia ataków na wiele organizacji, które zależą od kodu, pakietów lub rozszerzeń tego dewelopera.
Cztery kanały dowodzenia i kontroli
GlassWorm wyróżniał się niezwykle odporną konstrukcją dowodzenia i kontroli.
Zamiast polegać na jednym serwerze lub domenie, złośliwe oprogramowanie używało czterech różnych kanałów rozpoznawania C2:
- Blockchain Solana
Operatorzy przechowywali adresy serwerów C2 w polach memo transakcji blockchain, wykorzystując blockchain jako dead drop resolver. - BitTorrent DHT
Złośliwe oprogramowanie odpytywało sieć peer-to-peer BitTorrent Distributed Hash Table, aby pobrać dane konfiguracyjne. - Google Calendar
GlassWorm używał tytułów wydarzeń w Google Calendar jako sposobu na pobieranie adresów serwerów C2. - Komercyjna infrastruktura VPS
Złośliwe oprogramowanie mogło też łączyć się bezpośrednio z serwerami C2 hostowanymi u komercyjnych dostawców wirtualnych serwerów prywatnych.
Ta konstrukcja utrudniała zakłócenie operacji. Jeśli obrońcy zablokowali jeden kanał, zainfekowane maszyny mogły potencjalnie pobrać instrukcje innym kanałem.
Skoordynowana likwidacja była więc ważna, ponieważ wszystkie cztery kanały zostały zakłócone w tym samym czasie.
Dlaczego likwidacja ma znaczenie
Infrastruktura dowodzenia i kontroli to sposób, w jaki operatorzy złośliwego oprogramowania zarządzają zainfekowanymi maszynami.
Zakłócając kanały C2 GlassWorm, CrowdStrike, Google i Shadowserver uniemożliwiły skompromitowanym systemom otrzymywanie nowych poleceń, konfiguracji lub ładunków.
Nie oczyszcza to automatycznie zainfekowanych systemów, ale osłabia zdolność atakujących do ich kontrolowania.
Skoordynowany charakter operacji ma znaczenie, ponieważ GlassWorm zbudowano z myślą o odporności. Częściowa likwidacja mogłaby pozwolić operatorom przejść na kanały zapasowe. Jednoczesne unieszkodliwienie wszystkich znanych ścieżek C2 zmniejsza taką szansę.
Atrybucja i profil operatorów
CrowdStrike opisał operatorów GlassWorm jako dysponujących dużymi zasobami i uporczywych.
Aktywność przypisano prawdopodobnie cyberprzestępcom z Rosji na podstawie wskaźników takich jak:
- zatrzymywanie wykonywania złośliwego oprogramowania w systemach znajdujących się w krajach Wspólnoty Niepodległych Państw
- komentarze w języku rosyjskim w komponentach złośliwego oprogramowania
- zachowanie operacyjne zgodne z cyberprzestępczością motywowaną finansowo
Kampania wydaje się mieć głównie charakter przestępczy, a nie wyłącznie szpiegowski, ale jej wpływ na łańcuch dostaw oprogramowania czyni ją poważnym zagrożeniem dla organizacji każdej wielkości.
Dlaczego ataki na łańcuch dostaw oprogramowania są tak niebezpieczne
GlassWorm pokazuje, dlaczego łańcuch dostaw oprogramowania jest jedną z najważniejszych powierzchni ataku we współczesnym cyberbezpieczeństwie.
Organizacje polegają na narzędziach programistycznych, bibliotekach, rozszerzeniach, pakietach, aktualizacjach, systemach budowania i środowiskach deweloperskich. Atakujący rozumieją, że kompromitacja tych zależności może zapewnić ogromny zasięg.
Bariera wejścia do zatrucia pakietu lub rozszerzenia bywa stosunkowo niska, zwłaszcza gdy opiekunowie zostają skompromitowani lub tokeny do publikowania są skradzione. Ale zasięg skutków może być ogromny.
Jeden złośliwy pakiet, rozszerzenie lub aktualizacja repozytorium może dotknąć:
- deweloperów
- systemy CI/CD
- potoki budowania
- aplikacje produkcyjne
- środowiska chmurowe
- klientów końcowych
- ekosystemy open source
Każda organizacja, która korzysta z oprogramowania, dziedziczy część ryzyka związanego z organizacjami i osobami, które je tworzą.
Wnioski obronne dla deweloperów
Deweloperzy powinni traktować rozszerzenia i pakiety jako część swojego perymetru bezpieczeństwa.
Zalecane działania obejmują:
- instalowanie rozszerzeń wyłącznie od zaufanych wydawców
- przegląd uprawnień i zachowania rozszerzeń
- usuwanie nieużywanych rozszerzeń VS Code
- unikanie instalowania nowo opublikowanych lub mało renomowanych pakietów bez weryfikacji
- monitorowanie tokenów GitHub, npm, Python i OpenVSX
- rotację tokenów w razie podejrzenia kompromitacji
- stosowanie tokenów o ograniczonym zakresie i krótkim czasie życia tam, gdzie to możliwe
- unikanie przechowywania długo żyjących sekretów na stacjach roboczych deweloperów
- korzystanie z menedżerów haseł z silną ochroną
- przegląd rozszerzeń przeglądarki pod kątem podejrzanego zachowania
- monitorowanie nieoczekiwanych narzędzi zdalnego dostępu lub procesów proxy
Maszyny deweloperów należy traktować jako systemy o wysokiej wartości, a nie zwykłe urządzenia końcowe.
Wnioski obronne dla organizacji
Zespoły ds. bezpieczeństwa powinny rozszerzyć monitorowanie łańcucha dostaw poza systemy produkcyjne.
Ważne mechanizmy kontroli obejmują:
- wykrywanie zagrożeń na stacjach roboczych deweloperów (endpoint detection)
- monitorowanie podejrzanej aktywności rozszerzeń VS Code
- skanowanie zależności pakietów
- monitorowanie repozytoriów GitHub
- alertowanie o nieoczekiwanym publikowaniu pakietów
- skanowanie sekretów w repozytoriach i logach budowania
- utwardzanie uprawnień CI/CD
- dostęp o najmniejszych uprawnieniach dla tokenów deweloperskich
- automatyczne unieważnianie ujawnionych poświadczeń
- przepływy zatwierdzania publikacji pakietów i rozszerzeń
- audyt dostępu do OpenVSX, npm, PyPI i GitHub
- monitorowanie połączeń wychodzących do nietypowej infrastruktury
Organizacje powinny też opracować plan reagowania na incydenty dotyczący konkretnie kompromitacji poświadczeń deweloperów.
Plan ten powinien obejmować przegląd repozytoriów, przegląd pakietów, rotację tokenów, audyt rozszerzeń oraz procedury powiadamiania użytkowników końcowych.
Co sprawdzić po GlassWorm
Deweloperzy i organizacje, które mogły zostać narażone, powinni przejrzeć:
- zainstalowane rozszerzenia VS Code i Open VSX
- listy rozszerzeń w Cursor, Windsurf, Positron i VSCodium
- ostatnio zainstalowane pakiety npm i Python
- logi dostępu do GitHub
- aktywność publikowania w npm, PyPI i OpenVSX
- nowe lub zmodyfikowane repozytoria
- nieoczekiwane commity lub wydania
- ujawnione tokeny deweloperskie
- nietypowe instalacje rozszerzeń przeglądarki
- podejrzane lokalne procesy proxy lub VNC
- nieoczekiwane procesy Node.js
- nieznany ruch WebRTC lub WebSocket
Jeśli zostanie wykryta podejrzana aktywność, poświadczenia należy natychmiast zrotować.
Podsumowanie
Przerwanie działania GlassWorm to ważny sukces obrońców, ale pokazuje też, jak daleko ewoluowały ataki na łańcuch dostaw oprogramowania.
Kampania celowała w deweloperów za pośrednictwem zaufanych narzędzi i ekosystemów pakietów, kradła poświadczenia, zatruwała repozytoria, wdrażała mechanizmy zdalnego dostępu i korzystała z odpornych kanałów dowodzenia i kontroli opartych na blockchainie, sieciach peer-to-peer, Google Calendar oraz infrastrukturze VPS.
To nie była zwykła kampania złośliwego oprogramowania. To była uporczywa operacja zaprojektowana tak, by przetrwać zakłócenia i utrzymać dostęp do ekosystemów deweloperskich.
Kluczowy wniosek jest jasny: środowiska deweloperskie są dziś infrastrukturą krytyczną.
Ochrona łańcuchów dostaw oprogramowania wymaga zabezpieczenia nie tylko systemów produkcyjnych, ale także stacji roboczych, rozszerzeń, pakietów, tokenów, repozytoriów i potoków używanych do budowania oprogramowania, od którego zależą wszyscy inni.
