Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowa kampania przypisywana grupie TeamPCP pokazuje, że środowiska kontenerowe i klastry Kubernetes stały się pełnoprawnym celem operacji o charakterze sabotażowym. Atakujący wykorzystują złośliwy skrypt, który w określonych warunkach działa jak wiper, czyli narzędzie służące do nieodwracalnego niszczenia danych oraz unieruchamiania systemów.
Najbardziej niepokojącym elementem tej operacji jest selektywny charakter ataku. Malware analizuje cechy systemu ofiary i w przypadku wykrycia powiązań z Iranem uruchamia ładunek destrukcyjny, natomiast w innych środowiskach koncentruje się na utrzymaniu trwałego dostępu.
W skrócie
Kampania TeamPCP łączy kilka klas zagrożeń w jednym łańcuchu ataku: backdoor, ruch lateralny oraz destrukcję danych. Z analizy wynika, że operatorzy wykorzystują elementy infrastruktury i wzorce techniczne kojarzone z wcześniejszą aktywnością tej grupy.
- Malware sprawdza strefę czasową i lokalizację systemu.
- W środowiskach powiązanych z Iranem wdrażany jest wariant niszczący dane.
- W pozostałych przypadkach instalowany jest trwały backdoor na hostach.
- Kubernetes jest wykorzystywany jako mechanizm masowego wdrożenia ładunku na wielu węzłach jednocześnie.
Taki model działania pokazuje połączenie klasycznej kompromitacji infrastruktury chmurowej z geopolitycznie ukierunkowaną destrukcją.
Kontekst / historia
TeamPCP była już wcześniej wiązana z incydentami dotyczącymi komponentów łańcucha dostaw oraz z kampanią określaną jako CanisterWorm. Najnowsza aktywność wskazuje jednak na istotną zmianę taktyki: od samego uzyskiwania dostępu i utrzymywania obecności w środowisku do wdrażania ładunków nastawionych na sabotaż.
Znaczenie tej kampanii wynika również z tego, że atakujący poruszają się pomiędzy kilkoma warstwami infrastruktury jednocześnie. Obejmują hosta, środowisko kontenerowe i mechanizmy orkiestracji, a przy tym nie stosują jednego schematu wobec wszystkich ofiar. Logika działania opiera się na cechach systemu, co utrudnia wykrycie i ocenę ryzyka na wczesnym etapie incydentu.
Analiza techniczna
Złośliwy kod analizuje środowisko ofiary i sprawdza, czy system spełnia kryteria związane z irańską strefą czasową oraz lokalizacją. Jeśli oba warunki są spełnione i w środowisku obecny jest Kubernetes, malware wdraża DaemonSet w systemowej przestrzeni nazw. Taki mechanizm umożliwia uruchomienie kontenera na każdym węźle klastra, co czyni go wyjątkowo skutecznym narzędziem do skalowalnego sabotażu.
Uruchamiane kontenery działają z podwyższonymi uprawnieniami i montują główny system plików hosta do katalogu wewnątrz kontenera. To oznacza, że atak nie zatrzymuje się na warstwie kontenerowej, lecz uzyskuje bezpośredni dostęp do systemu gospodarza. Następnie malware usuwa katalogi najwyższego poziomu na hoście i wymusza restart maszyny, co prowadzi do trwałego uszkodzenia systemu operacyjnego oraz utraty danych.
Jeżeli Kubernetes jest dostępny, ale system nie spełnia warunków geograficznych, wdrażany jest alternatywny DaemonSet. W tym wariancie celem nie jest natychmiastowa destrukcja, lecz persistence. Na hoście zapisywany jest pythonowy backdoor, a następnie instalowany jako usługa systemd, co zapewnia utrzymanie dostępu po restarcie.
W scenariuszach bez Kubernetes malware nadal może działać destrukcyjnie. Gdy wykryje system powiązany z Iranem, podejmuje próbę usuwania plików dostępnych dla bieżącego użytkownika, w tym danych systemowych. Jeśli nie ma wystarczających uprawnień, próbuje wykorzystać konfiguracje pozwalające na bezhasłowe sudo.
Badacze opisali także nowszy wariant, w którym ograniczono wykorzystanie ruchu lateralnego opartego na Kubernetes, a większy nacisk położono na propagację przez SSH. W tym modelu malware analizuje logi uwierzytelniania, wyszukuje poprawne dane dostępu i wykorzystuje przejęte klucze prywatne, co sugeruje orientację na szybkie rozszerzanie zasięgu infekcji w infrastrukturze hybrydowej.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tej kampanii jest ryzyko całkowitej utraty dostępności systemów i danych na poziomie hostów klastra. W przeciwieństwie do incydentów ograniczonych do pojedynczych kontenerów, tutaj skutki mogą objąć cały węzeł, a dzięki wykorzystaniu DaemonSetów nawet wszystkie węzły w klastrze.
W praktyce oznacza to możliwość jednoczesnego unieruchomienia usług produkcyjnych, pipeline’ów CI/CD, systemów przetwarzania danych oraz komponentów aplikacji rozproszonych. Dodatkowym problemem jest to, że organizacje spoza profilu geopolitycznego mogą nie doświadczyć natychmiastowego zniszczenia, lecz zostać wykorzystane jako platforma do dalszych operacji, eksfiltracji danych albo przyszłego sabotażu.
Ryzyko zwiększa używanie uprzywilejowanych kontenerów, montowanie systemu plików hosta oraz możliwość wykorzystania niechronionego API Dockera. To klasyczne oznaki niewystarczającego hardeningu środowisk cloud-native, nadmiernych uprawnień oraz słabej segmentacji. Jeśli organizacja nie monitoruje tworzenia DaemonSetów, zmian w przestrzeniach nazw systemowych i nietypowych operacji hostowych inicjowanych z kontenerów, incydent może zostać wykryty dopiero po faktycznym zniszczeniu infrastruktury.
Rekomendacje
Organizacje korzystające z Kubernetes powinny ograniczyć możliwość uruchamiania uprzywilejowanych kontenerów i montowania hostPath do absolutnego minimum. Tworzenie DaemonSetów w przestrzeniach nazw systemowych powinno podlegać ścisłej kontroli RBAC, formalnemu zatwierdzaniu zmian oraz alertowaniu w czasie rzeczywistym.
Warto wdrożyć polityki bezpieczeństwa kontenerów blokujące:
- kontenery działające w trybie privileged,
- montowanie głównego systemu plików hosta,
- nadmierne capabilities procesów,
- dostęp do nieautoryzowanego API Dockera,
- tworzenie lub modyfikowanie usług systemowych na hostach przez procesy pochodzące z kontenerów.
W warstwie detekcji należy monitorować:
- nowe DaemonSety w kube-system,
- nietypowe obrazy uruchamiane z wysokimi uprawnieniami,
- połączenia wychodzące SSH z osłabioną walidacją hosta,
- ruch do portu 2375 w sieci lokalnej,
- zapisy plików wykonywalnych lub skryptów Pythona na hostach,
- zmiany w usługach systemd na węzłach klastra,
- operacje masowego usuwania plików i wymuszone restarty hostów.
Z perspektywy operacyjnej konieczne jest również wyłączenie bezhasłowego sudo tam, gdzie nie jest to niezbędne, rotowanie kluczy SSH, centralne zarządzanie tożsamością, segmentacja sieci między węzłami i serwerami zarządzającymi, wdrożenie EDR lub XDR na hostach oraz utrzymywanie offline’owych i regularnie testowanych kopii zapasowych.
W środowiskach podwyższonego ryzyka szczególnie użyteczne będą reguły korelacyjne łączące kilka wskaźników jednocześnie, takich jak utworzenie DaemonSetu, uruchomienie uprzywilejowanego kontenera, montowanie katalogu głównego hosta oraz wykonanie poleceń destrukcyjnych.
Podsumowanie
Kampania TeamPCP pokazuje, że Kubernetes przestaje być wyłącznie celem przejęcia i coraz częściej staje się narzędziem do szybkiego, zautomatyzowanego sabotażu. Wykorzystanie DaemonSetów, uprzywilejowanych kontenerów i dostępu do systemu plików hosta pozwala przenieść skutki incydentu z poziomu pojedynczego kontenera na poziom całego klastra.
Selektywny, geopolitycznie ukierunkowany charakter ładunku destrukcyjnego dodatkowo podkreśla, że współczesne kampanie wymierzone w infrastrukturę cloud-native coraz częściej łączą cyberprzestępczość, działania wywiadowcze i element sabotażu. Dla zespołów bezpieczeństwa oznacza to potrzebę wzmocnienia hardeningu, monitorowania aktywności na hostach oraz przygotowania procedur reagowania na incydenty o charakterze wiperowym.