LiteLLM pe PyPI lovit de TeamPCP: analiză detaliată a campaniei de malware care fură credențiale

Acasă » Piton » LiteLLM pe PyPI lovit de TeamPCP: analiză detaliată a campaniei de malware care fură credențiale

Pe 24 martie 2026, timp de câteva ore, un pachet Python extrem de popular s-a transformat în liniște într-un puternic hoț de credențiale. Două versiuni otrăvite ale LiteLLM, o bibliotecă utilizată pe scară largă ca... interfață unificată pentru modele lingvistice mari (LLM), au fost încărcate pe PyPI, expunând pentru scurt timp un număr masiv de sisteme unui atac sofisticat asupra lanțului de aprovizionare.

Versiunile rău intenționate, 1.82.7 și 1.82.8, a inclus o sarcină utilă în mai multe etape capabilă să extragă secrete de pe mașinile dezvoltatorilor, de pe rulourile CI/CD, de pe infrastructura cloud și de pe clusterele Kubernetes, apoi să le exfiltreze către servere controlate de atacatori. Campania a fost legat de grupul de amenințări TeamPCP, care a fost într-o perioadă de luni întregi de atacuri asupra Trivy, instrumentelor Checkmarx, imaginilor Docker, atacuri asupra lanțului de aprovizionare NPM și acum ecosistemul PyPI.

Ce este LiteLLM și de ce a fost o țintă atât de importantă?

LiteLLM este un bibliotecă Python open-source și server proxy care acționează ca un fel de adaptor universal pentru API-urile LLM. Permite aplicațiilor să comunice cu peste o sută de modele diferite – de la furnizori precum OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI și alții – prin intermediul unei singure API, în stil OpenAI.

Datorită acestui rol, proiectul a devenit profund integrat în ecosistemul inteligenței artificiale. Rapoartele de la mai mulți furnizori de servicii de securitate indică faptul că LiteLLM vede aproximativ 3-3.4 milioane de descărcări pe zi, cu unele date telemetrice care sugerează că este prezent în aproximativ 36% din mediile cloud monitorizatePentru atacatori, compromiterea unui pachet cu o astfel de amprentă reprezintă o șansă rară de a accesa un flux imens de date și acreditări sensibile cu o singură mișcare.

Prin design, LiteLLM se află adesea direct între aplicații și mai mulți furnizori de servicii de inteligență artificialăAceastă poziție înseamnă că gestionează în mod curent cheile API, variabilele de mediu, fișierele de configurare și alte secrete necesare pentru a ajunge la punctele finale LLM externe. Un backdoor dintr-o astfel de dependență poate intercepta și exfiltra în mod discret aceste valori fără a necesita o încălcare directă a platformelor din amonte.

Incidentul subliniază, de asemenea, cât de încurcată este dezvoltarea modernă: stațiile de lucru locale, conductele CI/CD, clusterele Kubernetes și conturile cloud sunt toate legate între ele prin secrete partajate și automatizare. Un singur... dependență compromisă în acel graf poate ajunge să expună acreditări pe mai multe niveluri ale stivei unei organizații, amplificând impactul mult dincolo de o singură gazdă.

Cum au fost introduse versiunile malițioase de LiteLLM

Eliberările otrăvite LiteLLM 1.82.7 și 1.82.8 au fost transferate către PyPI în dimineața zilei de 24 martie 2026, în jurul 08:30 UTCAcestea au rămas disponibile timp de aproape două ore înainte de a fi puse în carantină de echipa de securitate PyPI și blocate de sisteme de apărare terțe, eliminarea fiind raportată în jur de 11:25 UTC.

Ceea ce face ca acest caz să fie notabil este faptul că backdoor-ul nu a apărut în sursa GitHub corespunzătoareEndor Labs și alți cercetători au descoperit că logica malițioasă a fost injectată în roata construită distribuită pe PyPI, nu în depozitul public, ceea ce sugerează că compromiterea a avut loc în timpul sau după procesul de construire/publicare, mai degrabă decât printr-o confirmare vizibilă a codului.

