Tag: DevSecOps

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej uderzają w środowiska CI/CD, ponieważ to właśnie tam przetwarzane są tokeny, sekrety oraz poświadczenia do repozytoriów i usług chmurowych. Najnowszy incydent przypisywany grupie TeamPCP pokazuje, że przejęcie zaufanego elementu pipeline’u może stać się punktem wyjścia do dalszej kompromitacji projektów, narzędzi deweloperskich i infrastruktury organizacji.

W opisywanym przypadku celem były workflowy GitHub Actions utrzymywane przez Checkmarx. Atakujący mieli wykorzystać złośliwy ładunek kradnący dane z runnerów CI, co wpisuje się w rosnący trend nadużywania zaufanych komponentów automatyzacji do przejmowania kolejnych etapów procesu wytwarzania oprogramowania.

W skrócie

• TeamPCP miało skompromitować dwa workflowy GitHub Actions powiązane z Checkmarx.
• Złośliwy kod służył do kradzieży poświadczeń i sekretów z runnerów CI.
• Atak przypomina wcześniejsze działania obserwowane w kampanii związanej z Trivy.
• Napastnicy mogli wykorzystywać przejęte dane do modyfikacji tagów, publikacji skażonych artefaktów i dalszej eksfiltracji informacji.
• Dodatkowym elementem operacji były trojanizowane rozszerzenia publikowane w ekosystemie Open VSX.

Kontekst / historia

Incydent nie wygląda na odosobnione zdarzenie. Z dostępnych analiz wynika, że TeamPCP było wcześniej łączone z kompromitacją innych elementów ekosystemu bezpieczeństwa i DevSecOps, w tym komponentów związanych z Trivy. Wspólne cechy obejmują podobny typ malware kradnącego dane, zbliżony sposób eksfiltracji oraz schemat działania skoncentrowany na środowiskach chmurowych, pipeline’ach buildów i repozytoriach kodu.

W przypadku Checkmarx wskazano dwa projekty GitHub Actions jako dotknięte kompromitacją. Pojawiły się także informacje o przejęciu konta usługowego używanego do publikacji komponentów oraz o wypuszczeniu złośliwych wersji rozszerzeń deweloperskich. Jednocześnie komunikaty producenta sugerowały brak wpływu na dane klientów i środowiska produkcyjne, co nie zmienia faktu, że organizacje korzystające z zagrożonych artefaktów powinny traktować zdarzenie jako pełnoprawny incydent bezpieczeństwa.

Analiza techniczna

Trzonem ataku był złośliwy skrypt typu stealer osadzony w zaufanych akcjach GitHub poprzez manipulację tagami i przekierowanie ich na złośliwe commity. Taka technika jest szczególnie skuteczna w organizacjach, które przypinają zależności CI/CD do tagów wersji zamiast do pełnych identyfikatorów commitów. W efekcie pipeline może uruchomić zmodyfikowaną akcję bez jakichkolwiek zmian widocznych w konfiguracji.

Zadaniem ładunku było pozyskiwanie danych z runnera CI, w tym kluczy SSH, tokenów GitHub, poświadczeń do AWS, Google Cloud i Microsoft Azure, konfiguracji Kubernetes i Dockera, plików środowiskowych oraz innych sekretów używanych w trakcie budowania i testowania oprogramowania. Taki zakres zbieranych informacji sugeruje, że celem operacji nie było tylko przejęcie pojedynczego repozytorium, ale uzyskanie możliwości dalszego poruszania się po infrastrukturze ofiary.

Istotnym elementem było także ukrywanie eksfiltracji danych. Ruch wychodzący miał być kierowany do infrastruktury podszywającej się pod legalny zasób związany z ofiarą, co utrudnia wykrycie podczas pobieżnej analizy logów. Dodatkowo malware mogło tworzyć repozytorium zapasowe z wykorzystaniem tokena ofiary, aby przechowywać wykradzione dane wtedy, gdy bezpośrednia eksfiltracja do serwera kontrolowanego przez napastników nie była możliwa.

