Kim jest TeamPCP — i dlaczego to nie jest zwykła grupa hakerów

Przez ostatnie tygodnie cyberflux opisywał kolejne ataki których ślady prowadziły do tej samej grupy: Checkmarx KICS i Bitwarden, Shai-Hulud zatruwający narzędzia AI do kodowania, PyTorch Lightning na PyPI, 1800 deweloperów przez pięć ekosystemów jednocześnie. Za każdym razem ten sam string w kodzie złośliwego oprogramowania: "TeamPCP Cloud stealer."

Ale opisywanie TeamPCP przez pryzmat pojedynczych incydentów jest jak opisywanie amazońskiego systemu rzecznego przez pryzmat kolejnych dopływów. Widać wodę, nie widać skali.

Ten wpis jest próbą pokazania całości.

Nie APT, nie ransomware gang — platforma

Klasyczna taksonomia grup cyberprzestępczych dzieli je na kilka kategorii: APT sponsorowane przez państwa, grupy ransomware jako usługi, infostealer operations, hacktivisci. TeamPCP nie pasuje dobrze do żadnej z tych kategorii — bo jest czymś, co dopiero zaczyna mieć własną nazwę: access generation engine.

SOCRadar ujmuje to precyzyjnie w swoim dark web profile grupy: "TeamPCP functions as an access generation engine feeding into multiple ransomware ecosystems simultaneously." To nie jest organizacja która sama wdraża ransomware, sama sprzedaje dane, sama przeprowadza finalne ataki. To jest organizacja która generuje dostęp — do infrastruktury, do poświadczeń, do środowisk deweloperskich — i ten dostęp monetyzuje przez partnerstwa z innymi podmiotami.

Żeby to zrozumieć, trzeba prześledzić jak ta grupa ewoluowała w ciągu dziewięciu miesięcy.

Skąd przyszli: lipiec–wrzesień 2025

Pierwsze ślady aktywności TeamPCP na Telegramie sięgają 30 lipca 2025 roku. Konto @Persy_PCP zaczyna publikować komunikaty sugerujące rebranding istniejącej grupy: "you may already know us as TeamPCP or Shellforce… CipherForce is a newer project we are starting to find affiliates."

W tym samym czasie pod aliasem DeadCatx3 na GitHubie pojawia się konto z narzędziami atakujących. Domena masscan[.]cloud — która stanie się jednym z głównych wskaźników kampanii — zostaje powiązana z adresem IP 67.217.57.240.

We wrześniu 2025 Unit 42 dokumentuje pierwszą falę Shai-Hulud jako robaka w ekosystemie npm — samopropagujący się kod który używa skradzionych tokenów npm do infekowania pakietów innych deweloperów. Na tym etapie skala jest ograniczona: setki pakietów, kilku maintainerów.

Faza pierwsza: budowanie infrastruktury, grudzień 2025–luty 2026

Pierwsza udokumentowana duża operacja TeamPCP pojawia się pod koniec grudnia 2025 pod nazwą PCPcat. Cel jest inny niż wszystko co opisywaliśmy później — nie deweloperzy, nie ekosystemy pakietów, ale chmura jako infrastruktura.

Automatyczne skanery TeamPCP szukają wystawionych Docker API, paneli Kubernetes bez uwierzytelnienia, dashboardów Ray, serwerów Redis dostępnych z internetu. Gdy je znajdą — kompromitują i włączają w sieć kontrolowaną przez grupę: tysiące przejętych węzłów jako infrastruktura do skanowania kolejnych celów, proxy do ukrywania dalszych ataków, hosty do kopania kryptowaluty i deploymentu ransomware.

Pierwsza pięta achillesowa: React2Shell CVE-2025-55182, CVSS 10.0, podatność w środowiskach cloud pozwalająca na zdalne wykonanie kodu. TeamPCP był wśród pierwszych którzy ją masowo eksploitowali — charakterystyczny szczegół operacyjny to port 666 używany do niemal wszystkich połączeń exploitacyjnych.

Mandiant szacuje że do końca tej fazy TeamPCP skompromitował około 500 000 maszyn. Cyfra jest trudna do niezależnej weryfikacji ale oddaje skalę: nie chodzi o precyzyjne celowanie w konkretne organizacje, chodzi o zmasowane skanowanie i automatyczne przejmowanie wszystkiego co ma błędną konfigurację.

