Co znajdziesz w tym artykule?
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
- Krebs on Security — CanisterWorm Springs Wiper Attack Targeting Iran — https://krebsonsecurity.com/2026/03/canisterworm-springs-wiper-attack-targeting-iran/
- Flare — Threat Alert: TeamPCP, An Emerging Force — https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware
- Wiz — TeamPCP actor profile — https://threats.wiz.io/all-actors/teampcp