Wprowadzenie do problemu / definicja luki
GlassWorm to wielofalowa kampania typu supply chain wymierzona w ekosystem rozszerzeń Visual Studio Code (Microsoft Visual Studio Marketplace) oraz Open VSX (alternatywny, „vendor-neutral” rejestr używany m.in. przez edytory kompatybilne z VS Code). Atak polega na publikowaniu trojanizowanych rozszerzeń, które po instalacji uruchamiają kolejne etapy infekcji: kradzież tokenów i danych, instalację backdoora oraz – w najnowszej odsłonie – próbę podmiany aplikacji obsługujących portfele sprzętowe na wersje złośliwe.
Istotna zmiana w fali 4: po wcześniejszym skupieniu na Windows, kampania przeniosła ciężar na macOS (deweloperów), co ma sens operacyjny – to popularna platforma w software housach i środowiskach krypto/Web3.
W skrócie
- Kogo atakują? Deweloperów na macOS instalujących zaufanie-budujące rozszerzenia VS Code/Open VSX.
- Jak? 3 podejrzane rozszerzenia na Open VSX zawierają zaszyfrowany (AES-256-CBC) payload w skompilowanym JavaScript, uruchamiany po opóźnieniu ~15 minut.
- Po co? Kradzież danych (tokeny GitHub/NPM, dane przeglądarki, Keychain), celowanie w portfele krypto (rozszerzenia i aplikacje desktop), a w fali 4 także mechanizm podmiany Ledger Live i Trezor Suite.
- C2/odporność infrastruktury: utrzymany został mechanizm C2 oparty o blockchain Solana (dynamiczne wskazywanie endpointów).
Kontekst / historia / powiązania
- Październik 2025: kampania została opisana jako atak wykorzystujący m.in. „niewidzialne” znaki Unicode do ukrycia złośliwego kodu w rozszerzeniach.
- Kolejne fale: napastnicy wracali mimo nagłośnienia i usuwania złośliwych pozycji z marketplace’ów.
- Reakcja ekosystemu: zespół Open VSX (Eclipse Foundation) podkreślał, iż incydent został opanowany, usuwał złośliwe rozszerzenia i wprowadzał zmiany w zarządzaniu tokenami oraz skanowaniu publikacji.
W praktyce ta historia pokazuje typowy problem obrony w łańcuchu dostaw: choćby po „cleanupie” i wzmacnianiu kontroli, atakujący iterują techniki dostarczania (Unicode → binaria/kompilacja → szyfrowany JS + opóźnienia) i przenoszą cele na najbardziej „opłacalne” środowiska.
Analiza techniczna / szczegóły luki
1) Nośnik: złośliwe rozszerzenia (Open VSX / VS Code)
W fali 4 badacze wskazali trzy identyfikatory rozszerzeń (Open VSX), powiązane z macOS-owym łańcuchem infekcji:
- studio-velte-distributor.pro-svelte-extension
- cudra-production.vsce-prettier-pro
- Puccin-development.full-access-catppuccin-pro-extension
2) Dostarczenie i unikanie detekcji: szyfrowanie + opóźnienie
Zamiast „niewidzialnego” Unicode, payload jest opakowany w AES-256-CBC i zaszyty w skompilowanym JavaScript. Dodatkowo logika wykonuje się po ok. 15 minutach, co utrudnia sandboxing (wiele automatycznych analiz dynamicznych kończy się szybciej).
3) macOS TTP: AppleScript + LaunchAgents + Keychain
W porównaniu do wcześniejszych podejść (np. PowerShell/Registry na Windows), fala 4 używa natywnych dla macOS mechanizmów:
- AppleScript do wykonania etapów wstępnych,
- LaunchAgents jako mechanizm persystencji,
- próby pozyskania haseł z Keychain (w tym wskazywane jest też pozyskanie samej bazy Keychain).
4) C2 na blockchainie Solana (odporność na „takedown”)
Mechanizm C2 pozostaje kluczowym elementem kampanii: malware ma pobierać aktualne endpointy (np. URL) z danych powiązanych z aktywnością w sieci Solana, co utrudnia klasyczne blokowanie domen/serwerów „na sztywno”.
5) Eskalacja: podmiana aplikacji portfeli sprzętowych
Najbardziej niepokojący element fali 4: kod sprawdza obecność Ledger Live i Trezor Suite, a następnie ma próbować pobrać i zainstalować ich trojanizowane odpowiedniki (po usunięciu legalnej aplikacji). Badacze odnotowali też, iż w momencie testów część endpointów mogła zwracać puste pliki, przez co sama podmiana mogła „cicho” nie dojść do skutku – ale mechanizm jest już gotowy.
Przykładowe IoC (wartości z publicznych analiz)
- Podejrzane rozszerzenia: jak wyżej (3 ID).
- Wskazywane IP infrastruktury (C2/eksfil): m.in. 45.32.151.157, 45.32.150.251 (oraz historycznie 217.69.11.60).
- Portfel/identyfikator wykorzystywany w mechanizmie Solana-C2 (podawany przez badaczy): BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC.
Praktyczne konsekwencje / ryzyko
- Ryzyko kradzieży tożsamości deweloperskiej: tokeny i dane dostępowe do GitHub/NPM mogą przełożyć się na kolejne kompromitacje (repozytoria, paczki, pipeline’y CI/CD).
- Ryzyko finansowe (krypto): celowanie w portfele przeglądarkowe i desktopowe oraz eskalacja w stronę portfeli sprzętowych oznaczają potencjalnie wyższy „payoff” dla atakujących.
- Ryzyko lateral movement i trwałej obecności: persystencja (LaunchAgents) + zdalny dostęp/pośrednictwo ruchu (historycznie opisywane jako VNC/SOCKS) może zmienić stację deweloperską w punkt wejścia do sieci firmowej.
- Trudniejszy „takedown”: C2 oparte o Solanę komplikuje tradycyjne podejście „zablokuj domenę/serwer”.
Rekomendacje operacyjne / co zrobić teraz
Dla zespołów SOC/IR i IT
- Natychmiastowy audyt rozszerzeń VS Code na macOS (szczególnie instalowanych z Open VSX), z naciskiem na nowe/mało znane wydawców oraz „podejrzanie podobne” nazwy (np. podszywanie się pod popularne narzędzia typu formatter/theme).
- Wymuś allow-listę rozszerzeń (organizacyjnie) i ogranicz możliwość instalacji z nieautoryzowanych marketplace’ów, jeżeli to możliwe.
- Hunting na macOS pod kątem persystencji: przegląd ~/Library/LaunchAgents oraz /Library/LaunchAgents, korelacja z czasem instalacji rozszerzeń VS Code.
- Monitoring procesów i zachowań:
- nietypowe użycie osascript / AppleScript w kontekście VS Code,
- odwołania do narzędzia security i operacji na Keychain,
- nietypowe archiwizowanie/staging danych w katalogach tymczasowych (w analizach wskazywano staging w /tmp).
- Blokady i detekcje sieciowe (z rozwagą): dodaj do watchlisty wskazywane IP/ścieżki eksfiltracji, ale traktuj je jako zmienne (Solana-C2 ułatwia rotację).
- Rotacja sekretów: jeżeli wykryjesz podejrzane rozszerzenia na endpointach deweloperskich, załóż kompromitację tokenów (GitHub PAT, NPM, SSH keys) i wykonaj kontrolowaną rotację oraz przegląd logów dostępu.
Dla deweloperów
- Instaluj rozszerzenia tylko od zweryfikowanych wydawców i weryfikuj, czy linki/identyfikatory wydawcy zgadzają się z projektem.
- Ogranicz uprawnienia i ekspozycję sekretów w środowisku developerskim (np. osobne konta, krótkie TTL tokenów, minimalne scope).
- Jeśli używasz Ledger/Trezor: zwróć uwagę na nagłe reinstalacje/„aktualizacje” aplikacji i weryfikuj podpisy/pochodzenie instalatorów (szczególnie po instalacji nowych rozszerzeń).
Różnice / porównania z innymi przypadkami
- Fale 1–2: nacisk na ukrywanie kodu przez „niewidzialne” Unicode (w tym klasy znaków, które potrafią umykać typowym ostrzeżeniom) i kradzież danych deweloperskich/krypto.
- Fala 3: odejście od „niewidzialnego” kodu w stronę trudniejszych w analizie artefaktów (np. natywnych/kompilowanych), utrzymanie Solana-C2.
- Fala 4 (teraz): pełny pivot na macOS + AES-256-CBC w JS + opóźnienie 15 min + LaunchAgents/Keychain oraz wyraźna eskalacja w stronę podmiany Ledger Live i Trezor Suite.
To nie jest „jednorazowy incydent marketplace’u”, tylko kampania, która iteruje TTP pod presją publikacji i działań porządkowych.
Podsumowanie / najważniejsze wnioski
- GlassWorm w 4. fali pokazuje, iż deweloperskie marketplace’y są atrakcyjnym wektorem APT-like dla cyberprzestępców (skala + zaufanie + dostęp do sekretów).
- Pivot na macOS i próby podmiany Ledger/Trezor to sygnał, iż kampania celuje w środowiska o wysokiej wartości (krypto, Web3, startupy).
- Obrona „perymetrem” i samymi IOC nie wystarczy: potrzebne są polityki instalacji rozszerzeń, kontrola sekretów i detekcja behawioralna na endpointach deweloperskich.
Źródła / bibliografia
- KOI Security – GlassWorm Goes Mac: Fresh Infrastructure, New Tricks (29.12.2025). (koi.ai)
- BleepingComputer – New GlassWorm malware wave targets Macs with trojanized crypto wallets (01.01.2026). (BleepingComputer)
- Endor Labs – Invisible Threats and the Blind Spots of Security: How GlassWorm Exploited Unicode Shadows… (endorlabs.com)
- Truesec – GlassWorm – Self-Propagating VSCode Extension Worm (21.10.2025). (Truesec)
- SecurityWeek – Open VSX Downplays Impact From GlassWorm Campaign (31.10.2025). (SecurityWeek)