Telegram @team_pcp rośnie z około 700 subskrybentów na początku lutego 2026 do ponad 1180 pod koniec marca — napędzany regularnym publikowaniem próbek skradzionych danych jako dowodów działalności.

Moment zwrotny: Aqua Security, 1 marca 2026

To co wydarzyło się 1 marca 2026 jest centralnym elementem zrozumienia jak TeamPCP działa w fazie drugiej.

Aqua Security — producent Trivy, najpopularniejszego skanera bezpieczeństwa kontenerów na świecie — doświadczyło wycieku poświadczeń z własnej infrastruktury. Firma zareagowała rotacją sekretów i tokenów. Rotacja była — jak Aqua sama przyznała po fakcie — niekompletna. Atakujący zachowali dostęp przez resztkowe poświadczenia.

19 marca 2026 roku, niemal trzy tygodnie później, TeamPCP użył tego zachowanego dostępu do wstrzyknięcia złośliwego kodu do Trivy w wersji 0.69.4 przez oficjalne repozytoria. Nie przez podmianę pliku. Przez push złośliwego taga który nadpisał wszystkie historyczne tagi wersji jednocześnie — technikę force-push która sprawiła że żadna historyczna wersja nie była już bezpieczna, a organizacje przypinające konkretną wersję nie były chronione.

MOXFIVE opisuje mechanizm kaskady który nastąpił po tym wydarzeniu: "Stolen credentials and trusted distribution channels became the mechanism for moving from one environment to the next, and that pattern is what allowed a single incomplete credential rotation to cascade into the compromise of four additional projects."

Trivy jest wdrożony w milionach środowisk CI/CD jako automatyczny skaner uruchamiany przy każdym buildie. Każdy runner który wykonał trivy na złośliwej wersji uruchomił trzyetapowy ładunek: zbieranie poświadczeń, lateral movement przez Kubernetes, instalacja permanentnego backdoora systemd.

Credentials as chain: jak jeden niekompletnie obrócony token dał dostęp do pięciu projektów

To jest najważniejszy mechanizm operacyjny który odróżnia TeamPCP od tradycyjnych grup supply chain.

Tradycyjny atak supply chain wymaga odrębnego wektora wejścia do każdego celu: podatności w każdym projekcie, skompromitowanego maintainera dla każdego pakietu, odrębnej infrastruktury ataku. TeamPCP zbudował model który tego nie wymaga.

Sekwencja marca i kwietnia 2026:

Trivy (19 marca) → skradzione tokeny GitHub Actions z tysięcy runnerów → pivot do projektów które używały Trivy w CI/CD.

Checkmarx KICS (23 marca, 22 godziny po Trivy) — ten sam klucz RSA co w Trivy potwierdza powiązanie. Skompromitowane konto serwisowe Checkmarx pozwoliło na podmianę tagów w repozytorium GitHub Action. Tym razem skradzione tokeny Checkmarx service account.

LiteLLM (24 marca, 22 godziny po KICS) — środowisko CI/CD maintainera LiteLLM uruchamiało skompromitowane Trivy jako część pipeline'u. Skradzione tokeny PyPI pozwoliły na publikację złośliwych wersji 1.82.7 i 1.82.8 z trzynastominutowym odstępem — Endor Labs zauważył że w tym oknie atakujący aktywnie iterował kod dodając wektor infekcji przez .pth w wersji 1.82.8. Nie był to gotowy pakiet wdrożony jednorazowo. Był to aktywny development w czasie rzeczywistym.

Checkmarx KICS + Bitwarden CLI (22 kwietnia) — ta sama infrastruktura, nowa fala z nowymi celami.

SAP npm + PyTorch Lightning + Intercom (29–30 kwietnia) — rozszerzenie na PyPI i Packagist.

Każdy skompromitowany projekt dawał nowe poświadczenia. Te poświadczenia pozwalały na pivot do następnego projektu bez nowego wektora wejścia. Endor Labs: "Each attack yielded credentials that unlocked the next target. This campaign is almost certainly not over."

Model partnerski: od grupy do platformy

W marcu 2026 TeamPCP ogłosił dwa partnerstwa które fundamentalnie zmieniły charakter operacji.

