GlassWorm rozwija kampanię supply chain z użyciem droppera Zig atakującego narzędzia deweloperskie

securitybeztabu.pl 21 godzin temu

Wprowadzenie do problemu / definicja

Kampania GlassWorm to przykład nowoczesnego zagrożenia typu supply chain, w którym cyberprzestępcy nadużywają zaufanych narzędzi używanych przez programistów do dystrybucji złośliwego oprogramowania. W najnowszym wariancie ataku wykorzystano dropper napisany w języku Zig i ukryty w fałszywym rozszerzeniu IDE, co pozwala infekować wiele środowisk deweloperskich na jednym hoście.

To istotna zmiana jakościowa, ponieważ atak nie ogranicza się już do pojedynczego edytora czy jednego pakietu. Zamiast tego obejmuje cały lokalny ekosystem pracy dewelopera, zwiększając skalę kompromitacji i utrudniając wykrycie incydentu.

W skrócie

GlassWorm ewoluował od złośliwych pakietów do bardziej zaawansowanej kampanii wymierzonej w narzędzia deweloperskie.
Atak wykorzystuje fałszywe rozszerzenie IDE zawierające natywny komponent napisany w Zig.
Dropper działa poza typowym sandboxem JavaScript i skanuje system w poszukiwaniu innych środowisk programistycznych.
Po wykryciu kolejnych IDE malware instaluje następne etapy infekcji, zwiększając zasięg ataku.
Skutkiem mogą być kradzież danych, trwały dostęp zdalny i kompromitacja procesu wytwarzania oprogramowania.

Kontekst / historia

GlassWorm był wcześniej wiązany z nadużyciami w ekosystemie JavaScript oraz z próbami kompromitacji środowisk deweloperskich przy użyciu komponentów, które z założenia budzą zaufanie użytkowników. Obecna kampania pokazuje, iż operatorzy rozwijają swoje techniki, przesuwając ciężar z prostszych metod na bardziej zaawansowane mechanizmy oparte o natywny kod.

Ta ewolucja ma strategiczne znaczenie. Narzędzia deweloperskie, rozszerzenia IDE, rejestry pakietów oraz repozytoria kodu stanowią dziś krytyczny element łańcucha dostaw oprogramowania. Kompromitacja stacji roboczej programisty może otworzyć drogę nie tylko do kradzieży kodu czy sekretów, ale także do ingerencji w pipeline’y CI/CD i dalszego rozprzestrzeniania zagrożenia.

Analiza techniczna

W analizowanym scenariuszu atak rozpoczyna się od złośliwego rozszerzenia podszywającego się pod legalny dodatek dla środowiska programistycznego. Kluczowym elementem kampanii jest binarny komponent skompilowany w Zig, który pełni rolę droppera. Nie jest to końcowy ładunek, ale etap pośredni odpowiedzialny za przygotowanie dalszej infekcji.

Zastosowanie Zig ma znaczenie operacyjne. Natywny komponent działa poza ograniczeniami typowymi dla kodu JavaScript wykonywanego wewnątrz rozszerzenia, dzięki czemu uzyskuje szerszy dostęp do systemu operacyjnego. Po uruchomieniu dropper przeprowadza lokalny rekonesans i identyfikuje zainstalowane środowiska deweloperskie, takie jak VS Code, Cursor czy VSCodium.

Następnie malware pobiera kolejny etap infekcji i instaluje go w wykrytych IDE, wykorzystując natywne mechanizmy tych aplikacji. To szczególnie niebezpieczne podejście, ponieważ bazuje na zaufanych ścieżkach instalacyjnych i może nie wywoływać od razu oczywistych alarmów po stronie użytkownika.

Drugi etap kampanii odpowiada za adekwatne działania po kompromitacji. Z opisu wynika, iż malware potrafi unikać uruchamiania na systemach rosyjskich, komunikuje się z infrastrukturą C2 powiązaną z Solaną, a po uzyskaniu dostępu kradnie dane, utrzymuje trwałość oraz może wdrażać złośliwe rozszerzenia przeglądarki.

