
Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki supply chain wymierzone w ekosystemy open source należą dziś do najgroźniejszych zagrożeń dla zespołów programistycznych. W opisywanym incydencie złośliwie zmodyfikowane pakiety dla npm i Go zostały użyte do uruchomienia wieloetapowego łańcucha infekcji, którego celem było wdrożenie infostealera napisanego w Pythonie.
Na szczególną uwagę zasługuje sposób wykonania złośliwego kodu. Operatorzy kampanii nie ograniczyli się do klasycznych skryptów instalacyjnych, ale wykorzystali mechanizm automatycznych zadań w Visual Studio Code, uruchamianych po otwarciu katalogu projektu. To pokazuje, że środowisko IDE staje się pełnoprawnym elementem powierzchni ataku.
W skrócie
- Atak objął co najmniej dwa pakiety npm oraz 16 pakietów Go.
- Złośliwy kod był aktywowany przez ukryte zadanie VS Code uruchamiane automatycznie po otwarciu projektu.
- Łańcuch infekcji pobierał kolejne etapy z wykorzystaniem danych zapisanych w transakcjach blockchain.
- Po infekcji uruchamiany był backdoor oparty na Socket.io oraz pythonowy infostealer.
- Malware kradło dane z przeglądarek, portfeli kryptowalutowych, menedżerów haseł i narzędzi deweloperskich.
Kontekst / historia
Wśród zidentyfikowanych pakietów npm znalazły się html-to-gutenberg oraz fetch-page-assets, przy czym drugi deklarował pierwszy jako zależność. Pakiety zostały opublikowane pod koniec maja 2026 roku, a następnie usunięte po wykryciu incydentu. Równolegle wykryto podobny zestaw złośliwych pakietów w ekosystemie Go, co sugeruje skoordynowaną operację wymierzoną w programistów.
Kampania wpisuje się w szerszy trend ataków na środowiska deweloperskie, w których celem nie jest wyłącznie pojedyncza stacja robocza. Przejęcie tokenów, kluczy API, danych dostępowych do repozytoriów czy zasobów chmurowych może otworzyć drogę do dalszych kompromitacji łańcucha dostaw oprogramowania.
Analiza techniczna
Początek infekcji stanowiło ukryte zadanie VS Code, którego nazwa mogła sugerować legalną czynność związaną z jakością kodu lub lintingiem. Zadanie było skonfigurowane tak, aby uruchamiać się automatycznie po otwarciu folderu roboczego, co pozwalało ominąć bardziej oczywiste ścieżki wykonania złośliwego kodu.
Jednym z elementów kamuflażu było ukrycie ładunku jako pliku czcionki, mimo że w rzeczywistości zawierał on kod JavaScript. Taki zabieg utrudniał wykrycie podczas pobieżnej analizy struktury projektu. Następnie malware korzystał z blockchaina jako mechanizmu dead drop resolver, odczytując dane z transakcji w celu pobrania kolejnych, zaszyfrowanych komponentów.
Po pobraniu następnego etapu uruchamiany był komponent JavaScript odpowiedzialny za ustalenie konfiguracji C2 i aktywację backdoora opartego na Socket.io. Zapewniał on operatorom możliwość zdalnego wykonywania poleceń, pracy na plikach, przesyłania danych, zarządzania procesami, odczytu schowka oraz uruchamiania dodatkowego kodu.
Równolegle wdrażany był loader w Pythonie, który pobierał właściwy moduł kradnący dane wraz z wymaganymi zależnościami. Infostealer był profilowany pod kątem systemów Windows, Linux i macOS. Obejmował ekstrakcję danych z przeglądarek Chromium i Firefox, menedżerów haseł, aplikacji uwierzytelniających, portfeli kryptowalutowych oraz systemowych magazynów poświadczeń.
Szczególnie istotny był zakres danych deweloperskich objętych kradzieżą. Malware potrafił pozyskiwać poświadczenia Git, dane z GitHub CLI, logi GitHub Desktop, ustawienia i pamięć globalną VS Code, a także informacje powiązane z usługami chmurowymi. Zebrane dane były archiwizowane do plików ZIP i wysyłane do infrastruktury atakującego, a w części scenariuszy również do bota Telegram.
Konsekwencje / ryzyko
Skutki takiego incydentu mogą wykraczać daleko poza kompromitację jednego urządzenia. W środowiskach programistycznych przejęcie danych uwierzytelniających może prowadzić do dostępu do repozytoriów kodu, pipeline’ów CI/CD, rejestrów pakietów, kont chmurowych i systemów wewnętrznych organizacji.
To z kolei zwiększa ryzyko dalszych kompromitacji supply chain, sabotażu procesu wydawniczego, podmiany artefaktów, kradzieży własności intelektualnej oraz utrzymania trwałego dostępu do środowiska. Dodatkowo wykorzystanie automatycznych zadań VS Code pokazuje, że wiele organizacji nadal nie monitoruje ustawień IDE z taką samą uwagą jak skryptów startowych czy zadań systemowych.
Rekomendacje
Organizacje powinny niezwłocznie przeprowadzić przegląd środowisk deweloperskich pod kątem obecności podejrzanych pakietów npm i Go oraz plików .vscode/tasks.json. Należy zweryfikować, czy w projektach nie występują zadania skonfigurowane do automatycznego uruchamiania po otwarciu workspace’u, zwłaszcza jeśli ich nazwy imitują standardowe testy jakości lub linting.
- Przeprowadzić audyt konfiguracji workspace’ów i zadań IDE.
- Ograniczyć automatyczne uruchamianie zadań w niezaufanych projektach.
- Skanować zależności pod kątem nietypowych artefaktów i rozbieżności typów plików.
- Monitorować komunikację sieciową do niestandardowych źródeł konfiguracji i kanałów C2.
- Segmentować środowiska deweloperskie i ograniczać uprawnienia do systemów produkcyjnych.
- W razie wykrycia incydentu przeprowadzić pełną rotację haseł, tokenów, kluczy API i sekretów chmurowych.
W działaniach threat hunting warto uwzględnić takie wskaźniki jak fałszywe pliki czcionek zawierające JavaScript, nietypowe procesy Pythona uruchamiane z katalogów projektowych, archiwa ZIP tworzone krótko po otwarciu projektu oraz ślady dostępu do lokalnych magazynów poświadczeń.
Podsumowanie
Opisana kampania potwierdza, że cyberprzestępcy coraz sprawniej wykorzystują legalne funkcje narzędzi deweloperskich do prowadzenia operacji ofensywnych. Połączenie automatycznych zadań VS Code, wieloetapowego loadera, infrastruktury blockchain i modułu kradnącego dane znacząco podniosło poziom ukrycia całego ataku.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona software supply chain nie może ograniczać się wyłącznie do skanowania manifestów zależności. Równie ważne stają się ustawienia workspace’ów, logika wykonania osadzona w IDE oraz artefakty projektu, które dotąd bywały traktowane jako element niskiego ryzyka.