Najgroźniejszy był jednak efekt kaskadowy. Jeśli runner CI uruchamiał skażoną akcję i jednocześnie dysponował tokenem z uprawnieniami zapisu do innych repozytoriów, napastnicy mogli wykorzystać przejęte dane do kompromitacji kolejnych projektów. W praktyce taki model prowadzi do samonapędzającego się ataku supply chain, w którym jedno zatrute ogniwo umożliwia skażenie następnych.

Dodatkowym wektorem były zainfekowane rozszerzenia dla środowisk programistycznych publikowane w Open VSX. Po instalacji taki komponent miał sprawdzać obecność poświadczeń do usług chmurowych i platform deweloperskich, a następnie pobierać kolejny etap ładunku. Na systemach niebędących runnerami CI złośliwe oprogramowanie mogło również ustanawiać mechanizm przetrwania, rozszerzając zagrożenie na stacje robocze programistów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego typu incydentu jest utrata integralności zaufanych komponentów procesu wytwarzania oprogramowania. Jeżeli organizacja korzystała z zainfekowanych GitHub Actions lub trojanizowanych rozszerzeń, mogło dojść do wycieku tokenów, kluczy oraz danych dostępowych do środowisk chmurowych i repozytoriów kodu.

Ryzyko nie kończy się na samym wycieku. Przejęte poświadczenia mogą zostać użyte do modyfikacji kodu źródłowego, publikacji złośliwych artefaktów, przejmowania nowych repozytoriów, a nawet uzyskania dostępu do systemów uruchomieniowych. W środowiskach wielochmurowych oraz zintegrowanych z Kubernetes konsekwencje mogą obejmować eskalację do kontroli nad kontenerami, klastrami i usługami produkcyjnymi.

Dodatkowym problemem jest niska wykrywalność takiej operacji. Tradycyjne przeglądy kodu i skanowanie zależności nie zawsze wychwytują kompromitację, jeśli złośliwy kod został wstrzyknięty bezpośrednio do zaufanej akcji u źródła. Organizacja może więc przez dłuższy czas uruchamiać legalnie wyglądający komponent, który poza deklarowaną funkcją potajemnie kradnie sekrety.

Rekomendacje

Organizacje, które mogły korzystać z zagrożonych artefaktów, powinny w pierwszej kolejności przeprowadzić pełną rotację wszystkich sekretów dostępnych dla runnerów CI w okresie potencjalnej kompromitacji. Obejmuje to tokeny GitHub, klucze SSH, dane dostępowe do chmury, sekrety Kubernetes, poświadczenia bazodanowe oraz wartości przechowywane w zmiennych środowiskowych.

• Przejrzeć logi workflowów pod kątem nietypowych połączeń wychodzących, archiwów i nowych repozytoriów tworzonych automatycznie.
• Zweryfikować historię tagów wersji i sprawdzić, czy nie doszło do force-push lub nieautoryzowanych zmian wskaźników.
• Przypinać GitHub Actions do pełnych SHA commitów zamiast do tagów lub ruchomych wersji.
• Ograniczyć uprawnienia tokenów i kont serwisowych zgodnie z zasadą najmniejszych uprawnień.
• Segmentować sieć runnerów oraz ograniczyć ruch wychodzący wyłącznie do zatwierdzonych lokalizacji.
• Monitorować tworzenie nietypowych repozytoriów, publikację nowych artefaktów i rozszerzeń poza zatwierdzonym pipeline’em.
• Sprawdzić stacje deweloperskie pod kątem mechanizmów trwałości i podejrzanych rozszerzeń.

Z perspektywy strategicznej kluczowe jest traktowanie runnerów CI jako systemów uprzywilejowanych o wysokiej wartości. Każdy sekret dostępny podczas builda może mieć skutki wykraczające daleko poza jedno repozytorium, dlatego ochrona integralności pipeline’u powinna być priorytetem zarówno dla zespołów bezpieczeństwa, jak i dla inżynierów platformowych.