Pierwsze: CipherForce — własna operacja ransomware TeamPCP szukająca afiliantów. Komunikat na Telegramie wprost łączy tę tożsamość z historią grupy.

Drugie: VECT ransomware — partnerstwo ogłoszone publicznie z dostępem do panelu VECT dla każdego zarejestrowanego użytkownika BreachForums. Pisaliśmy o VECT jako ransomware który sam zniszczył klucze deszyfrowania — co czyni to partnerstwo szczególnie niepokojącym: TeamPCP dostarcza dostęp do środowisk, VECT deployuje payload który w praktyce niszczy dane bez możliwości odzyskania.

Cyber News Network opisuje implikacje modelu: "BreachForums provides 300,000 potential operators — converts a credential-theft operation into industrialized ransomware deployment. If even a small fraction of registered users activate, this could become one of the largest coordinated ransomware affiliate mobilizations observed."

TeamPCP nie deployuje ransomware samodzielnie. Dostarcza dostęp jako usługę dla każdego kto chce z niego skorzystać.

Infrastruktura trudna do neutralizacji

Część z tego co sprawia że TeamPCP jest trwałym zagrożeniem a nie jednorazową kampanią to architektura ich infrastruktury C2.

Wczesne kampanie używały tradycyjnych domen C2 — checkmarx.zone, scan.aquasecurtiy[.]org (celowa literówka - typosquatting). Te można zablokować i przejąć.

Późniejsze kampanie przeszły na dwa trudniejsze do neutralizacji mechanizmy.

ICP Canister — Internet Computer Protocol jako dead-drop C2. Zdecentralizowana infrastruktura bez jednego punktu przejęcia, censorship-resistant. Blokowanie domeny nie neutralizuje C2.

GitHub jako dynamiczny C2 — robak szuka w publicznych commitach GitHuba specyficznych stringów żeby pobrać adresy serwerów sterujących. Nowy commit z nowym adresem — robak go znajdzie. Ruch do GitHub domyślnie nie jest flagowany przez narzędzia bezpieczeństwa.

Do tego WAV steganografia — zaszyfrowane payloady drugiego etapu ukryte w plikach audio przechodzą przez filtry DLP jako pliki medialne. Trzy samopodpisane certyfikaty reużywane między operacjami zapewniają szyfrowane kanały bez atrybucji przez CA.

Europejska Komisja i zmiana przywództwa

Najbardziej głośna potwierdzona ofiara TeamPCP to nie deweloper ani startup. To Komisja Europejska.

2–3 kwietnia 2026 roku CERT-EU oficjalnie przypisał TeamPCP naruszenie środowiska AWS Komisji Europejskiej. 92 GB skompromitowanych danych z 42 wewnętrznych departamentów i 29 podmiotów UE. ShinyHunters — osobna operacja — opublikowała około 340 GB (nieskompresowanych) tych danych na własnej witrynie dark web.

To jest zmiana jakościowa w kategoriach ofiar: od tysięcy deweloperów i startupów do pierwszej potwierdzonej ofiary na poziomie instytucji rządowych.

W tym samym tygodniu na Telegramie ukazał się komunikat o zmianie przywództwa: oryginalny operator DMT przekazał kontrolę nowemu liderowi działającemu pod aliasem T00001B. Rotacja przywództwa w środku aktywnej kampanii jest sygnałem że organizacja ma strukturę wykraczającą poza jedną osobę.

CanisterWorm: gdy motywacja finansowa spotyka geopolitykę

Jest jeden element arsenału TeamPCP który wymaga osobnego omówienia bo wykracza poza schemat finansowo motywowanej grupy przestępczej.

CanisterWorm — komponent destructive wiper dokumentowany przez Unit 42 i Palo Alto Networks — zawiera geofencing: nie aktywuje się na maszynach z irańskim locale lub zainstalowanymi paczkami językowymi Farsi. Deployuje uprzywilejowane DaemonSets na klastrach Kubernetes żeby zniszczyć cały klaster lub wykonuje rekurencyjne usuwanie plików na hostach bez kontenerów.

Niszczenie infrastruktury — bez negocjacji, bez żądania okupu, z celowym wyłączeniem irańskich celów — sugeruje element geopolityczny w operacji która w pozostałych wymiarach jest czysto finansowa. Palo Alto Networks zauważa tę rozbieżność wprost: "This blend of automated propagation, decentralized infrastructure and targeted destruction marks CanisterWorm as one of the more complex cloud-native threats identified to date."

