Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem npm pozostaje jednym z najczęściej wykorzystywanych celów ataków na łańcuch dostaw oprogramowania. W najnowszej kampanii cyberprzestępcy opublikowali złośliwe pakiety podszywające się pod narzędzia związane z PostCSS, aby wykorzystać zaufanie deweloperów do popularnych zależności frontendowych.
Celem operacji nie było jedynie uruchomienie prostego skryptu, lecz dostarczenie wieloetapowego łańcucha infekcji kończącego się instalacją trojana zdalnego dostępu dla systemu Windows. To oznacza, że pozornie niegroźna zależność mogła doprowadzić do przejęcia stacji roboczej programisty i kradzieży danych.
W skrócie
Badacze wskazali kilka pakietów npm opublikowanych pod kontem „abdrizak”, w tym aes-decode-runner-pro, postcss-minify-selector oraz postcss-minify-selector-parser. Nazwy zostały dobrane tak, aby wyglądały jak legalne komponenty używane w procesie budowania aplikacji i przetwarzania CSS.
Po instalacji pakiety uruchamiały kod JavaScript zapisujący na dysku skrypt PowerShell. Następnie rozpoczynał się proces pobierania kolejnych elementów ładunku z zewnętrznej infrastruktury, czego efektem końcowym było wdrożenie RAT-a zdolnego do zbierania danych systemowych, wykonywania poleceń, przesyłania plików oraz kradzieży informacji z przeglądarki Google Chrome.
- Złośliwe pakiety podszywały się pod narzędzia PostCSS.
- Infekcja była wieloetapowa i ukierunkowana na system Windows.
- Końcowy malware zapewniał zdalny dostęp do hosta.
- Zagrożone były dane przeglądarkowe, poświadczenia i pliki projektowe.
Kontekst / historia
Ataki na otwarte rejestry pakietów nie są nowym zjawiskiem, ale ich charakter wyraźnie się zmienia. Wcześniejsze kampanie często polegały na prostym typosquattingu lub kradzieży zmiennych środowiskowych. Obecnie coraz częściej spotykane są operacje, w których pakiet pełni wyłącznie rolę pierwszego etapu dostępu, a właściwa funkcjonalność malware jest dostarczana dopiero później.
W tym przypadku napastnicy wykorzystali skojarzenie z PostCSS, czyli szeroko stosowanym ekosystemem narzędzi frontendowych. To ważne, ponieważ takie biblioteki bywają instalowane automatycznie jako zależności pośrednie, przez co ich obecność może pozostać niezauważona zarówno dla dewelopera, jak i dla podstawowych mechanizmów kontroli bezpieczeństwa.
Kampania wpisuje się również w szerszy trend ataków wymierzonych bezpośrednio w środowiska programistyczne. Stacje robocze deweloperów są atrakcyjnym celem, ponieważ często przechowują tokeny dostępu, sesje do usług chmurowych, sekrety projektowe oraz uprawnienia do repozytoriów i pipeline’ów CI/CD.
Analiza techniczna
Łańcuch infekcji rozpoczynał się od instalacji jednego ze złośliwych pakietów npm. Osadzony w nim kod JavaScript działał jako dropper i zapisywał na dysku skrypt settings.ps1, który następnie był uruchamiany w środowisku PowerShell.
Kolejny etap polegał na pobraniu zewnętrznego archiwum ZIP przy użyciu curl.exe. W archiwum znajdowały się dalsze komponenty, między innymi skrypt update.vbs, środowisko uruchomieniowe Pythona, plik loader.py oraz zestaw modułów .pyd skompilowanych z użyciem Nuitka.
Taka konstrukcja znacząco utrudnia analizę i wykrycie zagrożenia. Właściwa logika malware nie znajduje się bowiem bezpośrednio w samym pakiecie npm, lecz jest dostarczana zdalnie i częściowo ukryta w binarnych rozszerzeniach Pythona. Dzięki temu prostsze skanery zależności mogą nie wychwycić pełnej skali ryzyka.
Rola poszczególnych komponentów obejmowała przygotowanie środowiska wykonawczego, uruchomienie loadera oraz aktywację głównej logiki RAT-a. Z analizy wynika, że moduły odpowiadały za komunikację z serwerem C2, zbieranie informacji o hoście, wykonywanie poleceń powłoki, transfer plików oraz kradzież danych z Google Chrome.
- JavaScript inicjował infekcję i uruchamiał PowerShell.
- PowerShell pobierał dalsze składniki malware z infrastruktury zewnętrznej.
- VBS i Python przygotowywały środowisko do działania trojana.
- Moduły
.pydrealizowały funkcje operacyjne RAT-a. - Malware potrafił kraść dane przeglądarkowe, wykonywać polecenia i przesyłać pliki.
Szczególnie niebezpieczny jest komponent odpowiedzialny za pozyskiwanie danych z Chrome. W praktyce może to obejmować zapisane hasła, tokeny sesyjne, dane rozszerzeń oraz inne artefakty umożliwiające przejęcie kont lub dalszą kompromitację środowiska organizacji.
Konsekwencje / ryzyko
Ryzyko związane z tą kampanią należy ocenić jako wysokie, ponieważ atak rozpoczyna się w obszarze o dużym poziomie zaufania, czyli w menedżerze pakietów i zależnościach projektu. Jeśli złośliwy komponent zostanie uruchomiony na komputerze dewelopera, konsekwencje mogą wykraczać daleko poza pojedynczy endpoint.
Najbardziej prawdopodobne skutki obejmują kradzież poświadczeń z przeglądarki, przejęcie aktywnych sesji do usług deweloperskich, zdalne wykonywanie poleceń na hoście oraz exfiltrację plików związanych z projektem. W środowiskach firmowych może to prowadzić do naruszenia repozytoriów kodu, manipulacji pipeline’ami CI/CD, wycieku sekretów aplikacyjnych i dalszej kompromitacji infrastruktury chmurowej.
Dodatkowym problemem jest wieloetapowość ataku. Początkowy pakiet nie zawiera całego malware, przez co podstawowe kontrole reputacyjne i automatyczne skanowanie zależności mogą nie wykazać pełnego zagrożenia. To sprawia, że podobne kampanie są szczególnie groźne dla zespołów, które opierają bezpieczeństwo wyłącznie na statycznej analizie pakietów.
Rekomendacje
Organizacje powinny jak najszybciej sprawdzić, czy wskazane pakiety pojawiły się w projektach, plikach lock, lokalnym cache npm lub na stacjach roboczych deweloperów. Każdy host, na którym zainstalowano takie zależności, należy traktować jako potencjalnie skompromitowany.
- Usunąć wskazane pakiety oraz wszystkie powiązane artefakty.
- Przeanalizować uruchomienia
powershell.exe,wscript.exe,curl.exei nietypowych procesów Python po instalacji zależności npm. - Wyszukać pliki
settings.ps1,update.vbs,loader.pyoraz podejrzane moduły.pyd. - Zweryfikować połączenia sieciowe do nieautoryzowanych domen i adresów IP.
- Zrotować hasła, tokeny Git, sekrety npm, dane chmurowe i sesje przeglądarkowe używane na zagrożonych hostach.
- Przeanalizować historię zmian w projektach i pipeline’ach CI/CD pod kątem dodania podejrzanych zależności.
- Wdrożyć listy dozwolonych pakietów i dodatkowe kontrole reputacyjne dla nowych bibliotek.
- Rozszerzyć reguły EDR/XDR o wykrywanie łańcuchów typu npm → Node.js → PowerShell → VBS → Python.
W dłuższej perspektywie warto wdrożyć mechanizmy ograniczające typosquatting, skanowanie SBOM, kontrole zależności na etapie pull requestów oraz zasadę minimalnych uprawnień dla stacji deweloperskich. Istotne pozostaje również ograniczenie lokalnego przechowywania długowiecznych sekretów i lepsza segmentacja dostępu do repozytoriów.
Podsumowanie
Kampania wykorzystująca fałszywe pakiety npm podszywające się pod narzędzia PostCSS pokazuje, że ataki na software supply chain stają się coraz bardziej dojrzałe i wielowarstwowe. Z pozoru zwykła zależność frontendowa może dziś stanowić punkt wejścia do pełnej kompromitacji stacji roboczej programisty.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona łańcucha dostaw oprogramowania nie może ograniczać się do samego kodu aplikacji. Równie ważna jest ścisła kontrola pochodzenia, reputacji i rzeczywistego zachowania wszystkich zależności instalowanych w środowiskach developerskich.