Wprowadzenie do problemu / definicja
Grupa TeamPCP, dotąd kojarzona głównie z kompromitacją łańcucha dostaw systemu open source, rozszerzyła swoje operacje na środowiska chmurowe AWS. Mechanizm działania opiera się na przejmowaniu sekretów i poświadczeń z naruszonych pipeline’ów CI/CD, repozytoriów kodu oraz pakietów deweloperskich, a następnie szybkim wykorzystaniu ich do rekonesansu, ruchu bocznego i eksfiltracji danych.
To istotna zmiana z perspektywy bezpieczeństwa, ponieważ incydent początkowo wyglądający jak naruszenie procesu wytwarzania systemu może w krótkim czasie przerodzić się w pełnoskalową kompromitację infrastruktury chmurowej.
W skrócie
- TeamPCP wykorzystuje skradzione poświadczenia do uzyskiwania dostępu do środowisk AWS.
- Po walidacji aktywnych kluczy i tokenów atakujący enumerują usługi oraz identyfikują zasoby o wysokiej wartości.
- Na celowniku znajdują się m.in. kontenery, repozytoria kodu, menedżery sekretów, bucket’y S3 oraz bazy danych.
- Kampania pokazuje ścisły związek między bezpieczeństwem software supply chain a ochroną środowisk cloud.
Kontekst / historia
TeamPCP pozostaje aktywna co najmniej od 2024 roku. Początkowo grupa była łączona przede wszystkim z operacjami wymierzonymi w zasoby chmurowe, jednak w połowie 2025 roku przesunęła ciężar działań na ataki na łańcuch dostaw, szczególnie te ukierunkowane na kradzież poświadczeń CI/CD na dużą skalę.
W ostatniej fazie kampanii szerokim echem odbiło się naruszenie narzędzia do skanowania podatności Trivy. Według analityków był to jeden z kluczowych incydentów, który uruchomił dalsze skutki w zależnych pipeline’ach i ekosystemach programistycznych. Złośliwy kod osadzany w pakietach i workflow automatyzacji miał służyć do przechwytywania tokenów publikacyjnych, sekretów API, kluczy SSH oraz innych danych uwierzytelniających.
Znaczenie tej kampanii wynika ze skali potencjalnego oddziaływania. Zagrożone mogły zostać nie tylko pojedyncze projekty, ale także dziesiątki tysięcy repozytoriów oraz środowisk deweloperskich. To modelowy przykład przejścia od kompromitacji zaufanego komponentu do wtórnego wykorzystania przejętych sekretów w systemach produkcyjnych.
Analiza techniczna
Operacja ma charakter wieloetapowy. Pierwszy etap obejmuje przejęcie poświadczeń wskutek kompromitacji komponentów używanych w procesie budowania i publikacji oprogramowania. Napastnicy pozyskują m.in. klucze dostępu AWS, sekrety aplikacyjne oraz tokeny do usług SaaS.
Następnie grupa sprawdza, które z przechwyconych danych uwierzytelniających pozostają aktywne. Szybka walidacja ma znaczenie operacyjne, ponieważ ogranicza szansę, iż ofiara zdąży unieważnić sekret przed jego wykorzystaniem.
Po potwierdzeniu ważności poświadczeń rozpoczyna się faza rekonesansu w AWS. Atakujący enumerują dostępne usługi, identyfikują klastry i definicje zadań kontenerowych, analizują konfigurację środowiska oraz próbują uzyskać dostęp do przechowywanych sekretów. Szczególne znaczenie ma AWS Secrets Manager, ponieważ może zawierać dane umożliwiające dalszą eskalację dostępu.
Kolejny etap obejmuje uruchamianie kodu wewnątrz środowiska ofiary. Opisywane techniki zakładają wykorzystanie workflow GitHub do wykonywania kodu oraz mechanizmów zdalnego wykonywania poleceń w kontenerach działających w AWS. Dzięki temu napastnicy mogą uruchamiać polecenia Bash i skrypty Python bezpośrednio w obciążeniach testowych lub produkcyjnych.
Końcowym celem jest masowa eksfiltracja danych. Grupa pobiera kod źródłowy, pliki konfiguracyjne, osadzone sekrety, dane z bucketów S3, wpisy z menedżerów sekretów oraz zawartość baz danych. Taki zestaw informacji może zostać użyty do dalszej monetyzacji, sprzedaży dostępu lub przygotowania kolejnych kampanii.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tego typu działań jest przeniesienie ryzyka z warstwy developerskiej do środowisk produkcyjnych i chmurowych. choćby jeżeli pierwotny incydent dotyczy pakietu open source lub procesu publikacji, jego rzeczywiste skutki mogą obejmować przejęcie zasobów cloud, utratę poufności danych oraz ujawnienie kolejnych sekretów.
- wyciek kodu źródłowego i własności intelektualnej,
- ujawnienie sekretów umożliwiających następne kompromitacje,
- dostęp do danych klientów i zasobów biznesowych,
- ruch boczny między usługami, środowiskami i kontami,
- wzrost ryzyka wtórnych ataków, w tym wymuszeń i ransomware.
Szczególnie groźny jest efekt domina. o ile sekret przejęty z jednego repozytorium zapewnia dostęp do menedżera sekretów lub środowiska kontenerowego, napastnik może bardzo gwałtownie rozszerzyć zasięg operacji na kolejne systemy. W praktyce pojedynczy wyciek tokenu publikacyjnego może doprowadzić do naruszenia znacznie większej części infrastruktury.
Rekomendacje
Organizacje powinny traktować poświadczenia używane w pipeline’ach CI/CD, repozytoriach oraz narzędziach open source jako zasoby wysokiego ryzyka. Ochrona takich sekretów nie może być postrzegana wyłącznie jako zadanie zespołów developerskich, ponieważ ich kompromitacja bezpośrednio przekłada się na bezpieczeństwo środowisk chmurowych.
- natychmiastowa rotacja wszystkich sekretów, które mogły znaleźć się w zasięgu naruszonych workflow, pakietów lub środowisk build,
- inwentaryzacja kluczy AWS, tokenów publikacyjnych i sekretów aplikacyjnych wraz z przypisaniem właścicieli oraz zastosowań,
- wdrożenie krótkowiecznych poświadczeń i federacji tożsamości zamiast długoterminowych kluczy statycznych,
- ograniczenie uprawnień zgodnie z zasadą najmniejszych uprawnień, szczególnie dla ról CI/CD i kont serwisowych,
- monitorowanie użycia AWS Secrets Manager, S3, ECS oraz nietypowych operacji wykonywanych z kont automatyzacyjnych,
- analiza logów pod kątem nagłej enumeracji usług, dostępu do sekretów i zdalnego wykonywania poleceń w kontenerach,
- skanowanie repozytoriów i artefaktów build pod kątem wycieków sekretów oraz osadzonego złośliwego kodu,
- weryfikacja integralności zależności open source i workflow automatyzacji,
- wdrożenie mechanizmów detekcji zachowań post-exploitation, a nie tylko klasycznych sygnatur malware.
Z perspektywy reagowania na incydenty najważniejsze jest założenie, iż kompromitowany sekret mógł zostać już użyty. Sama rotacja kluczy nie powinna więc kończyć procesu obsługi incydentu. Niezbędne jest również ustalenie zakresu dostępu, możliwych ścieżek ruchu bocznego, skali eksfiltracji oraz ewentualnych mechanizmów utrzymania dostępu.
Podsumowanie
Aktywność TeamPCP pokazuje, iż współczesne kampanie przeciwko łańcuchowi dostaw nie kończą się na zatruciu pakietu lub przejęciu tokenu publikacyjnego. Rzeczywistym celem staje się wykorzystanie pozyskanych sekretów do wejścia w środowiska chmurowe, rozpoznania infrastruktury i kradzieży danych na dużą skalę.
Dla zespołów bezpieczeństwa oznacza to konieczność ścisłego połączenia monitoringu software supply chain z kontrolami cloud security i IAM. Organizacje, które traktują te obszary rozdzielnie, ryzykują przeoczenie momentu, w którym incydent developerski przechodzi w pełne naruszenie środowiska AWS.
Źródła
- SecurityWeek – TeamPCP Moves From OSS to AWS Environments — https://www.securityweek.com/teampcp-moves-from-oss-to-aws-environments/
- Wiz Research – raport dotyczący aktywności TeamPCP — https://www.wiz.io/
- OpenSourceMalware – analiza kampanii powiązanej z kompromitacją Trivy — https://opensourcemalware.com/
- Socket – informacje o kampanii i powiązaniach aktorów zagrożeń — https://socket.dev/
