W tekście o incydencie Trivy pisaliśmy, że problemem nie jest już wyłącznie złośliwy artefakt, ale zaufana automatyzacja, która wykonuje obce działania w naszym imieniu. Najnowsze informacje o TeamPCP przesuwają ten problem o poziom wyżej. Nie chodzi już o jedno repozytorium ani jeden skażony element pipeline’u. Chodzi o cały ekosystem zaufanych kanałów open source — GitHub Actions, Docker Hub, npm, Open VSX i PyPI — które developerzy traktują jak naturalną część codziennej pracy. W ciągu pięciu dni kampania objęła właśnie te warstwy, a SecurityWeek, powołując się na Vx-Underground, pisze o około 300 GB wykradzionych danych z około 500 000 zainfekowanych maszyn.
To ważna zmiana skali. W przypadku Trivy można było jeszcze myśleć o incydencie jako o bardzo groźnym, ale jednak punktowym naruszeniu zaufania do jednego ważnego elementu CI/CD. Teraz ten komfort znika. Gdy ten sam aktor pojawia się w kolejnych miejscach workflow deweloperskiego w odstępach jednego dnia, przestaje chodzić o pojedynczy przypadek. Zaczyna chodzić o przejmowanie całego układu zależności, na którym opiera się współczesne wytwarzanie oprogramowania. Datadog i SecurityWeek opisują właśnie taki wzór: od Trivy, przez npm i Open VSX, po PyPI i LiteLLM.
Najciekawsze jest jednak coś głębszego niż sama liczba przejętych punktów styku. TeamPCP nie atakuje open source jak zbioru bibliotek. Atakuje open source jak środowisko wykonawcze. Nie celuje w kod jako taki, ale w miejsca, w których kod staje się działaniem: akcję CI/CD, obraz kontenera, paczkę npm, rozszerzenie IDE, bibliotekę Pythona. To już nie wygląda jak klasyczny supply chain attack rozumiany jako „złośliwa paczka weszła do obiegu”. To wygląda raczej jak atak na nawyki wykonawcze całego ekosystemu. Developer nie robi nic nienormalnego. Odpala action, pobiera obraz, aktualizuje paczkę, uruchamia bibliotekę. Szkoda nie pojawia się dlatego, że workflow został porzucony. Szkoda pojawia się dlatego, że workflow pozostał normalny.
Z punktowego skażenia do wieloekosystemowej kampanii
Żeby zrozumieć skalę, warto prześledzić oś czasu. Datadog Security Labs odtworzyło ją dzień po dniu. 19 marca atakujący, używając skradzionych poświadczeń konta serwisowego Argon-DevOps-Mgt, uzyskali uprawnienia write/admin do repozytoriów Aqua Security. Opublikowali złośliwą wersję Trivy 0.69.4, force-pushowali 76 z 77 tagów aquasecurity/trivy-action na złośliwe commity i podmienili wszystkie siedem tagów aquasecurity/setup-trivy. Złośliwe akcje zrzucały pamięć procesu Runner.Worker, zbierały poświadczenia z typowych lokalizacji, szyfrowały wyniki schematem AES-256 + RSA-4096 i eksfiltrowały je na domenę scan.aquasecurtiy[.]org, czyli celowy typosquatting Aqua Security. Jeśli bezpośrednia eksfiltracja zawiodła i dostępny był token GitHub, malware tworzył publiczne repozytorium tpcp-docs i uploadował tam skradzione dane. SANS podawał, że modyfikacje tagów dotknęły ponad 10 000 workflow CI/CD.
Między 20 a 22 marca atakujący zaczęli „wydawać” skradzione dostępy. Na npm pojawił się CanisterWorm — samopropagujący się robak, który używał wykradzionych tokenów npm, sprawdzał, jakie paczki może nimi opublikować, podbijał wersje patch, pobierał oryginalne README, żeby zachować pozory, i republokował paczki z payloadem. Według Datadog kampania dotknęła co najmniej 64 unikalnych paczek npm i ponad 140 artefaktów. Równolegle ta sama infrastruktura C2 zaczęła serwować skrypt Kubernetes z destrukcyjnym rozgałęzieniem: na systemach z locale i strefą czasową ustawionymi na Iran malware wdrażało DaemonSet kasujący host filesystem i wymuszający reboot węzłów; poza tym wariantem instalowało trwały backdoor.
23 marca kampania trafiła w Checkmarx. Przejęte zostały Checkmarx/kics-github-action, Checkmarx/ast-github-action i dwa rozszerzenia Open VSX. SecurityWeek pisze, że łącznie przechwycono 35 tagów GitHub Actions, a rozszerzenia Open VSX miały ponad 36 000 pobrań i działały nie tylko w VS Code, ale też w kompatybilnych środowiskach, takich jak Cursor czy Windsurf. Datadog i SecurityWeek wskazują też, że tego samego dnia doszło do kompromitacji konta GitHub współzałożyciela i CEO LiteLLM, Krisha Dholakii.
24 marca na PyPI pojawiły się wersje LiteLLM 1.82.7 i 1.82.8 z wstrzykniętym payloadem. Około 14:00 UTC repozytoria LiteLLM na GitHubie zostały zdewastowane, a PyPI objęło projekt kwarantanną. Sam projekt LiteLLM publicznie potwierdził, że skompromitowane były właśnie wersje 1.82.7 i 1.82.8, oraz że źródłem kompromitacji była zależność Trivy używana w workflow bezpieczeństwa CI/CD.
I właśnie tu widać, że nie mamy już do czynienia z serią odrębnych incydentów. Najgroźniejsze w tej kampanii nie jest nawet to, że objęła pięć ekosystemów w pięć dni. Najgroźniejsze jest to, że każdy z tych ekosystemów pełni inną funkcję w codziennej pracy developera, a mimo to wszystkie zostały potraktowane jak jedna powierzchnia wykonawcza. GitHub Actions uruchamia, Docker Hub dostarcza, npm propaguje, Open VSX osadza się w IDE, PyPI przenosi atak do biblioteki aplikacyjnej. To nie wygląda jak seria przypadkowych kompromitacji. To wygląda jak sprawdzanie, jak daleko da się przesunąć obcą kontrolę, jeśli przejmuje się kolejne warstwy tego samego workflow.
Jak konkretnie działa przejście Trivy → LiteLLM
To jest krok, który najlepiej ilustruje logikę całej kampanii. LiteLLM używało Trivy w swoim pipeline CI/CD, konkretnie w pliku ci_cd/security_scans.sh. Kiedy złośliwa akcja Trivy wykonała się na runnerze LiteLLM, zrzuciła pamięć procesu i zebrała poświadczenia ze znanych lokalizacji — w tym token PyPI używany przez projekt do publikowania paczek. Te poświadczenia posłużyły następnie do opublikowania złośliwych wersji bezpośrednio jako legalne releasy LiteLLM. Datadog opisuje ten mechanizm jako „kaskadę”: skradzione poświadczenia z jednego środowiska CI/CD odblokowują dostęp do następnego ekosystemu. Nie złamano zabezpieczeń PyPI. Nie złamano zabezpieczeń LiteLLM jako projektu. Użyto legalnych poświadczeń uzyskanych przez kompromitację zaufanego narzędzia wyżej w łańcuchu.
I to jest moment, w którym ten case przestaje być tylko historią o „złośliwej paczce”. Problemem nie jest już wyłącznie to, co pobierasz, ale to, co ma prawo działać automatycznie w Twoim imieniu. Właśnie dlatego Trivy, Checkmarx, Open VSX i LiteLLM tak dobrze się tu spinają: wszystkie te elementy siedzą blisko wykonania, a nie tylko blisko kodu. Kiedy jedna zaufana warstwa zaczyna wykonywać obce działania przy użyciu własnych, legalnych poświadczeń, kolejne warstwy nie muszą zostać złamane. Wystarczy, że przyjmą je jako normalną część procesu.
Trzy warstwy payloadu i dlaczego 1.82.8 jest groźniejszy
Payload w analizowanych wariantach TeamPCP ma trójstopniową strukturę, opisaną przez Datadog, Wiz i inne analizy techniczne. Pierwsza warstwa to credential harvester: zbiera klucze SSH, cloud credentials dla AWS, GCP i Azure, sekrety Kubernetes, konfiguracje Dockera, historię powłoki, pliki .env, tokeny CI/CD i pliki portfeli kryptowalutowych. Dane są szyfrowane i eksfiltrowane przez HTTPS POST do infrastruktury C2. Druga warstwa to Kubernetes lateral movement: jeśli malware znajdzie użyteczny token service account, tworzy uprzywilejowane pody node-setup-* na każdym węźle klastra, wykonuje chroot na host filesystem i instaluje persistence dropper. Trzecia warstwa to trwały backdoor sysmon.service, który cyklicznie odpytuje infrastrukturę C2 o kolejny payload; charakterystyczny kill switch opiera się na sprawdzeniu, czy zwrócony URL zawiera youtube.com.
Różnica między wersjami 1.82.7 i 1.82.8 jest technicznie bardzo istotna. W 1.82.7 złośliwy kod siedział w module litellm/proxy/proxy_server.py, więc uruchamiał się przy imporcie tego komponentu. W 1.82.8 do roota wheela dodano plik litellm_init.pth, który powodował wykonanie payloadu przy starcie interpretera Pythona. To oznaczało, że każdy proces Pythona w środowisku, gdzie zainstalowano 1.82.8, mógł uruchamiać malware bez importu LiteLLM i bez interakcji użytkownika. To właśnie dlatego 1.82.8 było groźniejsze: atak przestał zależeć od tego, czy aplikacja naprawdę korzysta z LiteLLM. Wystarczała sama obecność paczki w środowisku.
LiteLLM i skala ryzyka dla środowisk AI
LiteLLM nie jest niszowym komponentem. Tu warto rozróżnić dwie liczby, bo oznaczają coś innego. Endor Labs podaje ponad 95 milionów pobrań miesięcznie, podczas gdy SecurityWeek — powołując się na ReversingLabs — mówi o około 480 milionach pobrań łącznie. To nie są sprzeczne dane, tylko dwa różne sposoby opisania skali adopcji. Niezależnie od przyjętej miary, mówimy o bibliotece na tyle szeroko używanej, że jej kompromitacja automatycznie podnosi ryzyko dla środowisk, w których stykają się DevOps, aplikacje AI i infrastruktura chmurowa.
To ma bardzo konkretny skutek dla architektury ryzyka. LiteLLM z natury ma dostęp do kluczy API dostawców AI, zmiennych środowiskowych i poświadczeń infrastrukturalnych. Payload zaprojektowano tak, by zbierał dokładnie to, do czego ma dostęp proces, w którym działa. Granica między „incydentem DevOps” a „incydentem AI” zaczyna się więc rozmywać. To nie są już dwa osobne światy. To jeden problem: skażenie zaufanego workflow wykonawczego w miejscu, gdzie infrastruktura deweloperska i AI tooling stykają się ze sobą.
Kiedy narzędzie bezpieczeństwa staje się narzędziem wejścia
W tej kampanii jest jeszcze jedna istotna obserwacja. TeamPCP nie uderza w przypadkowe elementy open source. Socket podkreśla, że grupa systematycznie celuje w narzędzia bezpieczeństwa i infrastrukturę OSS. To bardzo znaczące, bo narzędzia bezpieczeństwa z definicji są uprzywilejowane: skanują sekrety, dotykają pipeline’ów, mają wgląd w artefakty i często działają w środowiskach enterprise z bardzo szerokim zakresem dostępu. Jeśli atakujący przejmuje takie narzędzie, przejmuje nie tylko komponent techniczny, ale także organizacyjne zaufanie, którym ten komponent został wcześniej obdarzony.
CrowdStrike zwraca uwagę na jeszcze jeden szczegół: złośliwy kod w Trivy usuwał tymczasowe pliki po eksfiltracji i jednocześnie kontynuował normalne skanowanie, produkując oczekiwane logi. Operator przeglądający workflow widział ukończony krok skanera bezpieczeństwa, a nie złośliwą akcję. To właśnie czyni ten model tak niebezpiecznym. Atak nie musi zakłócać procesu. Wystarczy, że wykorzysta go jako nośnik własnego działania i zostawi po sobie rezultat wyglądający na całkowicie normalny.
I właśnie dlatego TeamPCP jest ważniejsze jako wzór niż jako pojedyncza grupa. Ta kampania pokazuje, że open source przestaje być wyłącznie biblioteką, a coraz bardziej przypomina środowisko operacyjne z własnymi punktami dystrybucji, wykonania, eskalacji i propagacji. Kiedy napastnik nauczy się poruszać po tych punktach, nie musi już łamać każdej warstwy osobno. Wystarczy, że jedna zaufana warstwa zacznie wykonywać obce działania przy użyciu własnych, legalnych poświadczeń.
Atrybucja i możliwe powiązania z Lapsus$
TeamPCP jest opisywany również pod nazwami DeadCatx3, PCPcat i ShellForce. SecurityWeek pisze, że grupa mogła wejść we współpracę z Lapsus$ przy monetyzacji kampanii, a inne relacje wskazują na zbieżności z wcześniejszymi działaniami wymierzonymi w Docker, Kubernetes, Ray i Redis.
Warto jednak zachować ostrożność i powiedzieć wprost, na czym opierają się te powiązania. Publicznie wskazywane są przede wszystkim: wzajemne ogłoszenia i przechwałki na kanałach Telegram, zbieżność czasowa działań, podobieństwa w infrastrukturze i ocenach badaczy mówiących o możliwej konwergencji między aktorami od supply chain a grupami nastawionymi na wymuszenia i kradzież tajemnic handlowych. To ważne rozróżnienie. Na obecnym etapie nie wygląda to na prostą, ostatecznie potwierdzoną tezę „to jedna i ta sama grupa”, ale raczej na sygnał współpracy, przenikania albo nakładających się interesów.
Co z tego wynika dla security
Najbardziej praktyczny wniosek brzmi tak: nie wystarczy już pytać, czy konkretny pakiet jest czysty. Trzeba pytać szerzej:
czy workflow ma zbyt wiele zaufanych punktów styku,
które z nich mają dostęp do sekretów i poświadczeń publikacyjnych,
które są pobierane automatycznie i uruchamiają się bez udziału człowieka,
i jak szybko kompromitacja jednego komponentu może przeskoczyć na kolejne warstwy.
GitGuardian zwraca uwagę, że historia Trivy bardzo boleśnie pokazuje, gdzie sekrety w pipeline’ach stają się najsłabszym punktem, a Datadog wskazuje, że w przypadku LiteLLM remediation nie kończy się na usunięciu paczki, tylko wymaga traktowania całego środowiska jako zdarzenia pełnej ekspozycji poświadczeń.
Dla środowisk, w których zainstalowano LiteLLM 1.82.7 lub 1.82.8, poprzeczka remediation jest więc wyższa niż zwykłe usunięcie paczki. Datadog rekomenduje identyfikację wszystkich hostów i jobów CI/CD z tymi wersjami, rotację wszystkich poświadczeń dostępnych z runtime, polowanie na ruch wychodzący do infrastruktury C2 i sprawdzenie systemów pod kątem ~/.config/sysmon/sysmon.py, sysmon.service i /tmp/pglog. W Kubernetesie dochodzi jeszcze przegląd logów pod kątem uprzywilejowanych podów node-setup-*.
I chyba właśnie to jest najważniejsze. Organizacje nie kontrolują już jednego supply chainu, tylko wiele nakładających się warstw zaufania wykonawczego: akcje CI/CD, registry obrazów, paczki językowe, marketplace’y rozszerzeń, biblioteki AI i konta publikacyjne. Jeśli jedna z tych warstw zostanie przejęta, reszta może nie zostać „zhackowana” w klasycznym sensie. Może po prostu wykonać obce działanie, używając własnych, legalnych poświadczeń.
Podsumowanie
To już nie wygląda jak jeden incydent. To wygląda jak systematyczne testowanie granic zaufania, na których opiera się codzienna praca developerów — pięć ekosystemów w pięć dni, z eskalacją techniczną od kroku do kroku.
Nie repozytorium, tylko ekosystem.
Nie jedna paczka, tylko wiele warstw wykonania.
Nie tylko supply chain, ale przejmowanie środowiska, które ten łańcuch uruchamia.
Źródła
SecurityWeek — o rozszerzeniu kampanii TeamPCP z Trivy na Docker Hub, npm, Open VSX i PyPI oraz o sygnałach możliwego powiązania z Lapsus$.
Datadog Security Labs — o osi czasu kampanii, mechanizmie Trivy → LiteLLM i zaleceniach remediacyjnych.
LiteLLM — oficjalny komunikat projektu o skompromitowanych wersjach 1.82.7 i 1.82.8.
Socket — o systematycznym celowaniu TeamPCP w narzędzia bezpieczeństwa i infrastrukturę open source.
Endor Labs / wtórne analizy techniczne — o skali pobrań LiteLLM i znaczeniu kompromitacji dla środowisk AI.
CrowdStrike / relacje wtórne — o mechanizmie ukrycia działań malware w workflow Trivy.
GitGuardian — o ekspozycji sekretów w incydencie Trivy.