Podsumowanie

Incydent przypisywany TeamPCP pokazuje, że nowoczesna kompromitacja łańcucha dostaw nie musi zaczynać się od wykorzystania klasycznej podatności. Wystarczy przejęcie poświadczeń CI i możliwość manipulacji zaufanym artefaktem, aby uruchomić efekt domina obejmujący repozytoria, rozszerzenia deweloperskie i środowiska chmurowe.

Dla organizacji najważniejszą lekcją jest konieczność wdrożenia twardych kontroli integralności, ograniczonych uprawnień, monitoringu anomalii oraz szybkiej rotacji sekretów po każdym podejrzeniu kompromitacji. CI/CD nie może być traktowane wyłącznie jako warstwa automatyzacji — to dziś jeden z najbardziej krytycznych elementów całego krajobrazu bezpieczeństwa.

Źródła

1. The Hacker News — TeamPCP Hacks Checkmarx GitHub Actions Using Stolen CI Credentials
2. Checkmarx — komunikaty i informacje producenta
3. Sysdig — analizy aktywności TeamPCP
4. Wiz — badania dotyczące kompromitacji Checkmarx
5. NVD — wpis dotyczący CVE-2026-33634

Wprowadzenie do problemu / definicja

CanisterWorm to nazwa kampanii destrukcyjnej przypisywanej grupie TeamPCP, w której wykorzystano komponent typu wiper do bezpowrotnego usuwania danych. Operacja zwraca uwagę połączeniem technik typowych dla cyberprzestępczości nastawionej na zysk z selektywnym niszczeniem systemów na podstawie ustawień regionalnych, takich jak strefa czasowa Iranu czy domyślny język perski.

To ważny przykład zmiany charakteru zagrożeń w środowiskach chmurowych i kontenerowych. Ataki nie kończą się już wyłącznie na kradzieży poświadczeń, eksfiltracji danych lub wymuszeniu okupu, ale coraz częściej obejmują również działania sabotażowe nastawione na trwałe zniszczenie zasobów.

W skrócie

Kampania CanisterWorm została zaobserwowana w marcu 2026 roku i jest łączona z grupą TeamPCP, znaną z automatyzacji ataków na źle zabezpieczone usługi chmurowe. W przeszłości aktor ten koncentrował się na przejmowaniu środowisk z wystawionymi interfejsami Docker API, klastrami Kubernetes, serwerami Redis oraz na wykorzystywaniu podatności takich jak React2Shell.

W najnowszej odsłonie operatorzy wdrożyli ładunek destrukcyjny, który aktywował się po wykryciu powiązania systemu z Iranem. Jeśli malware uznał środowisko za zgodne z określonym profilem, uruchamiał proces usuwania danych lokalnie lub na poziomie całego klastra Kubernetes.

• Kampania łączy elementy kradzieży danych, utrzymania dostępu i destrukcji.
• Selekcja ofiar odbywa się m.in. na podstawie ustawień regionalnych systemu.
• Ryzyko szczególnie dotyczy środowisk cloud-native i słabo zabezpieczonych usług administracyjnych.

Kontekst / historia

TeamPCP pojawił się pod koniec 2025 roku jako grupa działająca przede wszystkim w modelu cloud-first. Zamiast koncentrować się na stacjach roboczych użytkowników, atakujący skupiali uwagę na publicznie dostępnym zapleczu infrastrukturalnym, w tym na błędnie skonfigurowanych usługach administracyjnych oraz elementach orkiestracji kontenerów.

Z czasem działalność grupy zaczęła obejmować kilka równoległych celów: budowę botnetu, przejmowanie infrastruktury, kradzież poświadczeń, eksfiltrację danych i wymuszenia. Kampania CanisterWorm wpisuje się w tę ewolucję, ale idzie krok dalej, ponieważ końcowym etapem może być trwałe niszczenie danych.

