TeamPCP atakuje Kubernetes: destrukcyjny malware wymierzony w środowiska powiązane z Iranem

securitybeztabu.pl 19 godzin temu

Wprowadzenie do problemu / definicja

Nowa kampania przypisywana grupie TeamPCP pokazuje, iż zagrożenia dla środowisk chmurowych i kontenerowych wchodzą w bardziej agresywną fazę. Analizowany malware potrafi rozpoznać, czy działa w infrastrukturze Kubernetes, a następnie sprawdza ustawienia lokalizacyjne systemu, takie jak strefa czasowa i konfiguracja językowa.

Jeżeli host lub klaster wygląda na skonfigurowany dla Iranu, złośliwe oprogramowanie przechodzi do trybu destrukcyjnego i usuwa dane. W innych przypadkach koncentruje się na utrzymaniu dostępu, instalując backdoor na węzłach i przygotowując środowisko do dalszej eksploatacji.

W skrócie

TeamPCP wykorzystuje Kubernetes do szybkiego rozprzestrzeniania malware na wszystkie węzły klastra.
Wariant ukierunkowany na Iran wdraża wiper usuwający dane z hostów i wymuszający restart systemu.
W środowiskach niespełniających warunków geolokalizacyjnych malware instaluje trwały backdoor jako usługę systemd.
Nowsze warianty rozszerzają propagację przez SSH oraz nieautoryzowane API Dockera na porcie 2375.

Kontekst / historia

TeamPCP była już wcześniej łączona z aktywnością wymierzoną w środowiska cloud-native, w tym źle zabezpieczone instancje Dockera, klastry Kubernetes oraz elementy łańcucha dostaw. Najnowsza kampania wpisuje się w ten model, ale wyróżnia się selektywnym komponentem destrukcyjnym zależnym od kontekstu geograficznego i systemowego.

To istotna zmiana w sposobie działania aktora zagrożeń. Zamiast ograniczać się do kradzieży danych lub utrzymywania przyczółka, operatorzy łączą rozpoznanie środowiska z decyzją o całkowitym zniszczeniu hosta lub klastra. Taki model zwiększa ryzyko dla organizacji działających w regionach napięć geopolitycznych oraz dla firm utrzymujących rozproszone środowiska o zróżnicowanych ustawieniach regionalnych.

Analiza techniczna

Punkt wejścia kampanii stanowi skrypt typu stager, który może pobrać narzędzie administracyjne do obsługi klastra, a następnie uruchamia kolejny komponent napisany w Pythonie. Już na tym etapie widać, iż operatorzy zakładają możliwość wykonywania poleceń administracyjnych wobec hosta lub środowiska kontenerowego.

Logika działania opiera się na dwóch głównych testach. Pierwszy ma ustalić, czy kod działa w Kubernetes, na przykład poprzez obecność artefaktów typowych dla podów lub kont serwisowych. Drugi test sprawdza, czy system jest skonfigurowany dla Iranu, analizując strefę czasową taką jak Asia/Tehran oraz ustawienia lokalizacyjne w rodzaju fa_IR.

Na tej podstawie malware wybiera jedną z kilku ścieżek działania:

Kubernetes i środowisko powiązane z Iranem: wdrożenie destrukcyjnego DaemonSetu na wszystkich węzłach.
Kubernetes bez dopasowania do Iranu: instalacja backdoora na wszystkich węzłach.
Brak Kubernetes i dopasowanie do Iranu: lokalne niszczenie plików na hoście.
Brak Kubernetes i brak dopasowania: zakończenie działania bez dalszych efektów.

Najbardziej niebezpieczny wariant wykorzystuje DaemonSet wdrażany w przestrzeni kube-system. Kontener działa w trybie uprzywilejowanym i uzyskuje dostęp do systemu plików hosta poprzez montowanie hostPath. Taka konfiguracja pozwala wykonywać operacje bezpośrednio na węźle, w tym usuwać dane z kluczowych katalogów, a następnie wymuszać restart maszyny. Zastosowanie DaemonSetu oznacza, iż pojedynczy manifest może doprowadzić do zniszczenia wszystkich węzłów klastra, również tych odpowiedzialnych za control plane.

