LiteLLM op PyPI getroffen door TeamPCP: een diepgaande analyse van de malwarecampagne die inloggegevens steelt

Home » Python » LiteLLM op PyPI getroffen door TeamPCP: een diepgaande analyse van de malwarecampagne die inloggegevens steelt

Op 24 maart 2026 veranderde een enorm populair Python-pakket gedurende een paar uur stilletjes in een machtige dief van inloggegevens. Twee besmette releases van LiteLLM, een bibliotheek die veel gebruikt wordt als een uniforme interface voor grote taalmodellen (LLM's)werden geüpload naar PyPI, waardoor een enorm aantal systemen kortstondig werd blootgesteld aan een geavanceerde supply-chain-aanval.

De kwaadaardige versies, 1.82.7 en 1.82.8, bevatte een payload in meerdere fasen die in staat was om geheimen te stelen van ontwikkelaarsmachines, CI/CD-runners, cloudinfrastructuur en Kubernetes-clusters, en deze vervolgens door te sluizen naar servers die door de aanvaller werden beheerd. De campagne is gelinkt aan de TeamPCP-dreigingsgroep, dat al maandenlang Trivy, Checkmarx-tools en Docker-images aanvalt, aanvallen op de toeleveringsketen van npm En nu het PyPI-ecosysteem.

Wat is LiteLLM en waarom was het zo'n belangrijk doelwit?

LiteLLM is een open-source Python-bibliotheek en proxyserver Dit fungeert als een soort universele adapter voor LLM API's. Het stelt applicaties in staat om met meer dan honderd verschillende modellen te communiceren – van aanbieders zoals OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI en anderen – via één enkele API in OpenAI-stijl.

Vanwege die rol is het project diep verankerd geraakt in het AI-ecosysteem. Rapporten van verschillende beveiligingsleveranciers geven aan dat LiteLLM ongeveer 100% van de gebruikers betreft. 3 tot 3.4 miljoen downloads per dag, waarbij sommige telemetriegegevens suggereren dat het aanwezig is in ongeveer 36% van de bewaakte cloudomgevingenVoor aanvallers betekent het compromitteren van een pakket met een dergelijke vingerafdruk een zeldzame kans om in één klap toegang te krijgen tot een enorme hoeveelheid gevoelige gegevens en inloggegevens.

LiteLLM is zo ontworpen dat het vaak precies tussen twee uitersten in staat. toepassingen en meerdere AI-dienstverlenersDie positie houdt in dat er routinematig API-sleutels, omgevingsvariabelen, configuratiebestanden en andere geheimen worden verwerkt die nodig zijn om externe LLM-eindpunten te bereiken. Een achterdeur in een dergelijke afhankelijkheid kan deze waarden ongemerkt onderscheppen en doorsluizen zonder dat er een directe inbreuk op de upstream-platformen zelf nodig is.

Het incident onderstreept tevens hoe complex moderne softwareontwikkeling is: lokale werkstations, CI/CD-pipelines, Kubernetes-clusters en cloudaccounts zijn allemaal met elkaar verbonden via gedeelde geheimen en automatisering. Een enkel gecompromitteerde afhankelijkheid in die grafiek Dit kan ertoe leiden dat inloggegevens op meerdere niveaus binnen de infrastructuur van een organisatie openbaar worden, waardoor de impact veel groter wordt dan op één enkele host.

Hoe de kwaadaardige LiteLLM-versies werden geïntroduceerd

De vergiftigde stoffen komen vrij. LiteLLM 1.82.7 en 1.82.8 werden op de ochtend van 24 maart 2026 naar PyPI geüpload, rond 08: 30 GMTZe bleven bijna twee uur beschikbaar voordat ze door het PyPI-beveiligingsteam in quarantaine werden geplaatst en door externe beveiligingssystemen werden geblokkeerd. De verwijdering werd rond die tijd gemeld. 11: 25 GMT.

Wat deze zaak opmerkelijk maakt, is dat de De backdoor is niet gevonden in de bijbehorende GitHub-broncode.Endor Labs en andere onderzoekers ontdekten dat de kwaadaardige logica werd geïnjecteerd in het gebouwde wheel dat op PyPI werd gedistribueerd, en niet in de openbare repository. Dit suggereert dat de inbreuk plaatsvond tijdens of na het bouw-/publicatieproces, in plaats van via een zichtbare codecommit.

Analisten merkten met name op dat het bestand litellm/proxy/proxy_server.py bevatte een ingebedde base64-gecodeerde payload die was ontbreekt in hetzelfde bestand in de GitHub-commitEr werden ongeveer twaalf regels ingevoegd tussen verder legitieme codeblokken (bijvoorbeeld in de buurt van de definitie van REALTIME_REQUEST_SCOPE_TEMPLATE en showwarning functie). Die extra regels decodeerden en voerden stilletjes een verborgen script uit telkens wanneer de module werd geïmporteerd.

In versie 1.82.8De aanvallers gingen nog een stap verder door een .pth bestand met de naam litellm_init.pth in de Python-omgeving. Omdat Python alle processen uitvoert. .pth bestanden bij het opstarten van de interpreter, dit zorgde ervoor dat de payload zou worden uitgevoerd bij elke Python-aanroep, zelfs als LiteLLM zelf nooit door de applicatie is geïmporteerd.

Deze escalatie zorgde ervoor dat 1.82.8 aanzienlijk gevaarlijkerElk Python-script, testrunner, buildtool of automatiseringsapplicatie die wordt uitgevoerd in een omgeving waar het gecompromitteerde pakket is geïnstalleerd, activeert ongemerkt de logica voor het stelen van inloggegevens op de achtergrond.

Verbinding met de bredere TeamPCP-campagne

Het LiteLLM-compromis is geen op zichzelf staand incident. Onderzoek door Sonatype, Wiz, Endor Labs en anderen linken het aan een Doorlopende campagne voor de toeleveringsketen, uitgevoerd door TeamPCP., een groep die eind 2025 de aandacht trok en sindsdien een reeks open-sourceprojecten en ontwikkelaarsecosystemen als doelwit heeft genomen.

Eerder in maart werden dezelfde acteurs in verband gebracht met het via een achterdeur toegang verkrijgen tot... Aqua Security's Trivy kwetsbaarheidsscanners en gerelateerde GitHub Actions, evenals kwaadaardige varianten van Checkmarx-tools, waaronder KICSDe campagne omvatte onder andere GitHub Actions en OpenVSX-extensies. Ook npm-pakketten, Docker Hub-images en Kubernetes-omgevingen werden aangepakt, waarbij infrastructuur, versleutelingsschema's en persistentie-artefacten regelmatig werden hergebruikt.

Bij het traceren van het LiteLLM-incident hebben de beheerders onthuld dat een PyPI-publicatietoken Een token dat als omgevingsvariabele was opgeslagen in de GitHub-repository van LiteLLM, werd via de gecompromitteerde Trivy-workflow buitgemaakt. Dat token werd vervolgens misbruikt om... publiceer de besmette PyPI-releaseswaardoor de aanvallers tweefactorauthenticatie op gebruikersaccounts kunnen omzeilen en kwaadaardige wheels kunnen injecteren zonder de openbare broncode te wijzigen.

Onderzoekers wijzen ook op verdachte commits en workflows die rond 23 maart zijn aangemaakt in LiteLLM-gerelateerde repositories, waaronder een kortstondige branch en een GitHub Actions-workflow met een bekende RSA-publieke sleutel die ook in andere TeamPCP-payloads voorkomt. Telemetrie van workflow-uitvoeringen suggereert dat geheimen die beschikbaar waren voor deze CI-runners mogelijk zijn onderschept en gestolen.

Bij alle incidenten heeft de groep een consistent patroon laten zien: Inloggegevens stelen in de ene omgeving en vervolgens overstappen naar het volgende ecosysteem.In dit geval leidde een verkeerde configuratie in Trivy's GitHub Actions tot de diefstal van een geprivilegieerd token; dat token maakte kwaadaardige Trivy-releases en Docker-images mogelijk; die maakten op hun beurt de compromittering van Checkmarx-tools en uiteindelijk het LiteLLM PyPI-pakket mogelijk.

Hoe de LiteLLM-malware werkt

Analyses van meerdere leveranciers beschrijven de LiteLLM-achterdeur als een meertraps, base64-versleutelde Python-payload Ontworpen om onopvallend, flexibel en veerkrachtig te zijn. De logica is grofweg opgebouwd uit drie lagen, die elk een andere fase van de aanval afhandelen.

In de eerste laag wordt de geïnjecteerde code in proxy_server.py of de litellm_init.pth filet decodeert en start een verborgen orchestratorIn plaats van gebruik te maken van functies die gemakkelijk te herkennen zijn, zoals exec()Het script maakt gebruik van subprocess-aanroepen en standaardbibliotheekfunctionaliteit om de gedecodeerde payload uit te voeren en de uitvoer vast te leggen, waardoor het naadloos aansluit op het normale applicatiegedrag.

Zodra deze orchestrator actief is, verzamelt hij de uitvoer van de volgende fase. versleutelt de verzamelde gegevens met AES-256-CBC Vervolgens versleutelt het de AES-sessiesleutel zelf met behulp van een hardgecodeerde RSA-publieke sleutel die in de code is ingebouwd. De versleutelde gegevens en de sleutel worden gebundeld in een archief met de naam tpcp.tar.gz, in navolging van andere TeamPCP-operaties, en voorbereid op exfiltratie.

De tweede laag is verantwoordelijk voor agressieve systeemverkenning en het verzamelen van inloggegevensHet inventariseert hostnamen, gebruikers- en netwerkinformatie en omgevingsvariabelen, en scant vervolgens een lange lijst met paden en configuratiebestanden op gevoelige gegevens. Doelwitten zijn onder andere:

• SSH-sleutels en configuratiebestanden (client en server)
• Cloud-referenties voor AWS, GCP en Azure, inclusief op metadata gebaseerde tokens
• Kubernetes kubeconfig-bestanden, serviceaccounttokens en clustergeheimen
• Omgevingsbestanden zoals .env varianten die vaak worden gebruikt om API-sleutels op te slaan
• CI/CD-configuratie, geheimen en toegangstokens
• Terraform, Helm en andere IaC- of implementatie-artefacten
• Databaseverbindingsreeksen en configuratiebestanden
• TLS/SSL privésleutels en authenticatiemateriaal
• Portefeuilles met cryptocurrency en gerelateerde gegevens

In sommige omgevingen stopt de dief niet bij het ophalen. Hij probeert dan ook om... actief gebruikmaken van gevonden inloggegevensbijvoorbeeld door API's van cloudproviders te bevragen, Kubernetes-geheimen op te halen of bereikbare resources te verkennen, waardoor de kans op laterale verplaatsing en daaropvolgende inbreuken toeneemt.

De derde laag biedt persistentie en afstandsbedieningHet schrijft een Python-script naar de schijf (vaak te zien als sysmon.py) en registreert het als een langlopende service, vaak vermomd als iets onschuldigs zoals een "Systeemtelemetrieservice". Deze service neemt periodiek contact op met de infrastructuur van de aanvaller, meestal elke 50 minuten, om aanvullende commando's of payloads op te halen.

Onderzoekers merken hier wat eigenaardig gedrag op: toen bepaalde beveiligingsleveranciers probeerden de payload van het command-and-control-eindpunt te verkrijgen, reageerde de server met een link naar een geremasterde versie van het nummer "Bad Apple!!", blijkbaar als een afleidingstactiek tegen geautomatiseerde analyseOp geïnfecteerde systemen kan hetzelfde mechanisme echter in de loop van de tijd ongemerkt nieuwe functionaliteit leveren.

Exfiltratiekanalen en aanvallersinfrastructuur

Tijdens de LiteLLM-incidenten constateerden analisten communicatie met ten minste twee belangrijke domeinen die door de aanvallers werden beheerd: modelslitellmcloud en checkmarxzoneDeze sluiten aan op de infrastructuur die eerder bij TeamPCP-activiteiten is gebruikt en vervullen verschillende functies.

Het versleutelde archief tpcp.tar.gz is typisch geüpload naar models.litellmcloudwaardoor de beheerders gestolen inloggegevens kunnen ophalen uit duizenden downstream-omgevingen. In sommige varianten zijn er verschillende subpaden van checkmarxzone (bijvoorbeeld, checkmarxzone/raw or .../vsx) worden gebruikt om persistentiescripts of extra fasen uit te voeren.

Op gecompromitteerde systemen hebben verdedigers een reeks terugkerende problemen gemeld. indicatoren van compromis (IoC's) geassocieerd met de LiteLLM-malware:

• Aanwezigheid van het archief tpcp.tar.gz in tijdelijke of werkmappen
• Tijdelijke bestanden zoals /tmp/pglog en /tmp/.pg_state
• Python-script- en configuratiepaden gerelateerd aan sysmon.py en een bijbehorend servicebestand (vaak te vinden in de configuratiemappen van de gebruiker of systemd).
• Onverwacht litellm_init.pth bestanden in Python site-packages voor versie 1.82.8
• Uitgaand verkeer of DNS-zoekopdrachten die verwijzen naar modelslitellmcloud or checkmarxzone

Kwaadaardige logica werd getraceerd naar bestanden, waaronder proxy_server.py (LiteLLM 1.82.7 en 1.82.8) en litellm_init.pth (1.82.8). Beveiligingsleveranciers hebben hashes en andere IoC's gecatalogiseerd en blijven hun adviezen bijwerken naarmate er meer forensische details aan het licht komen.

Impact op AI-, cloud- en CI/CD-omgevingen

Omdat LiteLLM veelvuldig wordt gebruikt in AI-gestuurde toepassingen en dienstenDe praktische gevolgen van dit compromis reiken verder dan alleen gebruikers van softwarepakketten. In cloudomgevingen waar LiteLLM fungeerde als toegangspoort tot LLM-providers, is de kans groot dat geheimen zich in dezelfde runtime- of configuratieomgeving bevinden.

Wiz en andere waarnemers schatten dat LiteLLM over ongeveer een derde van de waargenomen wolkenomgevingenDit onderstreept de potentiële reikwijdte. Sommige bronnen die door BleepingComputer worden aangehaald, suggereren dat het aantal datalekken in de honderdduizenden kan lopen, hoewel onafhankelijke bevestiging van de exacte aantallen nog moet worden afgewacht.

Het is opvallend dat de malware de nadruk legt op Kubernetes-bewust gedragIn veel analyses probeert de payload geprivilegieerde pods te implementeren op alle knooppunten in een cluster, om die pods vervolgens te gebruiken voor toegang tot geheimen en configuratieobjecten. In afzonderlijke, maar verwante TeamPCP-operaties hebben onderzoekers gezien dat Kubernetes-clusters werden aangevallen met scripts die knooppunten wissen wanneer de omgeving zich in Iran lijkt te bevinden, terwijl er elders backdoors (zoals de zogenaamde CanisterWorm) worden geïnstalleerd.

De focus op CI/CD-tools is eveneens duidelijk. Door Trivy GitHub Actions, Checkmarx VS Code-extensies en GitHub Actions, en nu ook LiteLLM te compromitteren, krijgen aanvallers toegangspunten waar Automatisering heeft al ruime bevoegdheden. via repositories, build-artefacten en implementatiegegevens. Deze aanpak verandert anderszins op beveiliging gerichte tools in opstapjes voor een bredere inbreuk.

FBI-functionarissen en onderzoekers uit de sector hebben gewaarschuwd dat met grote hoeveelheden gestolen inloggegevens in bezitHet is redelijk om te verwachten dat er in de weken en maanden na de eerste onthulling van LiteLLM meer meldingen van datalekken, secundaire inbreuken en afpersingspogingen zullen volgen.

Stappen voor detectie, beheersing en sanering

Voor organisaties die mogelijk LiteLLM-versies hebben gedownload of uitgevoerd 1.82.7 of 1.82.8 De richtlijnen van beveiligingsleveranciers en PyPI-beheerders zijn, vanuit het perspectief van PyPI, zeer duidelijk: Beschouw getroffen systemen als gecompromitteerd.Het simpelweg verwijderen van het pakket heft de persistentiemechanismen niet op en maakt eventuele reeds gepleegde diefstal van inloggegevens niet ongedaan.

Aanbevolen acties die direct ondernomen moeten worden, zijn onder andere:

• Identificeer alle installaties van LiteLLM 1.82.7 of 1.82.8 op ontwikkelmachines, CI/CD-runners, containers en productieomgevingen.
• Verwijder de schadelijke versies en LiteLLM vastzetten op een bekende, stabiele release (waarbij 1.82.6 algemeen wordt beschouwd als de laatst bekende stabiele versie op het moment van dit rapport).
• Alle inloggegevens vernieuwen Toegankelijk vanuit de getroffen omgevingen: SSH-sleutels, sleutels en tokens van cloudproviders, Kubernetes-geheimen, CI/CD-geheimen, databasegegevens, TLS-sleutels en alle wallets of betalingsgerelateerde geheimen.
• Zoek naar persistentie-artefacten, zoals sysmon.pyverdachte systemd-servicedefinities en ongebruikelijke bestanden onder ~/.config of tijdelijke mappen zoals /tmp/pglog en /tmp/.pg_state.
• Inspecteer Kubernetes-clusters voor onverwachte geprivilegieerde pods, vooral in namespaces zoals kube-systemen voor ongebruikelijke serviceaccounts of roltoewijzingen.
• Uitgaande verbindingen bewaken en DNS-query's voor bekende aanvallersdomeinen zoals models.litellmcloud en checkmarxzone.

In omgevingen waar de backdoor mogelijk gedurende een langere periode actief is geweest, suggereren veel experts dat een volledige heropbouw vanuit een betrouwbare basislijn Dit is wellicht de veiligste optie, vooral voor kritieke infrastructuur. Gezien de aard van de malware kan subtiele manipulatie of de installatie van extra payloads niet volledig worden uitgesloten door alleen het LiteLLM-pakket te verwijderen.

Organisaties worden ook aangemoedigd om robuustere maatregelen te nemen. afhankelijkheidsbeheer en verdediging van de toeleveringsketenDit omvat het vastzetten aan specifieke, geverifieerde versies, het inschakelen van tools die bekende kwaadwillende pakketten blokkeren of markeren tijdens de import, en het integreren van geautomatiseerde gedragsanalyse die onverwachte netwerk- of bestandssysteemactiviteit kan detecteren tijdens builds en tests.

Wat de LiteLLM-zaak ons ​​leert over de toeleveringsketens van AI-software.

Het LiteLLM-incident illustreert een bredere trend die zich de afgelopen jaren heeft ontwikkeld: Componenten met een hoge impact in AI- en cloudstacks worden steeds vaker doelwitten voor overnames. Voor aanvallers in de toeleveringsketen. In plaats van zich direct te richten op eindgebruikersapplicaties, zoeken cybercriminelen steeds vaker naar zwakke punten in de toolchain waar het compromitteren van één enkele bibliotheek of plug-in toegang geeft tot veel downstream-organisaties.

Pakketten zoals LiteLLM bevinden zich feitelijk op een knelpunt voor geheimenZe bemiddelen bij gesprekken met AI-leveranciers, hebben interactie met CI/CD- en infrastructuurautomatiseringssystemen en draaien vaak met verhoogde machtigingen. Naarmate meer bedrijven zich haasten om LLM-functionaliteiten te integreren met behulp van open-source tools, neemt de waarde van dergelijke componenten – en de prikkel om er achterdeuren in te bouwen – alleen maar toe.

Tegelijkertijd illustreert de aanval de uitdagingen van het beveiligen van build- en publicatiepipelines. In dit geval zouden de aanvallers een verkeerde configuratie van een Trivy-workflow hebben misbruikt om een ​​token te stelen. Vervolgens gebruikten ze dat token om besmette pakketten naar PyPI te pushen, terwijl de openbare broncode ogenschijnlijk schoon bleef. Versielabels en bouwstappen werden onderdeel van het aanvalsoppervlak.waarbij gebruik wordt gemaakt van het feit dat veel pipelines afhankelijk zijn van tags in plaats van vastgezette commits en impliciet artefacten kunnen vertrouwen die afkomstig zijn van bekende beheerders.

Leveranciers zoals Sonatype, Wiz en Endor Labs benadrukken het belang van geautomatiseerde, realtime beveiligingsmaatregelen die afwijkend gedrag kunnen detecteren – zoals voorheen onbekende netwerkbestemmingen of versleutelde data-exfiltratie – zelfs wanneer pakketmetadata en repositorygeschiedenis legitiem lijken. Repositoryfirewalls, op dreigingsinformatie gebaseerde scanners en contextuele analyse van afhankelijkheden worden steeds vaker gezien als noodzakelijke lagen, en niet als optionele extra's.

Voor zowel beheerders als organisaties is het LiteLLM-compromis een herinnering dat Beheer van geheimen, CI/CD-beveiliging en inlogrotatie zijn van fundamenteel belang voor de beveiliging van de toeleveringsketen. Onvolledige of niet-atomaire rotatie van inloggegevens bij eerdere incidenten liet openingen achter die TeamPCP weken later opnieuw kon benutten, wat aantoont hoe een enkele misstap in de incidentrespons een domino-effect kan hebben op ecosystemen.

De campagne die LiteLLM in de greep kreeg, begon met wat leek op een beperkt workflowprobleem en heeft zich sindsdien uitgebreid naar GitHub Actions, Docker Hub, het Shai-Hulud npm-incidentOpenVSX en PyPI. Met achterdeuren die verborgen zitten in algemeen vertrouwde tools en AI-connectoren, en gestolen inloggegevens die naar de infrastructuur van aanvallers stromen, onderstreept deze episode hoe snel de softwareleveringsketen een aantrekkelijk en zeer effectief aanvalsoppervlak kan worden.