LiteLLM sobre PyPI atacat per TeamPCP: aprofundiment en la campanya de programari maliciós de robatori de credencials

Inici » Pitó » LiteLLM sobre PyPI atacat per TeamPCP: aprofundiment en la campanya de programari maliciós de robatori de credencials

Durant unes hores, el 24 de març de 2026, un paquet Python molt popular es va convertir discretament en un potent lladre de credencials. Dues versions enverinades de LiteLLM, una biblioteca àmpliament utilitzada com a interfície unificada per a models de llenguatge grans (LLM), es van penjar a PyPI, exposant breument un nombre massiu de sistemes a un atac sofisticat a la cadena de subministrament.

Les versions malicioses, 1.82.7 1.82.8 i, va incloure una càrrega útil multietapa capaç de sifonar secrets de màquines de desenvolupadors, executors de CI/CD, infraestructura al núvol i clústers de Kubernetes, i després exfiltrar-los a servidors controlats per atacants. La campanya ha estat vinculat al grup d'amenaces TeamPCP, que ha estat en una onada de mesos afectant Trivy, les eines de Checkmarx, les imatges de Docker, atacs a la cadena de subministrament de NPM i ara l'ecosistema PyPI.

Què és LiteLLM i per què era un objectiu tan privilegiat?

LiteLLM és un biblioteca de codi obert i servidor intermediari de Python que actua com una mena d'adaptador universal per a les API de LLM. Permet que les aplicacions es comuniquin amb més d'un centenar de models diferents (de proveïdors com ara OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI i altres) a través d'una única API d'estil OpenAI.

A causa d'aquest paper, el projecte s'ha integrat profundament en l'ecosistema d'IA. Els informes de diversos proveïdors de seguretat indiquen que LiteLLM veu aproximadament 3-3.4 milions de descàrregues per dia, amb alguna telemetria que suggereix que és present en aproximadament 36% dels entorns de núvol monitoritzatsPer als atacants, comprometre un paquet amb aquesta petjada representa una oportunitat excepcional d'accedir a un flux enorme de dades i credencials sensibles amb un sol moviment.

Per disseny, LiteLLM sovint es troba directament entre aplicacions i múltiples proveïdors de serveis d'IAAquesta posició significa que gestiona rutinàriament claus API, variables d'entorn, fitxers de configuració i altres secrets necessaris per arribar a punts finals LLM externs. Una porta del darrere en una dependència d'aquest tipus pot interceptar i exfiltrar aquests valors silenciosament sense necessitat d'una violació directa de les plataformes aigües amunt.

L'incident també subratlla com d'enredat està el desenvolupament modern: les estacions de treball locals, els pipelines de CI/CD, els clústers de Kubernetes i els comptes al núvol estan tots units mitjançant secrets compartits i automatització. Un sol dependència compromesa en aquest gràfic pot acabar exposant credencials a través de moltes capes de la pila d'una organització, amplificant l'impacte molt més enllà d'un sol host.

Com es van introduir les versions malicioses de LiteLLM

Els llançaments enverinats LiteLLM 1.82.7 i 1.82.8 van ser enviats a PyPI el matí del 24 de març de 2026, al voltant de 08:30UTCVan romandre disponibles durant gairebé dues hores abans de ser posats en quarantena per l'equip de seguretat de PyPI i bloquejats per defenses de tercers, i es va informar que s'havien eliminat al voltant de 11:25UTC.

El que fa que aquest cas sigui destacable és que La porta del darrere no apareixia al codi font corresponent de GitHub.Endor Labs i altres investigadors van descobrir que la lògica maliciosa s'injectava a la roda compilada distribuïda a PyPI, no al repositori públic, cosa que suggereix que el compromís es va produir durant o després del procés de compilació/publicació en lloc de fer-ho mitjançant una confirmació de codi visible.

