Złośliwe wersje LiteLLM 1.82.7 i 1.82.8: analiza incydentu supply chain powiązanego z TeamPCP - Security Bez Tabu

Złośliwe wersje LiteLLM 1.82.7 i 1.82.8: analiza incydentu supply chain powiązanego z TeamPCP

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki typu software supply chain polegają na kompromitacji narzędzi, bibliotek lub procesów budowania oprogramowania w taki sposób, aby złośliwy kod trafił do legalnych komponentów wykorzystywanych później w środowiskach deweloperskich i produkcyjnych. Incydent dotyczący pakietu LiteLLM pokazuje, jak niebezpieczne może być połączenie popularnej biblioteki Pythona, automatyzacji CI/CD oraz dostępu do zasobów chmurowych i klastrów Kubernetes.

W opublikowanych 24 marca 2026 roku wersjach 1.82.7 i 1.82.8 wykryto mechanizmy backdoor, kradzieży poświadczeń oraz utrwalania dostępu. Szczególnie groźny był fakt, że jedna z tych wersji mogła uruchamiać złośliwy kod automatycznie przy starcie interpretera Pythona.

W skrócie

  • Złośliwe wersje LiteLLM 1.82.7 i 1.82.8 trafiły do repozytorium PyPI i zostały usunięte po wykryciu incydentu.
  • Analizy wskazują na możliwe powiązanie z wcześniejszą kompromitacją łańcucha CI/CD z użyciem Trivy.
  • Payload przechwytywał klucze SSH, dane chmurowe, sekrety Kubernetes, pliki .env oraz inne wrażliwe artefakty.
  • Wersja 1.82.8 wykorzystywała plik .pth do automatycznego uruchamiania kodu bez konieczności bezpośredniego importowania biblioteki.
  • Incydent mógł umożliwiać ruch boczny w klastrach Kubernetes i trwałe osadzenie malware na hostach.

Kontekst / historia

LiteLLM to popularny pakiet Python używany do integracji z modelami językowymi oraz warstwami proxy dla ruchu do dostawców AI. Z perspektywy bezpieczeństwa takie oprogramowanie jest atrakcyjnym celem, ponieważ często działa w środowiskach mających dostęp do sekretów API, danych aplikacyjnych, konfiguracji runtime i poświadczeń chmurowych.

Publiczne ustalenia wskazują, że złośliwe wersje 1.82.7 i 1.82.8 zostały opublikowane 24 marca 2026 roku. Badacze powiązali incydent z szerszą kampanią przypisywaną grupie TeamPCP, wcześniej łączonej z kompromitacją innych elementów ekosystemu open source i infrastruktury bezpieczeństwa. Schemat działania wpisuje się w dobrze znany model eskalacji: przejęcie procesu budowania, pozyskanie poświadczeń z ofiar, a następnie wykorzystanie ich do kompromitacji kolejnych projektów i środowisk.

Znaczące jest również to, że na stronie projektu w PyPI dostępna była wcześniejsza, czysta wersja 1.82.1 z 10 marca 2026 roku. Oznacza to, że złośliwe wydania nie pozostały domyślną aktywną wersją pakietu, ale organizacje, które pobrały je w krótkim oknie kompromitacji, nadal mogły zostać poważnie narażone.

Analiza techniczna

Mechanizm ataku miał charakter wieloetapowy. W wersji 1.82.7 złośliwy kod został osadzony w pliku odpowiedzialnym za komponent proxy. Kluczową cechą tej modyfikacji było wykonywanie payloadu już na etapie importu modułu. W praktyce oznaczało to, że każda aplikacja lub proces ładujący ten komponent mogły uruchomić szkodliwą logikę bez dodatkowej interakcji użytkownika.

W wersji 1.82.8 napastnicy zastosowali bardziej agresywną technikę, dodając do pakietu plik .pth. W ekosystemie Pythona takie pliki umieszczone w site-packages są przetwarzane automatycznie podczas startu interpretera przez mechanizm site.py. Dzięki temu złośliwy kod mógł uruchamiać się przy każdym starcie procesu Python w zainfekowanym środowisku, nawet jeśli sama biblioteka LiteLLM nie była bezpośrednio importowana przez aplikację.

Według analiz plik .pth uruchamiał w tle dodatkowy proces z użyciem subprocess.Popen, który dekodował i wykonywał payload zakodowany w Base64. Następnie aktywowany był komponent orkiestrujący, rozpakowujący dwa główne moduły: harvester poświadczeń oraz dropper odpowiedzialny za persistence.

Zakres kradzieży danych był szeroki i obejmował między innymi:

  • klucze SSH,
  • poświadczenia usług chmurowych,
  • sekrety Kubernetes,
  • portfele kryptowalutowe,
  • pliki .env,
  • inne dane konfiguracyjne przydatne do dalszej ekspansji.

Zebrane dane miały być pakowane do archiwum i wysyłane do infrastruktury C2 kontrolowanej przez napastnika. Badacze wskazali również na funkcjonalność ruchu bocznego w Kubernetes. Jeżeli w środowisku dostępny był token konta serwisowego klastra, malware próbował enumerować węzły, a następnie wdrażać uprzywilejowane pody na każdym z nich. Taki pod mógł uzyskać dostęp do systemu plików hosta i zainstalować mechanizm trwałości jako usługę systemową użytkownika.