W wariancie niedestrukcyjnym malware również korzysta z uprzywilejowanego kontenera i dostępu do systemu plików hosta, ale zamiast kasować dane instaluje backdoor i rejestruje go jako usługę systemd. Mechanizm trwałości maskowany jest nazwami przypominającymi legalne komponenty monitorujące lub narzędzia związane z bazami danych, co utrudnia jego wykrycie podczas rutynowego przeglądu systemu.

Badacze opisali także nowszy wariant kampanii, który rozszerza propagację poza sam Kubernetes. Malware analizuje logi uwierzytelnienia SSH, wyszukuje informacje o poprawnych logowaniach, pozyskuje nazwy użytkowników i adresy IP, a następnie próbuje wykorzystywać znalezione klucze prywatne do ruchu lateralnego. Dodatkowym kanałem jest skanowanie sieci lokalnej pod kątem wystawionego API Dockera na porcie 2375 i tworzenie uprzywilejowanych kontenerów z montowaniem katalogu głównego hosta.

Konsekwencje / ryzyko

Dla organizacji korzystających z Kubernetes najpoważniejszym skutkiem może być natychmiastowa utrata całego klastra. Ponieważ malware wykorzystuje legalne mechanizmy orkiestratora i uprzywilejowane kontenery, jego działania mogą początkowo wyglądać jak zwykła operacja administracyjna lub automatyzacja infrastruktury.

trwałe usunięcie danych z hostów i lokalnych wolumenów,
przestój środowisk produkcyjnych i usług zależnych,
utrata kontroli nad węzłami przez instalację trwałego backdoora,
ruch lateralny do innych serwerów przez SSH,
kompromitacja hostów z niechronionym API Dockera,
utrudniona detekcja z powodu nazw podszywających się pod legalne usługi.

Szczególnie niebezpieczne jest połączenie selektywnego wipera z mechanizmami persistence. Ten sam zestaw narzędzi może działać jako broń destrukcyjna wobec jednych ofiar, a wobec innych jako platforma do długotrwałego utrzymania dostępu. Dla zespołów bezpieczeństwa oznacza to konieczność oceny nie tylko samego kodu, ale również kontekstu środowiskowego i operacyjnego.

Rekomendacje

Organizacje utrzymujące środowiska Kubernetes i infrastrukturę kontenerową powinny potraktować tę kampanię jako sygnał ostrzegawczy i przeprowadzić weryfikację podstawowych mechanizmów bezpieczeństwa.

przejrzeć wszystkie DaemonSety w przestrzeni kube-system i zweryfikować, czy nie istnieją nieautoryzowane obiekty,
wykrywać kontenery uprzywilejowane oraz przypadki użycia hostPath z montowaniem systemu hosta,
ograniczyć możliwość tworzenia i modyfikacji DaemonSetów poprzez ścisłe RBAC,
zablokować publiczną ekspozycję API Dockera, zwłaszcza na porcie 2375,
przeanalizować logi SSH pod kątem nietypowych połączeń i oznak ruchu lateralnego,
zweryfikować obecność podejrzanych usług systemd i plików podszywających się pod narzędzia administracyjne,
wdrożyć polityki bezpieczeństwa dla kontenerów i mechanizmy admission control blokujące manifesty z nadmiernymi uprawnieniami,
przygotować i regularnie testować procedury odtworzeniowe dla klastrów oraz kopie zapasowe danych i konfiguracji.

W środowiskach, które mogą być już skompromitowane, nie wystarczy usunięcie pojedynczego poda lub kontenera. Konieczna jest pełna analiza hostów, rotacja kluczy SSH, weryfikacja sekretów oraz odbudowa zaufanej podstawy środowiska.

Podsumowanie

Kampania TeamPCP to przykład nowoczesnego malware ukierunkowanego na środowiska cloud-native, który łączy rozpoznanie, automatyczną propagację, trwałość i funkcję wipera. Najważniejszą cechą tej operacji jest selektywność: kod podejmuje decyzję o zniszczeniu lub utrzymaniu dostępu na podstawie konfiguracji systemu i przesłanek geograficznych.

Dla obrońców oznacza to, iż bezpieczeństwo Kubernetes nie może być analizowane wyłącznie przez pryzmat podatności i błędnych konfiguracji. Coraz większe znaczenie ma monitorowanie nieautoryzowanych DaemonSetów, kontrola nad uprzywilejowanymi kontenerami oraz eliminacja otwartych interfejsów administracyjnych, zanim staną się one punktem wyjścia do pełnoskalowego incydentu.