Concretament, els analistes van observar que l'arxiu litellm/proxy/proxy_server.py contenia una càrrega útil codificada en base64 integrada que era absent del mateix fitxer al commit de GitHubEs van inserir aproximadament una dotzena de línies entre blocs de codi que d'altra banda serien legítims (per exemple, a prop de la definició de REALTIME_REQUEST_SCOPE_TEMPLATE i la showwarning funció). Aquestes línies addicionals descodificaven i executaven silenciosament un script ocult cada vegada que s'importava el mòdul.

En versió 1.82.8, els atacants van anar un pas més enllà llançant un .pth fitxer anomenat litellm_init.pth a l'entorn Python. Com que Python processa tot .pth fitxers a l'inici de l'intèrpret, això assegurava que la càrrega útil s'executés a cada invocació de Python, fins i tot si l'aplicació no va importar mai el mateix LiteLLM.

Aquesta escalada va fer 1.82.8 significativament més perillós: qualsevol script de Python, executor de proves, eina de compilació o automatització iniciada en un entorn amb el paquet compromès instal·lat activaria silenciosament la lògica de robatori de credencials en segon pla.

Connexió amb la campanya més àmplia de TeamPCP

El compromís de LiteLLM no va succeir de manera aïllada. Les investigacions de Sonatype, Wiz, Endor Labs i altres ho vinculen a un campanya de cadena de subministrament en curs dirigida per TeamPCP, un grup que va cridar l'atenció a finals del 2025 i que des de llavors s'ha centrat en una sèrie de projectes de codi obert i ecosistemes de desenvolupadors.

A principis de març, els mateixos actors van ser vinculats a l'intrusió de El truc d'Aqua Security escàner de vulnerabilitats i accions de GitHub relacionades, així com a variants malicioses de les eines de Checkmarx, incloent-hi KICS, Accions de GitHub i extensions d'OpenVSX. La campanya també ha afectat paquets npm, imatges de Docker Hub i entorns de Kubernetes, reutilitzant freqüentment infraestructura, esquemes de xifratge i artefactes de persistència.

En rastrejar l'incident de LiteLLM, els mantenidors van revelar que un Token de publicació de PyPI emmagatzemada com a variable d'entorn al repositori de GitHub de LiteLLM va ser exfiltrada a través del flux de treball de Trivy compromès. Aquest testimoni es va utilitzar de manera abusiva per publicar les versions contaminades de PyPI, permetent als atacants eludir les proteccions de dos factors als comptes d'usuari i injectar rodes malicioses sense alterar el codi font públic.

Els investigadors també assenyalen commits i fluxos de treball sospitosos creats al voltant del 23 de març en repositoris relacionats amb LiteLLM, incloent-hi una branca de curta durada i un flux de treball de GitHub Actions que conté una clau pública RSA familiar que es veu en altres càrregues útils de TeamPCP. La telemetria de les execucions de fluxos de treball suggereix que és possible que s'hagi accedit a secrets disponibles per a aquests executors de CI i que s'hagin exfiltrat.

En tots els incidents, el grup ha mostrat un patró consistent: robar credencials en un entorn i després passar al següent ecosistemaEn aquest cas, una configuració incorrecta a les accions de GitHub de Trivy va permetre el robatori d'un token privilegiat; aquest token va provocar llançaments maliciosos de Trivy i imatges de Docker; aquests, al seu torn, van permetre comprometre les eines de Checkmarx i, en última instància, el paquet PyPI de LiteLLM.

Com funciona el programari maliciós LiteLLM

Les anàlisis de diversos proveïdors descriuen la porta del darrere LiteLLM com a càrrega útil de Python multietapa i ofuscada en base64 dissenyat per ser discret, flexible i resilient. La lògica s'organitza en aproximadament tres capes, cadascuna de les quals gestiona una fase diferent de l'atac.

A la primera capa, el codi injectat a proxy_server.py o el litellm_init.pth file descodifica i llança un orquestrador ocultEn lloc d'utilitzar funcions fàcilment marcables com ara exec(), l'script es basa en crides de subprocessos i funcionalitats de biblioteca estàndard per executar la càrrega útil descodificada i capturar la seva sortida, cosa que l'ajuda a integrar-se en el comportament normal de l'aplicació.