Mai exact, analiștii au observat că dosarul litellm/proxy/proxy_server.py conținea o sarcină utilă încorporată, codificată în base64, care era absent din același fișier în commit-ul GitHubAproximativ o duzină de linii au fost inserate între blocuri de cod altfel legitime (de exemplu, lângă definiția REALTIME_REQUEST_SCOPE_TEMPLATE si showwarning Acele linii suplimentare decodificau și executau în tăcere un script ascuns de fiecare dată când modulul era importat.

În versiunea 1.82.8, atacatorii au mers cu un pas mai departe aruncând un .pth fișier numit litellm_init.pth în mediul Python. Deoarece Python procesează toate .pth fișiere la pornirea interpretorului, acest lucru a asigurat rularea sarcinii utile la fiecare invocație Python, chiar dacă LiteLLM în sine nu a fost niciodată importat de aplicație.

Această escaladare a făcut 1.82.8 semnificativ mai periculosorice script Python, rulator de teste, instrument de compilare sau automatizare lansată într-un mediu cu pachetul compromis instalat ar declanșa în mod discret logica de furt de credențiale în fundal.

Conexiune la campania mai amplă TeamPCP

Compromisul LiteLLM nu s-a produs izolat. Investigațiile efectuate de Sonatype, Wiz, Endor Labs și alții o leagă de o campanie continuă privind lanțul de aprovizionare, derulată de TeamPCP, un grup care a atras atenția la sfârșitul anului 2025 și care de atunci a vizat o serie de proiecte open-source și ecosisteme de dezvoltatori.

La începutul lunii martie, aceiași actori au fost implicați în misiunea de a descifra Trivy-ul Aqua Security scaner de vulnerabilități și acțiuni GitHub aferente, precum și variantelor rău intenționate ale instrumentelor Checkmarx, inclusiv KICS, Acțiuni GitHub și extensii OpenVSX. Campania a abordat și pachete npm, imagini Docker Hub și medii Kubernetes, reutilizând frecvent infrastructura, schemele de criptare și artefactele de persistență.

Urmărind incidentul LiteLLM, mentenatorii au dezvăluit că un Token de publicare PyPI stocat ca variabilă de mediu în depozitul GitHub al LiteLLM a fost exfiltrat prin fluxul de lucru Trivy compromis. Tokenul respectiv a fost apoi abuzat pentru a publicați versiunile PyPI alterate, permițând atacatorilor să ocolească protecțiile cu doi factori asupra conturilor de utilizator și să injecteze programe malițioase fără a modifica codul sursă public.

Cercetătorii indică, de asemenea, commit-uri și fluxuri de lucru suspecte create în jurul datei de 23 martie în depozitele legate de LiteLLM, inclusiv o ramură de scurtă durată și un flux de lucru GitHub Actions care conține o cheie publică RSA familiară, observată în alte sarcini utile TeamPCP. Telemetria din rularea fluxurilor de lucru sugerează că secretele disponibile pentru acești rulatori CI ar fi putut fi accesate și exfiltrate.

În toate incidentele, grupul a prezentat un tipar constant: fură acreditări într-un mediu, apoi trec la următorul ecosistemÎn acest caz, o configurație greșită în acțiunile GitHub ale Trivy a permis furtul unui token privilegiat; acel token a dus la versiuni Trivy și imagini Docker rău intenționate; acestea, la rândul lor, au permis compromiterea instrumentelor Checkmarx și, în cele din urmă, a pachetului LiteLLM PyPI.

Cum funcționează malware-ul LiteLLM

Analizele efectuate de mai mulți furnizori descriu backdoor-ul LiteLLM ca fiind sarcina utilă Python cu mai multe etape, ofuscată în base64 conceput să fie discret, flexibil și rezistent. Logica este organizată în aproximativ trei straturi, fiecare gestionând o fază diferită a atacului.

În primul strat, codul injectat în proxy_server.py sau litellm_init.pth fişier decodează și lansează un orchestrator ascunsÎn loc să folosești funcții ușor de semnalat, cum ar fi exec(), scriptul se bazează pe apeluri de subprocese și funcționalități standard ale bibliotecii pentru a rula sarcina utilă decodificată și a captura ieșirea acesteia, ajutându-l să se integreze în comportamentul normal al aplicației.

Odată ce rulează, acest orchestrator colectează rezultatul etapei ulterioare, criptează datele colectate cu AES-256-CBC și apoi criptează cheia de sesiune AES folosind o cheie publică RSA hard-coded încorporată în cod. Blobul și cheia criptate sunt grupate într-o arhivă numită tpcp.tar.gz, reflectând alte operațiuni TeamPCP, și pregătit pentru exfiltrare.

Al doilea strat este responsabil pentru recunoaștere agresivă a sistemului și recoltare a acreditărilorEnumeră numele de gazdă, informațiile despre utilizatori și rețea și variabilele de mediu, apoi scanează o listă lungă de căi și fișiere de configurare pentru materiale sensibile. Obiectivele includ:

• Chei SSH și fișiere de configurare (client și server)
• Acreditări în cloud pentru AWS, GCP și Azure, inclusiv token-uri derivate din metadate
• Fișierele de configurare Kubernetes kube, token-uri de cont de serviciu și secrete de cluster
• Fișiere de mediu , cum ar fi .env variante adesea folosite pentru stocarea cheilor API
• Configurație CI/CD, secrete și token-uri de acces
• Terraform, Helm și alte artefacte IaC sau de implementare
• Șiruri de conexiune la baza de date și fișierele de configurare
• Chei private TLS/SSL și material de autentificare
• Portofele de criptare și date aferente

În unele medii, hoțul nu se oprește la colectare. El încearcă să utilizați în mod activ acreditările descoperite, de exemplu prin interogarea API-urilor furnizorilor de cloud, extragerea secretelor Kubernetes sau explorarea resurselor accesibile, crescând șansa de mișcare laterală și compromitere ulterioară.

Al treilea strat oferă persistență și control de la distanțăScrie un script Python pe disc (observat în mod obișnuit ca sysmon.py) și îl înregistrează ca un serviciu de lungă durată, adesea deghizat în ceva benign, cum ar fi un „Serviciu de telemetrie a sistemului”. Acest serviciu contactează periodic infrastructura atacatorului, de obicei la fiecare 50 de minute, pentru a obține comenzi sau sarcini suplimentare.

Cercetătorii observă un comportament ciudat aici: când anumiți furnizori de securitate au încercat să obțină sarcina utilă de la endpoint-ul de comandă și control, serverul a răspuns cu un link către o versiune remasterizată a melodiei „Bad Apple!!”, aparent ca un tactică de diversiune împotriva analizei automatePe sistemele infectate însă, același mecanism poate oferi în mod discret noi funcționalități în timp.

Canale de exfiltrare și infrastructură pentru atacatori

În incidentele LiteLLM, analiștii au observat comunicarea cu cel puțin două domenii principale controlate de atacatori: modelslitellmcloud și checkmarxzoneAcestea se aliniază cu infrastructura utilizată în activitatea anterioară a TeamPCP și îndeplinesc roluri distincte.

Arhiva criptată tpcp.tar.gz este de obicei încărcat pe models.litellmcloud, permițând operatorilor să recupereze acreditări furate din mii de medii downstream. În unele variante, diferite subcăi ale checkmarxzone (de exemplu, checkmarxzone/raw or .../vsx) sunt folosite pentru a livra scripturi de persistență sau etape suplimentare.

Pe sistemele compromise, apărătorii au raportat o serie de probleme recurente indicatori de compromis (IoC) asociat cu malware-ul LiteLLM:

• Prezența arhivei tpcp.tar.gz în directoare temporare sau de lucru
• Fișiere temporare, cum ar fi /tmp/pglog și /tmp/.pg_state
• Script Python și căi de configurare legate de sysmon.py și un fișier de serviciu corespunzător (adesea în directoarele de configurare utilizator sau systemd)
• Neașteptat litellm_init.pth fișiere în pachetele de site Python pentru versiunea 1.82.8
• Trafic de ieșire sau căutări DNS care indică modelslitellmcloud or checkmarxzone

Logica rău intenționată a fost urmărită până la fișiere care includ proxy_server.py (LiteLLM 1.82.7 și 1.82.8) și litellm_init.pth (1.82.8). Furnizorii de servicii de securitate au catalogat hash-uri și alte IoC-uri și continuă să își actualizeze recomandările pe măsură ce apar detalii criminalistice suplimentare.

Impactul asupra mediilor de inteligență artificială, cloud și CI/CD

Deoarece LiteLLM este utilizat intens în Aplicații și servicii bazate pe inteligență artificială, raza practică de explozie a acestui compromis se extinde dincolo de simplii consumatori de pachete. Mediile cloud în care LiteLLM a servit drept poartă de acces către furnizorii LLM au probabil secrete colocate în același spațiu de execuție sau de configurare.

Wiz și alți observatori estimează că LiteLLM apare în aproximativ o treime din mediile cloud observate, subliniind potențiala acoperire. Unele surse citate de BleepingComputer au sugerat că numărul evenimentelor de exfiltrare a datelor ar putea ajunge la sute de mii, deși confirmarea independentă a numărului exact este încă în așteptare.

În special, malware-ul pune accentul pe Comportament conștient de KubernetesÎn multe analize, sarcina utilă încearcă să implementeze pod-uri privilegiate în toate nodurile dintr-un cluster, apoi să utilizeze aceste pod-uri pentru a accesa secrete și obiecte de configurare. În operațiuni TeamPCP separate, dar corelate, cercetătorii au observat clustere Kubernetes vizate de scripturi care șterg nodurile atunci când mediul pare a fi localizat în Iran, instalând în același timp backdoor-uri (cum ar fi așa-numitul CanisterWorm) în alte părți.

Accentul pus pe instrumentele CI/CD este la fel de clar. Prin compromiterea acțiunilor Trivy GitHub, a extensiilor Checkmarx VS Code și a acțiunilor GitHub, și acum a LiteLLM, atacatorii obțin puncte de intrare unde automatizarea are deja privilegii largi peste depozite, construiesc artefacte și acreditări de implementare. Această abordare transformă instrumentele altfel orientate spre securitate în puncte de plecare pentru compromisuri mai ample.

Oficialii FBI și cercetătorii din industrie au avertizat că, odată cu... volume mari de acreditări furate în mână, este rezonabil să ne așteptăm la mai multe notificări de încălcări de securitate, intruziuni secundare și tentative de extorcare în săptămânile și lunile care urmează dezvăluirii inițiale LiteLLM.

Etape de detectare, izolare și remediere

Pentru organizațiile care ar fi putut extrage sau executa versiuni LiteLLM 1.82.7 sau 1.82.8 Conform PyPI, îndrumările furnizorilor de securitate și ale administratorilor PyPI sunt directe: tratați sistemele afectate ca fiind compromiseSimpla dezinstalare a pachetului nu elimină mecanismele de persistență și nu anulează niciun furt de acreditări care s-ar fi putut produce deja.

Acțiunile imediate recomandate includ:

• Identificați orice instalații a LiteLLM 1.82.7 sau 1.82.8 pe mașini de dezvoltator, rulouri CI/CD, containere și medii de producție.
• Eliminați versiunile rău intenționate și atașează LiteLLM la o versiune cunoscută ca fiind bună (cu 1.82.6 citată pe scară largă ca fiind ultima versiune curată la momentul raportării).
• Rotiți toate acreditările accesibile din mediile afectate: chei SSH, chei și token-uri ale furnizorilor de cloud, secrete Kubernetes, secrete CI/CD, acreditări ale bazei de date, chei TLS și orice portofele sau secrete legate de plăți.
• Căutați artefacte de persistență, Cum ar fi sysmon.py, definiții suspecte ale serviciilor systemd și fișiere neobișnuite sub ~/.config sau directoare temporare, cum ar fi /tmp/pglog și /tmp/.pg_state.
• Inspectați clusterele Kubernetes pentru pod-uri privilegiate neașteptate, în special în spații de nume precum kube-systemși pentru conturi de serviciu sau legături de rol neobișnuite.
• Monitorizați conexiunile de ieșire și interogări DNS pentru domeniile atacatorilor cunoscuți, cum ar fi models.litellmcloud și checkmarxzone.

În mediile în care backdoor-ul ar fi putut funcționa pentru o perioadă semnificativă de timp, mulți experți sugerează că un reconstrucție completă de la o bază de încredere poate fi cea mai sigură cale, în special pentru infrastructura critică. Având în vedere natura malware-ului, manipularea subtilă sau sarcinile suplimentare nu pot fi excluse doar prin eliminarea pachetului LiteLLM.

Organizațiile sunt, de asemenea, încurajate să adopte măsuri mai robuste gestionarea dependenței și apărarea lanțului de aprovizionare: fixarea la versiuni specifice, verificate, activarea instrumentelor care blochează sau semnalează pachetele rău intenționate cunoscute în momentul ingerării și încorporarea analizei comportamentale automate care poate detecta activitatea neașteptată a rețelei sau a sistemului de fișiere în timpul buildărilor și testelor.

Ce spune cazul LiteLLM despre lanțurile de aprovizionare cu software de inteligență artificială

Incidentul LiteLLM evidențiază o tendință mai amplă care s-a dezvoltat în ultimii ani: Componentele cu efect de levier ridicat din inteligența artificială și stivele cloud devin ținte principale pentru atacatorii din lanțul de aprovizionare. În loc să atace direct aplicațiile utilizatorilor finali, actorii care atacă în mod amenințător caută din ce în ce mai mult puncte în lanțul de instrumente unde compromiterea unei singure biblioteci sau plugin oferă acces multor organizații din aval.

Pachete precum LiteLLM se află practic la un punct de blocaj pentru secreteAcestea mediază apeluri către furnizorii de inteligență artificială, ating sisteme de CI/CD și automatizare a infrastructurii și adesea rulează cu permisiuni ridicate. Pe măsură ce tot mai multe companii se grăbesc să integreze capabilitățile LLM folosind instrumente open-source, valoarea acestor componente - și stimulentul de a le proteja prin backdoor - nu fac decât să crească.

În același timp, atacul ilustrează provocările apărării conductelor de compilare și publicare. În acest caz, atacatorii ar fi profitat de o configurație greșită a fluxului de lucru Trivy pentru a fura un token, apoi l-au folosit pentru a trimite pachete contaminate către PyPI, totul lăsând arborele de surse publice aparent curat. Etichetele de versiune și pașii de compilare au devenit parte a suprafeței de atac, exploatând faptul că multe conducte se bazează pe etichete în loc de commit-uri fixate și pot avea implicit încredere în artefacte provenite de la administratori familiari.

Furnizori precum Sonatype, Wiz și Endor Labs subliniază importanța măsuri de siguranță automatizate, în timp real care pot detecta comportamente anormale – cum ar fi destinații de rețea nevăzute anterior sau exfiltrare criptată – chiar și atunci când metadatele pachetelor și istoricul depozitului par legitime. Firewall-urile depozitelor, scanerele bazate pe informații despre amenințări și analiza contextuală a dependențelor sunt din ce în ce mai mult văzute ca straturi necesare, nu ca elemente suplimentare opționale.

Atât pentru mentenatori, cât și pentru organizații, compromisul LiteLLM este o reamintire că gestionarea secretelor, consolidarea CI/CD și rotația acreditărilor sunt fundamentale pentru securitatea lanțului de aprovizionare. Rotația incompletă sau non-atomică a acreditărilor în incidentele anterioare a lăsat goluri pe care TeamPCP a putut să le reutilizeze săptămâni mai târziu, demonstrând cum o singură greșeală în răspunsul la incidente se poate extinde în cascadă în ecosisteme.

Campania care a cuprins LiteLLM a început cu ceea ce părea a fi o problemă limitată a fluxului de lucru și de atunci s-a extins pe GitHub Actions, Docker Hub, incidentul Shai-Hulud NPM, OpenVSX și PyPI. Cu backdoor-uri ascunse în instrumente și conectori AI de încredere, iar datele de autentificare furate curg către infrastructura atacatorilor, episodul subliniază cât de repede poate deveni lanțul de aprovizionare software o suprafață de atac atractivă și extrem de eficientă.