Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki typu software supply chain należą dziś do najgroźniejszych zagrożeń dla organizacji rozwijających i wdrażających oprogramowanie. Ich celem jest przejęcie zaufanych elementów ekosystemu — pakietów, obrazów kontenerowych, rozszerzeń IDE, akcji CI/CD czy mechanizmów publikacji — tak, aby złośliwy kod został uruchomiony jako część legalnego procesu build, testów lub wdrożenia.
Najnowsza kampania przypisywana grupie TeamPCP pokazuje, że taki model działania może być prowadzony równolegle w wielu popularnych ekosystemach open source. Zamiast pojedynczego incydentu obserwujemy rozbudowaną operację wymierzoną w narzędzia używane przez programistów, zespoły DevOps i środowiska chmurowe.
W skrócie
TeamPCP miało rozszerzyć działalność z incydentu wokół Trivy do szerokiej kampanii obejmującej Docker Hub, OpenVSX i VS Code, NPM oraz PyPI. Wspólnym celem była przede wszystkim kradzież sekretów, w tym tokenów publikacyjnych, kluczy API, poświadczeń chmurowych i danych dostępowych do CI/CD.
Szczególnie niebezpieczne okazało się manipulowanie tagami GitHub Actions bez zmiany ich nazwy. Taki mechanizm pozwalał ofiarom nadal korzystać z pozornie tej samej wersji komponentu, podczas gdy w rzeczywistości uruchamiany był złośliwy kod.
- atak obejmował wiele ekosystemów jednocześnie,
- głównym wektorem były przejęte tokeny i zaufane kanały dystrybucji,
- malware działało obok legalnego kodu, utrudniając wykrycie,
- w części przypadków pojawiły się funkcje samopropagacji i wariant destrukcyjny.
Kontekst / historia
Początek kampanii wiązany jest z incydentem dotyczącym Trivy, popularnego skanera podatności używanego w bezpieczeństwie aplikacji i kontenerów. Według opisu zdarzeń kompromitacja miała rozpocząć się pod koniec lutego 2026 roku, gdy atakujący uzyskali dostęp do tokenu pozwalającego na ingerencję w proces publikacji i dystrybucji artefaktów.
Z czasem przestał to być odosobniony przypadek. Operatorzy rozszerzyli działania na kolejne projekty i repozytoria, koncentrując się na komponentach o wysokim zasięgu operacyjnym. Taki dobór celów nie był przypadkowy — przejęcie jednego popularnego pakietu, obrazu czy rozszerzenia może przełożyć się na infekcję tysięcy pipeline’ów i stacji roboczych.
Analiza techniczna
Technicznie kampania opierała się na kilku powtarzalnych schematach. Pierwszym było uzyskanie dostępu do tokenów lub kont z uprawnieniami pozwalającymi na modyfikację repozytoriów, publikowanie nowych wersji albo manipulowanie release management. Drugim było podmienianie zaufanych wskaźników wersji, szczególnie tagów GitHub Actions, bez widocznej dla użytkownika zmiany nazwy.
W przypadku Trivy atakujący mieli publikować złośliwe pakiety i obrazy kontenerowe oraz zmieniać tagi akcji CI tak, aby pipeline’y automatycznie wykonywały malware. Istotne było to, że po uruchomieniu złośliwego etapu wykonywany był również prawidłowy kod narzędzia. Z perspektywy operatora proces mógł więc wyglądać normalnie, co znacząco utrudniało detekcję wyłącznie na podstawie logów.
Podobne techniki miały zostać użyte w incydencie dotyczącym Checkmarx i projektu KICS, gdzie złośliwy payload osadzono w rozszerzeniach dla ekosystemu VS Code i powiązanych komponentach GitHub Actions. Oznacza to rozszerzenie ataku z poziomu pipeline’u na stacje robocze deweloperów oraz środowiska IDE kompatybilne z VS Code.
Równolegle rozwijano operację w NPM. Tam malware było wykonywane już na etapie instalacji pakietu. Według analiz końcowy łańcuch infekcji zawierał komponent określany jako CanisterWorm, który po zdobyciu tokenów publikacyjnych mógł infekować kolejne paczki, tworząc mechanizm samopropagacji. Dodatkowo wykorzystywano mechanizmy trwałości, takie jak procesy działające w tle i usługi użytkownika.
Szczególnie groźny był wariant ukierunkowany na Kubernetes. Kod miał wykrywać środowisko klastrowe, wdrażać uprzywilejowane DaemonSety, utrzymywać trwałość i wykonywać ruch boczny z użyciem SSH oraz interfejsów Dockera. W części przypadków malware analizowało ustawienia regionalne i strefę czasową, a dla wybranych konfiguracji uruchamiało moduł destrukcyjny odpowiedzialny za usuwanie danych.
W najnowszym etapie kampanii skompromitowany miał zostać również LiteLLM w repozytorium PyPI. To szczególnie wrażliwy przypadek, ponieważ biblioteka bywa wykorzystywana jako warstwa pośrednia pomiędzy aplikacjami a dostawcami modeli AI, przez co często ma dostęp do licznych kluczy API, zmiennych środowiskowych i sekretów integracyjnych.
Konsekwencje / ryzyko
Ryzyko związane z tą kampanią należy uznać za bardzo wysokie. Dotyczy ono jednocześnie integralności zależności, bezpieczeństwa CI/CD, stacji roboczych deweloperów, środowisk kontenerowych oraz zasobów chmurowych. Kompromitacja pojedynczego tokenu może prowadzić do efektu domina i dalszych włamań wtórnych.
Najpoważniejszym skutkiem jest utrata poufności sekretów. Zagrożone mogą być tokeny GitHub, klucze SSH, poświadczenia do rejestrów kontenerów, sekrety organizacyjne, dane dostępowe do usług chmurowych oraz uprawnienia do klastrów Kubernetes. Jeżeli złośliwy komponent miał do nich dostęp, należy zakładać pełną kompromitację i konieczność natychmiastowej rotacji.
Drugim obszarem ryzyka jest naruszenie integralności procesu dostarczania oprogramowania. Jeśli atakujący mogli publikować złośliwe obrazy, pakiety i tagi, istnieje realne zagrożenie dalszego skażenia artefaktów budowanych przez ofiary, a w konsekwencji także środowisk klientów, partnerów i produkcji.
Dodatkowo kampania pokazuje, że granica między cyberszpiegostwem a destrukcją zaciera się coraz bardziej. Wariant dla Kubernetes z funkcją wycierania danych sugeruje, że te same mechanizmy dostępu mogą zostać wykorzystane nie tylko do kradzieży sekretów, lecz także do zakłócenia ciągłości działania usług.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy korzystały ze skompromitowanych wersji pakietów, obrazów kontenerowych, rozszerzeń IDE lub GitHub Actions powiązanych z kampanią. Niezbędny jest pełny przegląd zależności używanych w CI/CD, środowiskach deweloperskich i obrazach bazowych.
Kolejnym krokiem musi być rotacja wszystkich potencjalnie narażonych sekretów. Dotyczy to nie tylko tokenów bezpośrednio używanych przez zainfekowane komponenty, ale również poświadczeń dostępnych przez zmienne środowiskowe, pliki konfiguracyjne, cache buildów, menedżery sekretów oraz profile chmurowe.
- pinować workflow GitHub Actions do niezmiennych commit SHA zamiast tagów,
- ograniczać uprawnienia tokenów automatyzacyjnych do minimum,
- rozdzielać konta serwisowe dla publikacji, buildów i administracji,
- wymuszać krótką ważność tokenów i regularną rotację,
- monitorować zmiany tagów, release’y i force-pushy w krytycznych repozytoriach,
- wdrażać podpisywanie artefaktów i kontrolę pochodzenia pakietów,
- blokować wykonywanie skryptów instalacyjnych tam, gdzie nie są konieczne,
- analizować logi pod kątem nietypowych połączeń wychodzących i procesów działających w tle,
- sprawdzać DaemonSety, konta uprzywilejowane i dostęp do API Kubernetes,
- odtwarzać najbardziej wrażliwe systemy z czystych, zaufanych źródeł w razie podejrzenia trwałej kompromitacji.
Podsumowanie
Kampania TeamPCP pokazuje, że nowoczesne ataki na łańcuch dostaw oprogramowania osiągnęły skalę ekosystemową. Napastnicy nie ograniczyli się do pojedynczego narzędzia, lecz przenieśli ten sam model działania między GitHub Actions, Docker Hub, OpenVSX, NPM, PyPI i środowiskami Kubernetes.
Dla obrońców to ważny sygnał ostrzegawczy. Zaufanie do popularnej biblioteki, obrazu czy akcji CI nie może opierać się wyłącznie na rozpoznawalności projektu. Skuteczna ochrona wymaga twardego pinowania wersji, kontroli integralności, rygorystycznego zarządzania sekretami oraz gotowości do szybkiej reakcji po wykryciu oznak kompromitacji.
Źródła
- SecurityWeek — From Trivy to Broad OSS Compromise: TeamPCP Hits Docker Hub, VS Code, PyPI — https://www.securityweek.com/from-trivy-to-broad-oss-compromise-teampcp-hits-docker-hub-vs-code-pypi/
- Checkmarx — Security Advisory on OpenVSX Extensions and GitHub Actions — https://checkmarx.com/
- Aikido Security — Analyses of TeamPCP, CanisterWorm and Kubernetes activity — https://www.aikido.dev/
- Endor Labs — Analysis of malicious LiteLLM package behavior — https://www.endorlabs.com/
- Socket — Research on NPM supply-chain propagation and TeamPCP activity — https://socket.dev/