Un cop en execució, aquest orquestrador recopila la sortida de l'etapa següent, xifra les dades recollides amb AES-256-CBC i després xifra la clau de sessió AES utilitzant una clau pública RSA codificada de manera fixa integrada al codi. El blob i la clau xifrats s'agrupen en un arxiu anomenat tpcp.tar.gz, fent ressò d'altres operacions de TeamPCP, i preparats per a l'exfiltració.

La segona capa és responsable de reconeixement agressiu del sistema i recollida de credencialsEnumera els noms d'amfitrió, la informació d'usuari i de xarxa i les variables d'entorn i, a continuació, escaneja una llarga llista de camins i fitxers de configuració per trobar material sensible. Els objectius inclouen:

• Claus SSH i fitxers de configuració (client i servidor)
• Credencials al núvol per a AWS, GCP i Azure, incloent-hi tokens derivats de metadades
• Fitxers de configuració de Kubernetes, tokens de compte de servei i secrets de clúster
• Fitxers d'entorn tal com .env variants que s'utilitzen sovint per emmagatzemar claus API
• Configuració de CI/CD, secrets i tokens d'accés
• Terraform, Helm i altres artefactes d'IaC o de desplegament
• Cadenes de connexió de base de dades i fitxers de configuració
• Claus privades TLS/SSL i material d'autenticació
• Carteres de criptomoneda i dades relacionades

En alguns entorns, el lladre no s'atura a la recollida. Intenta... utilitzar activament les credencials descobertes, per exemple consultant les API dels proveïdors de núvol, extraient els secrets de Kubernetes o explorant els recursos accessibles, augmentant la possibilitat de moviment lateral i de compromís posterior.

La tercera capa proporciona persistència i control remotEscriu un script de Python al disc (normalment observat com a sysmon.py) i el registra com un servei de llarga durada, sovint disfressat de quelcom benigne com ara un "Servei de telemetria del sistema". Aquest servei contacta periòdicament amb la infraestructura de l'atacant, normalment cada 50 minuts, per obtenir ordres o càrregues útils addicionals.

Els investigadors observen un comportament peculiar aquí: quan certs proveïdors de seguretat van intentar obtenir la càrrega útil del punt final de comandament i control, el servidor va respondre amb un enllaç a una versió remasteritzada de la cançó "Bad Apple!!", aparentment com a tàctica de desviació contra l'anàlisi automatitzadaEn sistemes infectats, però, el mateix mecanisme pot oferir silenciosament noves funcionalitats amb el temps.

Canals d'exfiltració i infraestructura d'atacants

En els incidents de LiteLLM, els analistes van observar comunicació amb almenys dos dominis principals controlats per atacants: modelslitellmcloud i checkmarxzoneAquests s'alineen amb la infraestructura utilitzada en activitats anteriors de TeamPCP i tenen funcions diferents.

L'arxiu xifrat tpcp.tar.gz sol ser penjat a models.litellmcloud, permetent als operadors recuperar credencials robades de milers d'entorns posteriors. En algunes variants, diferents subrutes de checkmarxzone (per exemple, checkmarxzone/raw or .../vsx) s'utilitzen per lliurar scripts de persistència o etapes addicionals.

En sistemes compromesos, els defensors han informat d'un conjunt de problemes recurrents indicadors de compromís (IOC) associat amb el programari maliciós LiteLLM:

• Presència de l'arxiu tpcp.tar.gz en directoris temporals o de treball
• Fitxers temporals com ara /tmp/pglog i /tmp/.pg_state
• Script de Python i rutes de configuració relacionades amb sysmon.py i un fitxer de servei coincident (sovint als directoris de configuració d'usuari o systemd)
• Inesperat litellm_init.pth fitxers als paquets de lloc de Python per a la versió 1.82.8
• Trànsit sortint o cerques DNS que apunten a modelslitellmcloud or checkmarxzone

Es va rastrejar la lògica maliciosa fins a fitxers com ara proxy_server.py (LiteLLM 1.82.7 i 1.82.8) i litellm_init.pth (1.82.8). Els proveïdors de seguretat han catalogat els hashes i altres IoC i continuen actualitzant els seus avisos a mesura que sorgeixen detalls forenses addicionals.

Impacte en entorns d'IA, núvol i CI/CD

Com que LiteLLM s'utilitza molt en Aplicacions i serveis basats en IA, el radi d'explosió pràctic d'aquest compromís s'estén més enllà dels simples consumidors de paquets. Els entorns de núvol on LiteLLM servia com a porta d'entrada als proveïdors de LLM probablement tinguessin secrets coubicats al mateix temps d'execució o espai de configuració.

Wiz i altres observadors estimen que LiteLLM apareix al voltant de un terç dels entorns de núvol observats, cosa que subratlla l'abast potencial. Algunes fonts citades per BleepingComputer han suggerit que el nombre d'esdeveniments d'exfiltració de dades pot arribar als centenars de milers, tot i que la confirmació independent del recompte exacte encara està pendent.

Cal destacar que el programari maliciós emfatitza Comportament sensible a KubernetesEn moltes anàlisis, la càrrega útil intenta desplegar pods privilegiats a tots els nodes d'un clúster i, a continuació, utilitzar aquests pods per accedir a secrets i objectes de configuració. En operacions separades però relacionades de TeamPCP, els investigadors han vist clústers de Kubernetes atacats amb scripts que esborren els nodes quan l'entorn sembla estar ubicat a l'Iran, mentre instal·len portes del darrere (com ara l'anomenat CanisterWorm) en altres llocs.

L'enfocament en les eines de CI/CD és igualment clar. En comprometre les accions de Trivy GitHub, les extensions de Checkmarx VS Code i les accions de GitHub, i ara LiteLLM, els atacants obtenen punts d'entrada on l'automatització ja té amplis privilegis sobre repositoris, crear artefactes i credencials de desplegament. Aquest enfocament converteix eines que, en altres circumstàncies, estarien orientades a la seguretat en trampolins per a un compromís més ampli.

Funcionaris de l'FBI i investigadors de la indústria han advertit que amb grans volums de credencials robades a la mà, és raonable esperar més notificacions d'intrusions, intrusions secundàries i intents d'extorsió en les setmanes i mesos posteriors a la divulgació inicial de LiteLLM.

Mesures de detecció, contenció i remediació

Per a organitzacions que hagin tret o executat versions de LiteLLM 1.82.7 o 1.82.8 des de PyPI, les directrius dels proveïdors de seguretat i els mantenidors de PyPI són contundents: tractar els sistemes afectats com a compromesosLa simple desinstal·lació del paquet no elimina els mecanismes de persistència ni desfà cap robatori de credencials que ja s'hagi pogut produir.

Les accions immediates recomanades inclouen:

• Identificar qualsevol instal·lació de LiteLLM 1.82.7 o 1.82.8 en màquines de desenvolupador, executors de CI/CD, contenidors i entorns de producció.
• Eliminar les versions malicioses i vincular LiteLLM a una versió coneguda com a correcta (amb la 1.82.6 àmpliament citada com l'última versió neta en el moment de l'informe).
• Rota totes les credencials accessible des dels entorns afectats: claus SSH, claus i tokens de proveïdors de núvol, secrets de Kubernetes, secrets de CI/CD, credencials de base de dades, claus TLS i qualsevol secret relacionat amb moneders o pagaments.
• Cerca d'artefactes de persistència, Com ara sysmon.py, definicions de servei systemd sospitoses i fitxers inusuals a ~/.config o directoris temporals com ara /tmp/pglog i /tmp/.pg_state.
• Inspeccionar els clústers de Kubernetes per a pods privilegiats inesperats, especialment en espais de noms com ara kube-systemi per a comptes de servei o vinculacions de rols inusuals.
• Supervisar les connexions de sortida i consultes DNS per a dominis d'atacants coneguts com ara models.litellmcloud i checkmarxzone.