Technicznie kampania łączy kilka istotnych trendów obserwowanych we współczesnych operacjach malware:

wykorzystanie natywnego kodu do obejścia ograniczeń środowisk skryptowych,
nadużycie rozszerzeń IDE jako wektora initial access,
rozprzestrzenianie się pomiędzy wieloma aplikacjami na tym samym hoście,
usuwanie śladów po instalatorze po wdrożeniu kolejnych etapów,
koncentrację na stacjach roboczych deweloperów jako celu o wysokiej wartości.

Konsekwencje / ryzyko

Ryzyko związane z GlassWorm jest znacznie szersze niż pojedyncza infekcja endpointu. Stacja deweloperska często zawiera tokeny Git, klucze API, poświadczenia do chmury, dane projektowe, lokalne repozytoria oraz dostęp do systemów build i wdrożeń. Ich przejęcie może prowadzić do rozległego naruszenia bezpieczeństwa organizacji.

kradzieży własności intelektualnej,
kompromitacji repozytoriów kodu,
wstrzyknięcia złośliwego kodu do legalnych projektów,
przejęcia pipeline’ów CI/CD,
eskalacji do środowisk testowych i produkcyjnych,
ataków na klientów, partnerów i użytkowników końcowych.

Szczególnie niebezpieczny jest charakter wielośrodowiskowy tej kampanii. o ile złośliwe oprogramowanie potrafi infekować kilka IDE na jednym komputerze, usunięcie tylko jednego dodatku lub naprawa jednej aplikacji może nie rozwiązać problemu. Dodatkowym zagrożeniem jest możliwość instalacji złośliwych rozszerzeń przeglądarki, co zwiększa ryzyko przejęcia sesji, tokenów i wrażliwych danych uwierzytelniających.

Rekomendacje

Organizacje powinny traktować wykrycie podejrzanych rozszerzeń lub artefaktów powiązanych z GlassWorm jako pełnoprawny incydent bezpieczeństwa. Samo odinstalowanie dodatku jest niewystarczające, jeżeli malware zdążył pobrać kolejne etapy infekcji lub rozprzestrzenić się pomiędzy narzędziami.

Natychmiast izolować podejrzaną stację roboczą od sieci.
Uznawać host za skompromitowany do czasu zakończenia pełnej analizy powłamaniowej.
Rotować wszystkie potencjalnie ujawnione sekrety, w tym tokeny Git, klucze API i poświadczenia chmurowe.
Sprawdzać listę rozszerzeń we wszystkich używanych IDE, a nie tylko w jednej aplikacji.
Zweryfikować przeglądarki pod kątem nieautoryzowanych rozszerzeń i aktywnych sesji.
Przeanalizować logi repozytoriów, CI/CD i IAM w poszukiwaniu nietypowych działań.
Wdrożyć allowlisty rozszerzeń IDE oraz ograniczyć instalację dodatków z niezatwierdzonych źródeł.
Monitorować uruchamianie binariów inicjowanych przez rozszerzenia i analizować telemetrię EDR.
Stosować zasadę least privilege na stacjach deweloperskich.
Szkolić zespoły programistyczne z ryzyk supply chain i weryfikacji reputacji dodatków.

W bardziej dojrzałych środowiskach warto dodatkowo wdrożyć skanowanie zależności i rozszerzeń, mechanizmy attestation oraz regularne przeglądy zaufanych komponentów używanych w procesie tworzenia oprogramowania.

Podsumowanie

GlassWorm pokazuje, iż ataki supply chain coraz częściej koncentrują się na codziennych narzędziach pracy deweloperów. Wykorzystanie droppera Zig uruchamianego poza sandboxem JavaScript pozwala operatorom skuteczniej infekować wiele środowisk IDE i zwiększać zasięg kompromitacji.

Dla organizacji to wyraźny sygnał, iż ekosystem developerski należy traktować jako krytyczną powierzchnię ataku. Skuteczna obrona wymaga nie tylko ochrony endpointów, ale również ścisłej kontroli rozszerzeń, rygorystycznego zarządzania sekretami i pełnej widoczności działań wykonywanych na stacjach roboczych programistów.