Wprowadzenie do problemu / definicja
TeamPCP to nazwa przypisywana podmiotowi zagrożeń, który przez lata rozwijał kampanie wymierzone w publicznie dostępne usługi, środowiska kontenerowe oraz elementy nowoczesnego łańcucha dostaw oprogramowania. Najnowsze ustalenia sugerują, że aktywność tej grupy mogła rozpocząć się już w 2020 roku od ataków na źle zabezpieczone serwery Redis, a następnie rozszerzyć się na infrastrukturę cloud-native i procesy CI/CD.
To istotny przykład ewolucji cyberzagrożeń: od prostych infekcji pojedynczych hostów do wieloetapowych operacji, które mogą obejmować botnety, koparki kryptowalut, kradzież danych oraz działania destrukcyjne.
W skrócie
- Badacze łączą TeamPCP z kampaniami przeciwko Redis obserwowanymi od 2020 roku.
- W kolejnych latach aktor miał rozszerzyć operacje na środowiska Ray, Docker, React i Kubernetes.
- Analiza wskazuje na spójność infrastruktury, metod działania i technik wdrażania malware.
- Złośliwe narzędzia obejmują nie tylko koparki i botnety, ale również komponenty destrukcyjne oraz mechanizmy samoistnej propagacji.
- Najpoważniejsze ryzyko dotyczy kompromitacji łańcucha dostaw oprogramowania i nadużyć w pipeline’ach deweloperskich.
Kontekst / historia
Z dostępnych analiz wynika, że TeamPCP nie musi być całkowicie nowym aktorem, lecz raczej kontynuacją wcześniej funkcjonującego ekosystemu operacyjnego. Jednym z najważniejszych punktów odniesienia są historyczne kampanie przeciwko nieprawidłowo zabezpieczonym instancjom Redis, które już kilka lat temu były wykorzystywane do dostarczania złośliwego oprogramowania.
W drugiej połowie 2025 roku badacze zaobserwowali operacje powiązywane z tym samym zapleczem. Jedna z nich miała koncentrować się na przejmowaniu infrastruktury AI i budowie samoreplikującego się botnetu, a druga na infekowaniu serwerów Redis w celu wdrażania koparek kryptowalut. Z czasem zakres działań rozszerzono także na komponenty aplikacyjne i środowiska cloud-native, co wskazuje na systematyczny rozwój kompetencji operacyjnych.
Analiza techniczna
Najważniejszy wniosek z analizy technicznej dotyczy ciągłości działań na przestrzeni kilku lat. Korelacja obejmuje nakładające się domeny, elementy infrastruktury backendowej, schematy uwierzytelniania, aktywność reverse shelli, techniki stagingu oraz podobny model wdrażania ładunków. To sugeruje, że kampanie wymierzone w Redis, późniejsze działania w środowiskach Ray i Docker oraz ataki supply chain mogą być elementami jednej linii rozwoju zagrożenia.
Model działania opierał się na wyszukiwaniu publicznie dostępnych usług, wykorzystywaniu znanych podatności lub błędów konfiguracyjnych oraz automatyzacji kolejnych etapów kompromitacji. W praktyce oznacza to szybkie skanowanie internetu, uzyskanie dostępu do hosta, wdrożenie malware, a następnie wykorzystanie przejętego systemu do dalszego skanowania i propagacji.
Szczególną uwagę zwraca ewolucja narzędzi używanych po uzyskaniu dostępu do środowisk Kubernetes. Wskazywany skrypt w Pythonie, określany jako „kube.py”, miał początkowo służyć utrzymaniu dostępu i rozprzestrzenianiu się w klastrze. Nowsze warianty rozszerzono jednak o funkcje destrukcyjne. W analizowanych przypadkach kod sprawdzał konfigurację strefy czasowej ofiary i w zależności od wyniku uruchamiał odmienny scenariusz, obejmujący dodatkowe tylne wejście, komponent robakowy lub działania typu wiper prowadzące do niszczenia danych i węzłów klastra.
Rozwój w kierunku ataków supply chain wpisuje się w ten sam schemat. Zamiast ograniczać się do pojedynczych serwerów, atakujący mieli zacząć wykorzystywać zależności obecne w nowoczesnym procesie tworzenia oprogramowania. Kompromitacja tokenów, nadużycia w systemach automatyzacji oraz zatrucie popularnych bibliotek open source umożliwiają osiągnięcie znacznie większej skali infekcji niż klasyczny atak na pojedynczy host.
Konsekwencje / ryzyko
Skutki takich operacji są wielowarstwowe. Na poziomie infrastruktury zagrożone są organizacje, które wystawiają do internetu usługi Redis, platformy kontenerowe, klastry Kubernetes lub komponenty chmurowe bez odpowiedniego hardeningu. Efektem może być przejęcie zasobów obliczeniowych, instalacja koparek kryptowalut, uruchomienie botnetu, eksfiltracja danych albo wdrożenie destrukcyjnego malware.
Na poziomie operacyjnym szczególnie groźna jest automatyzacja oraz zdolność do samoistnej propagacji. Skraca to czas od wykrycia podatnego systemu do pełnej kompromitacji i zwiększa liczbę ofiar w krótkim okresie. W środowiskach kontenerowych konsekwencje mogą obejmować przejęcie całych klastrów, lateral movement między przestrzeniami roboczymi oraz trwałe osadzenie złośliwych komponentów w pipeline’ach deweloperskich.
Najpoważniejsze ryzyko dotyczy jednak łańcucha dostaw oprogramowania. Jeśli atakujący przejmie bibliotekę, repozytorium, token automatyzacji lub proces budowania, złośliwy kod może zostać przeniesiony dalej do klientów, partnerów i użytkowników końcowych. Tego typu incydenty są trudniejsze do wykrycia i często mają znacznie większy promień oddziaływania niż tradycyjne naruszenia pojedynczej infrastruktury.
Rekomendacje
Organizacje powinny przede wszystkim ograniczyć ekspozycję usług administracyjnych i bazodanowych do internetu. Redis, interfejsy orkiestratorów, panele zarządzania kontenerami oraz narzędzia deweloperskie nie powinny być publicznie dostępne bez silnego uwierzytelniania, segmentacji sieci i filtrowania ruchu.
- wyłączyć zbędną ekspozycję usług i portów,
- wdrożyć rotację kluczy oraz tokenów dostępowych,
- stosować zasadę najmniejszych uprawnień,
- monitorować uruchamiane kontenery, zadania i DaemonSety,
- kontrolować integralność obrazów oraz artefaktów buildów,
- wymuszać MFA dla repozytoriów i systemów automatyzacji,
- zabezpieczać sekrety wykorzystywane w pipeline’ach CI/CD,
- walidować zależności open source przed wdrożeniem do produkcji.
Z perspektywy detekcji warto monitorować nietypowe procesy na hostach Redis i Docker, podejrzane reverse shelle, masowe pobieranie i uruchamianie skryptów Python, tworzenie nowych zasobów wykonawczych w Kubernetes, nagłe wzrosty użycia CPU oraz połączenia wychodzące do nieznanej infrastruktury sterującej. Zespoły bezpieczeństwa powinny też regularnie prowadzić threat hunting pod kątem oznak automatycznej propagacji, nadużyć tokenów i zmian w łańcuchu dostaw pakietów.
Podsumowanie
Przypadek TeamPCP pokazuje, że współczesne grupy cyberprzestępcze rozwijają swoje operacje stopniowo, przez wiele lat, przechodząc od oportunistycznych ataków na źle zabezpieczone usługi do bardziej zaawansowanych kampanii obejmujących środowiska cloud-native i supply chain. To już nie tylko problem pojedynczych serwerów, ale całych ekosystemów wytwarzania i dostarczania oprogramowania.
Dla obrońców najważniejszy wniosek jest praktyczny: słabo zabezpieczona infrastruktura internetowa, nadmiernie uprzywilejowane tokeny i niewystarczająco monitorowane pipeline’y deweloperskie tworzą wspólną powierzchnię ataku. Ograniczenie ekspozycji, kontrola tożsamości maszynowych i higiena łańcucha dostaw powinny być dziś traktowane jako jeden spójny program bezpieczeństwa.