Persistence opierało się na usłudze sysmon.service, która uruchamiała skrypt Pythona w katalogu użytkownika i okresowo kontaktowała się z serwerem kontrolnym w celu pobrania kolejnego etapu ładunku. Opisano również mechanizm kill switch, w którym wykonanie było przerywane po spełnieniu określonego warunku zwracanego przez infrastrukturę sterującą.

Z technicznego punktu widzenia incydent jest ważny z trzech powodów: pokazuje kompromitację artefaktu dystrybucyjnego na poziomie wheel, demonstruje skuteczność nadużycia plików .pth jako mało widocznego wektora autostartu oraz łączy klasyczny stealer z funkcjami cloud-native post-exploitation, w tym z ruchem bocznym w Kubernetes.

Konsekwencje / ryzyko

Skutki dla organizacji mogą być bardzo poważne, zwłaszcza jeśli LiteLLM działał w środowiskach produkcyjnych, runnerach CI/CD, platformach AI lub klastrach Kubernetes. Największe ryzyko wynika z możliwości przejęcia tożsamości technicznych i dalszej kompromitacji powiązanych systemów.

  • Wyciek kluczy SSH i dostępów do repozytoriów kodu.
  • Przejęcie kont chmurowych i eskalacja dostępu do usług IaaS oraz PaaS.
  • Kompromitacja sekretów aplikacyjnych, tokenów API i danych środowiskowych.
  • Przejęcie węzłów Kubernetes poprzez uprzywilejowane pody.
  • Długotrwała obecność napastnika dzięki persistence na hostach.
  • Wtórne naruszenia wynikające z wykorzystania skradzionych poświadczeń w innych systemach.

Największym problemem w tego typu zdarzeniach jest efekt domina. Jedna zainfekowana biblioteka może stać się punktem wejścia do wielu środowisk jednocześnie: stacji deweloperskich, pipeline’ów, serwerów aplikacyjnych, platform inferencyjnych i klastrów kontenerowych. Jeżeli organizacja nie ma pełnej widoczności zależności oraz telemetrii wykonania, wykrycie takiego incydentu może nastąpić dopiero po eksfiltracji danych lub ujawnieniu kolejnych oznak ruchu bocznego.

Rekomendacje

Organizacje, które mogły pobrać LiteLLM 1.82.7 lub 1.82.8, powinny potraktować ten incydent jako potencjalne pełne naruszenie zaufania do hosta oraz wszystkich sekretów obecnych w czasie instalacji lub wykonania pakietu.

Rekomendowane działania operacyjne:

  • natychmiast zidentyfikować wszystkie systemy, na których zainstalowano wersje 1.82.7 lub 1.82.8,
  • odizolować podejrzane hosty i workloady od sieci produkcyjnej,
  • usunąć złośliwe wersje i przejść na zweryfikowaną, czystą wersję pakietu,
  • przeszukać site-packages pod kątem nieautoryzowanych plików .pth,
  • sprawdzić obecność artefaktów persistence, w tym usług sysmon.service i skryptów w katalogach użytkownika,
  • przeanalizować logi egress pod kątem połączeń do infrastruktury C2,
  • skontrolować klastry Kubernetes pod kątem nieznanych uprzywilejowanych podów, nietypowych daemonsetów i zmian na węzłach,
  • unieważnić i zrotować wszystkie potencjalnie ujawnione sekrety, takie jak klucze SSH, tokeny API, dane chmurowe, hasła i certyfikaty,
  • przeprowadzić przegląd pipeline’ów CI/CD, szczególnie tam, gdzie używano narzędzi i integracji powiązanych z wcześniejszymi incydentami,
  • wdrożyć pinning wersji, weryfikację integralności artefaktów, SBOM oraz polityki dopuszczania pakietów wyłącznie z zatwierdzonych źródeł.

W dłuższej perspektywie warto rozszerzyć kontrole bezpieczeństwa o:

  • skanowanie behawioralne pakietów open source przed wdrożeniem,
  • detekcję anomalii związanych z uruchamianiem procesów Python,
  • monitorowanie tworzenia usług systemowych i zmian w site-packages,
  • segmentację środowisk build i produkcji,
  • minimalizację uprawnień kont serwisowych w Kubernetes,
  • stosowanie krótkotrwałych poświadczeń zamiast długowiecznych sekretów.

Podsumowanie

Incydent z LiteLLM 1.82.7 i 1.82.8 to kolejny przykład dojrzałego ataku supply chain, w którym napastnicy wykorzystują zaufanie do popularnych komponentów open source oraz słabsze ogniwa w procesie budowania i publikacji pakietów. Technicznie wyróżnia się on połączeniem kradzieży poświadczeń, automatycznego uruchamiania przez plik .pth, ruchu bocznego w Kubernetes i trwałości na poziomie hosta.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: kompromitacja pojedynczego pakietu nie powinna być traktowana wyłącznie jako problem zależności aplikacyjnej, lecz jako potencjalny incydent obejmujący tożsamość, infrastrukturę chmurową, pipeline’y CI/CD oraz klastry kontenerowe. W środowiskach, które miały kontakt ze złośliwymi wersjami, konieczne jest nie tylko usunięcie biblioteki, ale także pełne dochodzenie powłamaniowe i rotacja wszystkich narażonych sekretów.

Źródła