En entorns on la porta del darrere podria haver estat executada durant un període significatiu, molts experts suggereixen que un reconstrucció completa des d'una línia base fiable pot ser el camí més segur, especialment per a infraestructures crítiques. Donada la naturalesa del programari maliciós, no es poden descartar manipulacions subtils o càrregues útils addicionals simplement eliminant el paquet LiteLLM.

També s'està animant les organitzacions a adoptar mesures més robustes gestió de dependències i defenses de la cadena de subministrament: fixació a versions específiques i verificades, habilitació d'eines que bloquegen o marquen paquets maliciosos coneguts en el moment de la ingestió i incorporació d'anàlisis de comportament automatitzades que poden detectar activitat inesperada de la xarxa o del sistema de fitxers durant les compilacions i les proves.

Què diu el cas LiteLLM sobre les cadenes de subministrament de programari d'IA

L'incident de LiteLLM destaca una tendència més àmplia que s'ha anat construint durant els darrers anys: Els components d'alt ús en la IA i les piles de núvol s'estan convertint en objectius principals per als atacants de la cadena de subministrament. En lloc d'anar directament a les aplicacions dels usuaris finals, els actors d'amenaces busquen cada cop més punts de la cadena d'eines on comprometre una sola biblioteca o complement permet accedir a moltes organitzacions posteriors.

Paquets com ara LiteLLM es troben efectivament en un punt d'estrangulament dels secretsIntervenen en trucades a proveïdors d'IA, toquen sistemes d'automatització d'infraestructures i de CI/CD, i sovint funcionen amb permisos elevats. A mesura que més empreses s'afanyen a integrar les capacitats de LLM mitjançant eines de codi obert, el valor d'aquests components (i l'incentiu per fer-los passar per alt) no fa més que créixer.

Alhora, l'atac il·lustra els reptes de defensar les pipelines de compilació i publicació. En aquest cas, els atacants presumptament van aprofitar una configuració incorrecta del flux de treball de Trivy per robar un token, i després van utilitzar aquest token per enviar paquets contaminats a PyPI, tot deixant l'arbre de codi font públic aparentment net. Les etiquetes de versió i els passos de compilació es van convertir en part de la superfície d'atac, explotant el fet que molts pipelines es basen en etiquetes en lloc de commits fixats i poden confiar implícitament en artefactes provinents de mantenidors familiars.

Venedors com Sonatype, Wiz i Endor Labs emfatitzen la importància de mesures de seguretat automatitzades i en temps real que poden detectar comportaments anòmals, com ara destinacions de xarxa no vistes prèviament o exfiltració xifrada, fins i tot quan les metadades del paquet i l'historial del repositori semblen legítims. Els tallafocs dels repositoris, els escàners basats en intel·ligència d'amenaces i l'anàlisi contextual de les dependències es consideren cada cop més com a capes necessàries, no com a extres opcionals.

Tant per als mantenidors com per a les organitzacions, el compromís de LiteLLM és un recordatori que gestió de secrets, enduriment de CI/CD i rotació de credencials són fonamentals per a la seguretat de la cadena de subministrament. La rotació incompleta o no atòmica de credencials en incidents anteriors va deixar obertures que TeamPCP va poder reutilitzar setmanes més tard, demostrant com un sol pas en fals en la resposta a incidents pot propagar-se a través dels ecosistemes.

La campanya que va arrasar amb LiteLLM va començar amb el que semblava un problema de flux de treball limitat i des de llavors ha abastat GitHub Actions, Docker Hub, l'incident de la NPM de Shai-Hulud, OpenVSX i PyPI. Amb portes del darrere amagades en eines i connectors d'IA de gran confiança, i credencials robades que flueixen cap a la infraestructura de l'atacant, l'episodi subratlla la rapidesa amb què la cadena de subministrament de programari pot convertir-se en una superfície d'atac atractiva i altament eficaç.