Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo łańcucha dostaw oprogramowania pozostaje jednym z najtrudniejszych obszarów cyberbezpieczeństwa. Coraz częściej napastnicy nie atakują bezpośrednio organizacji końcowej, lecz kompromitują zaufane komponenty wykorzystywane w procesie tworzenia aplikacji, dzięki czemu zyskują dostęp do środowisk deweloperskich, repozytoriów oraz mechanizmów publikacji oprogramowania.
Najnowsza kampania przypisywana aktorom powiązanym z Koreą Północną pokazuje, że szczególnie atrakcyjnym celem są maintainerzy projektów open source, konta deweloperskie i publiczne rejestry pakietów. W praktyce oznacza to, że pojedyncza kompromitacja może stać się punktem wejścia do znacznie szerszego ataku na firmy, klientów i partnerów biznesowych.
W skrócie
Badacze opisali kampanię określaną jako PolinRider, wymierzoną w deweloperów open source oraz użytkowników zaufanych pakietów i repozytoriów. Zamiast polegać wyłącznie na fałszywych bibliotekach, operatorzy przejmują legalne konta maintainerów, modyfikują istniejące projekty i publikują zainfekowane artefakty w popularnych ekosystemach.
W operacji wykorzystywano złośliwe komponenty prowadzące do wdrożenia backdoora DEV#POPPER oraz infostealera OmniStealer. Skala kampanii jest istotna, ponieważ zidentyfikowano liczne złośliwe wydania i ponad sto unikalnych pakietów, a aktywność objęła między innymi NPM, Packagist, moduły Go oraz rozszerzenia przeglądarkowe.
Kontekst / historia
Operacja wpisuje się w dłuższy trend działań północnokoreańskich grup APT, które od lat koncentrują się na przejmowaniu dostępu do środowisk programistycznych, poświadczeń, kodu źródłowego i zasobów powiązanych z finansami cyfrowymi. Kampania PolinRider ma być aktywna od grudnia 2025 roku i została powiązana z szerszym klastrem aktywności znanym z wykorzystywania socjotechniki, fałszywych procesów rekrutacyjnych oraz długotrwałego infekowania systemów specjalistów IT.
To kolejny etap ewolucji wcześniejszych operacji wymierzonych w programistów, ale z wyraźnie większym naciskiem na kompromitację legalnych repozytoriów i dystrybucję malware przez kanały, które ofiary uznają za wiarygodne. Taki model działania zwiększa skuteczność ataku, ponieważ złośliwy kod trafia do ofiar jako część prawidłowo wyglądającej aktualizacji lub zależności.
Analiza techniczna
Z technicznego punktu widzenia kampania opiera się na nadużyciu zaufania do istniejących projektów open source. Po uzyskaniu dostępu do kont maintainerów napastnicy wprowadzają zmiany bezpośrednio do legalnych repozytoriów, co znacząco utrudnia wykrycie incydentu i podnosi wiarygodność zainfekowanych pakietów.
W przejętych projektach umieszczano zaciemnione ładunki JavaScript pełniące funkcję loaderów. Ich zadaniem było pobranie lub odszyfrowanie kolejnych etapów infekcji. Szczególnie niebezpieczny okazał się mechanizm wykorzystujący publiczną infrastrukturę blockchain oraz publiczne interfejsy RPC do pozyskiwania zaszyfrowanych payloadów, co utrudnia filtrowanie ruchu i analizę komunikacji.
Dalszy etap infekcji prowadził do wdrożenia narzędzi DEV#POPPER i OmniStealer. Pierwszy z komponentów działa jako trojan zdalnego dostępu, pozwalając operatorowi utrzymać obecność w systemie i wykonywać polecenia. Drugi odpowiada za kradzież informacji, co w środowisku deweloperskim ma szczególnie wysoką wartość operacyjną.
Celem atakujących mogą być między innymi:
- tokeny do rejestrów pakietów,
- dane dostępowe do repozytoriów Git,
- poświadczenia chmurowe,
- sekrety CI/CD,
- klucze SSH,
- pliki konfiguracyjne i artefakty buildów.
Istotnym elementem techniki ataku było również przepisywanie historii Git tak, aby złośliwe zmiany wyglądały na starsze i mniej podejrzane. Taka manipulacja utrudnia analizę śledczą, opóźnia wykrycie oraz może wprowadzać w błąd zespoły reagowania. W części przypadków kampania rozszerzyła się także na ekosystem Packagist, gdzie loadery ukryto w plikach konfiguracyjnych, zwiększając szanse na przetrwanie po częściowej remediacji.
Konsekwencje / ryzyko
Ryzyko wynikające z takich operacji jest wysokie zarówno dla indywidualnych programistów, jak i dla przedsiębiorstw. Kompromitacja stacji roboczej dewelopera może szybko przełożyć się na przejęcie dostępu do repozytoriów firmowych, systemów budowania, infrastruktury chmurowej oraz mechanizmów podpisywania i publikacji pakietów.
Szczególnie niebezpieczny jest fakt, że atak odbywa się przez legalne, wcześniej zaufane pakiety. Oznacza to, że reputacja projektu, jego popularność czy duża liczba użytkowników nie są już wystarczającymi wskaźnikami bezpieczeństwa. Zagrożenie może dodatkowo rozprzestrzeniać się przez pipeline’y automatycznego buildowania, zależności tranzytywne i lokalne cache pakietów.
Dla organizacji korzystających z open source oznacza to ryzyko naruszenia integralności procesu SDLC, utraty tajemnic przedsiębiorstwa, wycieku kodu źródłowego oraz wprowadzenia backdoora do własnych produktów. Jeśli przejęte zostaną poświadczenia do rejestrów lub systemów CI/CD, atak może zostać wykorzystany także wobec klientów i partnerów.
Rekomendacje
Organizacje powinny traktować instalację podejrzanych wersji pakietów jako potencjalną kompromitację całego środowiska programistycznego, a nie jedynie incydent dotyczący jednej biblioteki. Remediacja powinna być prowadzona z użyciem czystego, odseparowanego systemu administracyjnego, a nie na potencjalnie zainfekowanej stacji roboczej.
Kluczowe działania obronne obejmują:
- ścisłą kontrolę zależności i wersji z użyciem lockfile oraz wewnętrznych mirrorów,
- monitorowanie zmian w krytycznych repozytoriach maintainerów, w tym anomalii w historii commitów, tagach i artefaktach,
- weryfikację integralności pakietów i porównywanie ich zawartości ze stanem repozytorium źródłowego,
- stosowanie MFA dla kont maintainerów, platform Git, rejestrów pakietów i systemów CI/CD,
- rotację wszystkich sekretów, tokenów i kluczy znajdujących się na hostach, które mogły mieć kontakt z podejrzanym pakietem,
- segmentację środowisk deweloperskich i ograniczenie uprawnień dostępu do chmury, rejestrów oraz systemów produkcyjnych,
- wdrożenie telemetryki EDR/XDR na stacjach programistów,
- prowadzenie SBOM i procedur szybkiego mapowania systemów korzystających z określonych wersji komponentów.
Dobrą praktyką pozostaje również regularny przegląd poziomu zaufania do zależności open source, zwłaszcza tych utrzymywanych przez pojedynczych maintainerów lub projektów o nieregularnej aktywności. Wysokie ryzyko należy oceniać nie tylko przez pryzmat popularności pakietu, lecz także modelu utrzymania, przejrzystości procesu release oraz sposobu zarządzania kontami uprzywilejowanymi.
Podsumowanie
Kampania PolinRider potwierdza, że ataki na łańcuch dostaw oprogramowania coraz częściej są wymierzone bezpośrednio w deweloperów i legalne projekty open source. Przejęcie kont maintainerów, ukrywanie loaderów w zaufanych repozytoriach oraz wykorzystywanie publicznej infrastruktury do dostarczania payloadów pokazują wysoki poziom dojrzałości operacyjnej napastników.
Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia punktu ciężkości z prostego skanowania pakietów na pełną ochronę środowisk programistycznych, sekretów i procesów publikacji. W nowoczesnym SDLC bezpieczeństwo open source staje się bezpośrednio bezpieczeństwem całej organizacji.