Istotnym tłem dla tej operacji są wcześniejsze incydenty związane z kompromitacją łańcucha dostaw. Pojawiły się informacje o złośliwych modyfikacjach dystrybuowanych przez komponenty powiązane z narzędziami Trivy i KICS, których celem miała być kradzież kluczy SSH, poświadczeń chmurowych, tokenów Kubernetes oraz innych sekretów. To pokazuje, że TeamPCP nie ogranicza się do prostego skanowania internetu pod kątem błędnych konfiguracji, ale potrafi również zwiększać skalę działania poprzez naruszenie zaufanych kanałów dostarczania oprogramowania.

Analiza techniczna

Od strony technicznej kampania opiera się na znanych, ale skutecznie zautomatyzowanych metodach. TeamPCP wykorzystuje skrypty i narzędzia do masowego wyszukiwania podatnych lub niewłaściwie skonfigurowanych usług, a następnie wdraża komponenty odpowiedzialne za utrzymanie dostępu, ruch boczny, tunelowanie oraz dalsze skanowanie internetu.

W analizach aktywności grupy wskazywano m.in. na nadużywanie wystawionych Docker API, serwerów Redis, dashboardów Ray oraz podatności React2Shell. To zestaw technik szczególnie groźnych dla organizacji, które intensywnie korzystają z konteneryzacji, automatyzacji i rozproszonych środowisk uruchomieniowych.

Najważniejszym elementem CanisterWorm był jednak warunkowo aktywowany ładunek destrukcyjny. Mechanizm sprawdzał ustawienia regionalne systemu, zwłaszcza strefę czasową oraz konfigurację językową. Jeśli host odpowiadał profilowi ofiary powiązanej z Iranem, malware inicjowało proces wymazywania danych.

W przypadku uzyskania dostępu do klastra Kubernetes skutki mogły wykraczać poza pojedynczą maszynę. Zniszczenie mogło objąć wiele węzłów, wolumenów i usług, co oznacza przejście od incydentu ograniczonego do jednego hosta do sabotażu na poziomie całego środowiska kontenerowego.

Dodatkowo infrastruktura grupy miała wykorzystywać tzw. canistery oparte na Internet Computer Protocol do orkiestracji kampanii i hostowania złośliwych komponentów. Z perspektywy obrony ma to znaczenie praktyczne, ponieważ rozproszony model publikacji utrudnia szybkie wyłączenie infrastruktury i osłabia skuteczność klasycznych działań typu takedown. Atakujący mieli też dynamicznie modyfikować ładunki i tymczasowo usuwać je z dystrybucji, co utrudnia analizę oraz oszacowanie pełnej skali kompromitacji.

Wzorzec działania sugeruje więc nie pojedynczy malware, lecz szerszy ekosystem operacyjny obejmujący kilka etapów:

• uzyskanie dostępu do infrastruktury,
• kradzież poświadczeń i sekretów,
• utrzymanie trwałości w środowisku,
• eksfiltrację danych,
• uruchomienie komponentu destrukcyjnego jako etapu końcowego.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii jest ryzyko nieodwracalnej utraty danych. W środowiskach Kubernetes konsekwencje mogą objąć jednocześnie wiele węzłów, wolumenów i usług, co przekłada się na długotrwałe przestoje operacyjne, utratę integralności danych oraz kosztowny proces odtwarzania.

Jeśli przed uruchomieniem wipera doszło do kradzieży poświadczeń, organizacja może jednocześnie mierzyć się z dwiema kategoriami incydentu: zniszczeniem systemów i wtórnym wykorzystaniem wykradzionych sekretów. Taki scenariusz znacząco komplikuje reakcję, ponieważ samo odtworzenie środowiska nie eliminuje ryzyka dalszych nadużyć.

Dla organizacji korzystających z pipeline’ów CI/CD oraz zautomatyzowanego pobierania artefaktów zagrożenie ma dodatkowy wymiar. Kompromitacja narzędzia bezpieczeństwa lub skanera może stać się wektorem wejścia do środowiska produkcyjnego, co podważa tradycyjne założenie wysokiego zaufania do narzędzi DevSecOps.