Nie ma publicznej atrybucji co do tego co ten komponent mówi o tożsamości lub sponsoringu grupy. Ale jego obecność zmienia ocenę ryzyka dla organizacji które zakładają że mają do czynienia z czysto przestępczym podmiotem.

Co to oznacza dla organizacji używających dotkniętych narzędzi

Pełna lista projektów skompromitowanych w kampaniach TeamPCP od marca do maja 2026:

Aqua Security Trivy, Checkmarx KICS (Docker Hub i GitHub Action), BerriAI LiteLLM, Telnyx Python SDK, Smart Slider 3 Pro (WordPress), Bitwarden CLI, SAP npm packages (cztery), PyTorch Lightning, intercom-client, intercom-php, oraz potencjalnie dalsze projekty których kompromitacja nie była jeszcze publicznie ujawniona.

Każda z tych kompromitacji dawała TeamPCP dostęp do środowisk organizacji które używają tych narzędzi. Dla organizacji które używały któregokolwiek z nich w CI/CD między marcem a majem 2026 — zakładając że dochodzenie jest kompletne jest błędem operacyjnym.

Cyber News Network wskazuje na jeden szczegół który komplikuje tę ocenę: TeamPCP przez wielomiesięczne pre-positioning budował infrastrukturę w grudniu 2025 którą aktywował w marcu 2026. Zespoły przeglądające tylko niedawną aktywność mogą przeoczyć fazę stagingową.

Gdzie jesteśmy i co dalej

Mini Shai-Hulud przez pięć ekosystemów w trzech dniach to nie jest punkt kulminacyjny kampanii. Jest kolejnym etapem operacji która działa od dziewięciu miesięcy i która za każdym razem rozszerza się na nowe cele i ekosystemy.

Endor Labs sformułował to najdokładniej: "Each attack yielded credentials that unlocked the next target. This campaign is almost certainly not over."

Logika jest prosta: 1800 publicznych repozytoriów z wykradzionymi poświadczeniami to akumulowany zasób dostępu. Część tych poświadczeń jest już rotowana. Część nie. Poświadczenia do środowisk produkcyjnych mają długi czas życia jeśli nie ma automatycznej rotacji. Każde poświadczenie które nie zostało obrócone po kompromitacji jest potencjalnym wektorem dla następnej fazy kampanii — niezależnie od tego czy TeamPCP zdecyduje się je użyć, czy jego partnerzy, czy ktokolwiek inny kto pobrał dane z publicznych repozytoriów GitHub.

TeamPCP nie jest grupą hakerów która zostanie rozwiązana gdy znikną jej liderzy lub gdy platformy zablokują konkretne konta. Jest wzorcem operacyjnym: automatyczne generowanie dostępu przez supply chain, monetyzacja przez partnerstwa, decentralizowana infrastruktura C2 odporna na neutralizację. Wzorzec będzie kontynuowany przez T00001B tak samo jak przez DMT — bo model działa niezależnie od tego kto go prowadzi.

Źródła

SOCRadar — pełny dark web profile z historią aliasów i analizą partnerskich operacji: https://socradar.io/blog/dark-web-profile-teampcp/

Unit 42 / Palo Alto Networks — analiza supply chain campaign i CanisterWorm: https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/

Flare.io — pierwotna dokumentacja z lutego 2026 z analizą infrastruktury i Telegrama: https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware

Endor Labs — szczegółowa analiza LiteLLM i mechanizmu credentials-as-chain: https://www.endorlabs.com/learn/teampcp-isnt-done

MOXFIVE — threat actor alert z chronologią marca 2026: https://www.moxfive.com/resources/moxfive-threat-actor-alert-teampcp

Cyber News Network — analiza modus operandi i multi-month pre-positioning: https://cyberwarrior76.substack.com/p/threat-actor-modus-operandi-team

Cyble — profil techniczny grupy: https://cyble.com/threat-actor-profiles/teampcp/

TrollEye Security — szczegóły ataku na Trivy i force-push technique: https://www.trolleyesecurity.com/trivy-supply-chain-attack-teampcp-backdoors-widely-used-security-scanner-via-github-actions/