GlassWorm – botnet, który polował na programistów. Dlaczego to ostrzeżenie dla całego open source?

GlassWorm – botnet, który żerował na zaufaniu w open source

Społeczność open source od dawna ufa rozproszonemu modelowi tworzenia oprogramowania, ale najnowsze wydarzenia pokazują, że to zaufanie bywa nagminnie wykorzystywane. Botnet GlassWorm, aktywny od października 2025 roku, przez ponad sześć miesięcy atakował ekosystem open source, celując w środowiska programistów. Dzięki współpracy CrowdStrike, Google i Shadowserver Foundation udało się przerwać działanie jego infrastruktury. To ważna lekcja dla każdej organizacji, która produkuje lub używa otwartego kodu.

Czym był GlassWorm i jak działał?

GlassWorm to samorozprzestrzeniające się złośliwe oprogramowanie, które według raportu SecurityWeek atakowało przede wszystkim programistów Visual Studio oraz inne osoby związane z otwartymi projektami. Malware był dystrybuowany za pośrednictwem trojanizowanych rozszerzeń do VS Code umieszczonych w marketplace OpenVSX, a później także przez GitHub.

Jego kluczową cechą było wykorzystanie Unicode variation selectors – znaków, które są niewidoczne dla ludzkiego oka, ale mogą zmieniać interpretację kodu przez edytory. Atakujący ukrywali w ten sposób złośliwe instrukcje, które pozostawały poza zasięgiem wzroku programisty przeglądającego kod źródłowy. To sprytna technika, która czyniła klasyczne audyty kodu nieskutecznymi.

Infrastruktura odporna na blokady

GlassWorm wyróżniał się nie tylko metodami ukrywania, ale też architekturą. Jego operatorzy zbudowali system dowodzenia i kontroli (C2) oparty aż na czterech kanałach, co CrowdStrike określił jako „dynamiczny front chroniący właściwe serwery C2 przez wiele warstw pośrednictwa”. Podstawą był blockchain Solana, gdzie adresy C2 kodowano w polach memo transakcji. Gdyby ten kanał padł, w grę wchodziły zapasowe: sieć BitTorrent do przechowywania danych konfiguracyjnych, Google Calendar (w tytułach wydarzeń zapisywano zakodowane w Base64 ścieżki C2) oraz tradycyjne serwery VPS używane do hostowania ładunków.

Takie rozwiązanie miało zapewnić przetrwanie botnetu nawet po wyłączeniu części infrastruktury. Dlatego kluczowe było jednoczesne przejęcie wszystkich czterech kanałów, co udało się osiągnąć pod koniec maja 2026 roku. Jak podkreślają badacze, sama Solana jako warstwa rozpoznawcza czyni atakujących zdolnymi do szybkiego odtworzenia sieci po utracie pojedynczego punktu – to wyzwanie dla przyszłych operacji tego typu.

Co kradł GlassWorm i komu zagrażał?

Głównym celem botnetu były dane uwierzytelniające do platform takich jak NPM, GitHub i Git, a także informacje o portfelach kryptowalut – konkretnie z kilkudziesięciu rozszerzeń. Poza tym malware instalował serwery proxy SOCKS5 i ukryte serwery VNC, umożliwiające zdalny dostęp do zainfekowanej maszyny. Taki zestaw narzędzi dawał atakującym bezpośredni wgląd w środowiska deweloperskie i potencjalny dostęp do łańcucha dostaw oprogramowania.

CrowdStrike ostrzega, że „dostęp do wykradzionych poświadczeń stwarzał ciągłe ryzyko ataków na łańcuch dostaw o znacznym wpływie”. Innymi słowy, infekcja jednego programisty mogła w konsekwencji zagrozić wszystkim odbiorcom jego kodu – od małych firm po duże przedsiębiorstwa.

Co ciekawe, badacze wskazują na rosyjskie pochodzenie operatorów GlassWorm: malware sprawdza lokalizację systemu i omija komputery w krajach WNP, a w kodzie znajdowały się komentarze po rosyjsku. To jednak nie zmienia faktu, że zagrożenie było globalne i dotknęło programistów na całym świecie.

Jak się chronić i co dalej?

Takedown GlassWorma to ważne osiągnięcie, ale nie koniec problemu. CrowdStrike radzi organizacjom, by sprawdziły, czy ich urządzenia nie łączyły się z adresem IP 164.92.88[.]210 – to adres, na który botnet po przejęciu miał kierować zapytania. Każda taka próba połączenia powinna być potraktowana jako sygnał alarmowy i skutkować dokładnym audytem.

Dla deweloperów kluczowe są dwie zasady: po pierwsze, ostrożność przy instalowaniu rozszerzeń i pakietów z nieoficjalnych źródeł (OpenVSX, GitHub), nawet jeśli pochodzą od zaufanych wydawców – atakujący potrafią przejmować konta lub stosować typosquatting. Po drugie, regularna rotacja tokenów i kluczy API używanych w procesie CI/CD.

GlassWorm nie był pierwszym botnetem atakującym łańcuch dostaw i nie będzie ostatnim. Jak zauważają eksperci CrowdStrike, „dopóki środowiska deweloperskie, potoki kompilacji i repozytoria kodu pozostają słabo chronione, każda organizacja konsumująca oprogramowanie dziedziczy ryzyko wszystkich jego twórców”. Dlatego warto potraktować tę historię jako impuls do przeglądu własnych praktyk – zwłaszcza w firmach, które polegają na gotowych bibliotekach i frameworkach open source.