Podwyższone ryzyko dotyczy szczególnie organizacji, które:

• eksponują usługi administracyjne bez silnego uwierzytelniania i segmentacji,
• przechowują sekrety w pipeline’ach w sposób niewystarczająco chroniony,
• nie ograniczają uprawnień dla mechanizmów automatyzacji, takich jak workflow CI/CD,
• nie monitorują aktywności w klastrach Kubernetes pod kątem anomalii destrukcyjnych,
• nie posiadają przetestowanych kopii zapasowych odpornych na manipulację przez napastnika.

Rekomendacje

W pierwszej kolejności organizacje powinny przeprowadzić przegląd ekspozycji usług chmurowych i kontenerowych. Wystawione Docker API, niezabezpieczone panele zarządzania, otwarte Redisy oraz publicznie dostępne interfejsy orkiestracji powinny zostać natychmiast zidentyfikowane, ograniczone sieciowo lub wyłączone.

W środowiskach Kubernetes warto zweryfikować uprawnienia kont serwisowych, rotację tokenów, polityki RBAC oraz możliwość wykonywania operacji destrukcyjnych przez nieautoryzowane workloady. Szczególne znaczenie ma wdrożenie zasady najmniejszych uprawnień oraz segmentacja dostępu między komponentami środowiska.

Drugim filarem obrony powinno być bezpieczeństwo łańcucha dostaw oprogramowania. Dobre praktyki obejmują:

• pinowanie wersji zależności i akcji CI/CD,
• weryfikację integralności artefaktów,
• ograniczenie uprawnień tokenów wykorzystywanych przez workflow,
• monitorowanie nieautoryzowanych zmian w repozytoriach i pipeline’ach,
• regularny przegląd zaufanych źródeł oprogramowania i automatyzacji.

Na poziomie detekcji należy zwiększyć widoczność telemetryczną dla zdarzeń, które mogą wskazywać na przygotowanie lub realizację ataku destrukcyjnego:

• masowe kasowanie plików i wolumenów,
• nietypowe operacje wobec API Kubernetes,
• pobieranie skryptów z niezaufanych lokalizacji podczas działania kontenerów,
• uruchamianie narzędzi tunelujących i proxy,
• nagłe zmiany konfiguracji językowej, regionalnej lub środowiskowej wykorzystywanej do selekcji ofiar.

Niezbędne są również kopie zapasowe odseparowane logicznie lub fizycznie od produkcji oraz regularnie testowane pod kątem odtwarzania pełnych środowisk kontenerowych. Sam backup nie wystarczy, jeśli napastnik może usunąć snapshoty, zaszyfrować repozytorium kopii albo wykorzystać skradzione poświadczenia do sabotażu procesu odzyskiwania.

Podsumowanie

CanisterWorm pokazuje, że współczesne kampanie wymierzone w infrastrukturę chmurową coraz częściej łączą automatyzację, kompromitację łańcucha dostaw, kradzież sekretów i destrukcyjne payloady. TeamPCP nie musi stosować przełomowych technik, aby osiągać wysoki poziom skuteczności — wystarczy industrializacja znanych metod oraz ich sprawne skalowanie w środowiskach cloud-native.

Dla obrońców najważniejszy wniosek jest jednoznaczny: bezpieczeństwo chmury i kontenerów wymaga nie tylko ochrony perymetru, ale także ścisłej kontroli pipeline’ów, ograniczania zaufania do zależności oraz gotowości do szybkiego odtworzenia środowiska po incydencie destrukcyjnym.

Źródła

1. Krebs on Security — CanisterWorm Springs Wiper Attack Targeting Iran — https://krebsonsecurity.com/2026/03/canisterworm-springs-wiper-attack-targeting-iran/
2. Flare — Threat Alert: TeamPCP, An Emerging Force — https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware
3. Wiz — TeamPCP actor profile — https://threats.wiz.io/all-actors/teampcp