{
	"id": "f2d059de-2373-4285-8e92-2dbfbcb52f22",
	"created_at": "2026-04-10T03:21:04.724573Z",
	"updated_at": "2026-04-10T03:22:19.383338Z",
	"deleted_at": null,
	"sha1_hash": "3b253990b77e51467b0f57de4f4e14f738604d1b",
	"title": "Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2338709,
	"plain_text": "Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply\r\nChain Compromise\r\nBy Peter Girnus, Fernando Tucci, Deep Patel, Simon Dulude, Ashish Verma, John Rainier Navato ( words)\r\nPublished: 2026-03-26 · Archived: 2026-04-10 02:07:44 UTC\r\nArtificial Intelligence (AI)\r\nTeamPCP orchestrated one of the most sophisticated multi-ecosystem supply chain campaigns publicly\r\ndocumented to date. It cascaded through developer tooling and compromised LiteLLM and exposed how AI proxy\r\nservices that concentrate API keys and cloud credentials become high-value collateral when supply chain attacks\r\ncompromise upstream dependencies.\r\nBy: Peter Girnus, Fernando Tucci, Deep Patel, Simon Dulude, Ashish Verma, John Rainier Navato Mar 26, 2026\r\nRead time: 26 min (6971 words)\r\nSave to Folio\r\nKey takeaways\r\nLiteLLM, a widely-used AI proxy package, was compromised on PyPI, with two of its\r\nversions containing malicious code. These LiteLLM versions deployed a three-stage payload: credential\r\nharvesting, Kubernetes lateral movement, and persistent backdoor for remote code execution. Sensitive\r\ndata from cloud platforms, SSH keys, and Kubernetes clusters were targeted and encrypted before\r\nexfiltration.\r\nThe LiteLLM incident was part of a broader campaign by the criminal group TeamPCP, which\r\nhas demonstrated deep understanding of Python execution models, adapting their attack rapidly for stealth\r\nand persistence. \r\nTeamPCP has previously compromised security tools like Trivy and Checkmarx KICS to steal credentials\r\nand propagate malicious payloads. Attackers leveraged compromised CI/CD pipelines and security\r\nscanners to escalate privileges and publish trojanized packages.  \r\nThis is an ongoing and developing story that TrendAI™ will update as new information emerges from our\r\nmonitoring and analysis.\r\nOn March 24, production systems running LiteLLM started dying, and engineers saw runaway processes, CPU\r\npegged at 100%, containers killed by out-of-memory (OOM) errors. The stack traces\r\npointed to the LiteLLM package, a popular Python package downloaded 3.4 million times per day that serves as a\r\nunified gateway to multiple LLM providers, was compromised on PyPI. Upon analysis, it was found that versions\r\n1.82.7 and 1.82.8 contained malicious code that stole cloud credentials, SSH keys, and Kubernetes secrets. \r\nThe malicious versions deployed a three-stage payload: a credential harvester targeting over 50 categories of\r\nsecrets, a Kubernetes lateral movement toolkit capable of compromising entire clusters, and a persistent backdoor\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 1 of 26\n\nproviding ongoing remote code execution.\r\nThe compromise was not an isolated event. It was the latest link in a cascading supply chain campaign by a threat\r\nactor tracked as TeamPCP. This post traces the cascade from its origin, the open-source vulnerability\r\nscanner Trivy, and then presents our technical analysis of the LiteLLM payload.\r\nTeamPCP orchestrated one of the most sophisticated multi-ecosystem supply chain campaigns publicly\r\ndocumented to date.\r\nThe campaign spanned PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX in a single coordinated operation.\r\nWhile it did not specifically target AI infrastructure, the campaign's cascade through developer tooling\r\ncaught LiteLLM in its blast radius and exposed how AI proxy services that concentrate API keys and cloud\r\ncredentials become high-value collateral when supply chain attacks compromise upstream dependencies.\r\nKey sections of this blog entry include a technical analysis of the malicious multi-stage payload and its impact on\r\nAI environments, a timeline and operational review of TeamPCP’s campaign, and a deep dive into how security\r\ntools themselves became attack vectors. TrendAI™ Research's analysis into the LiteLLM compromise also covers\r\nattribution challenges, gaps in public threat intelligence, and actionable defense strategies. Detailed indicators\r\nof compromise and MITRE ATT\u0026CK mappings have been provided, but for an even more comprehensive\r\nunderstanding of this security incident, reach out to TrendAI™ Research for the full technical report. For our\r\nfollow-up coverage on TeamPCP’s Telnyx Python SDK compromise, read our analysis here. \r\nHow your security scanner can become the attack vector\r\nTrivy is an open-source vulnerability scanner developed by Aqua Security. It scans container images, filesystems,\r\nand infrastructure-as-code for security vulnerabilities, and it is integrated into the CI/CD pipelines of thousands of\r\nsoftware projects via the trivy-action GitHub Action.\r\nSecurity scanners are uniquely dangerous supply chain targets. By design, they require broad read access to the\r\nenvironments they scan, including environment variables, configuration files, and runner memory. When a\r\nscanner is compromised, it becomes a credential harvesting platform with legitimate access to secrets.\r\nIn late February 2026, an actor operating under the handle MegaGame10418 exploited a\r\nmisconfigured pull_request_target workflow in Trivy's CI to exfiltrate the aqua-bot Personal Access Token\r\n(T1078 — Valid Accounts). Aqua Security disclosed the incident on March 1 and initiated credential rotation.\r\nHowever, according to Aqua's own post-incident analysis, the rotation \"wasn't atomic and attackers may have been\r\nprivy to refreshed tokens.\"\r\nThat gap proved decisive. On March 19 at 17:43 UTC, TeamPCP used still-valid credentials to force-push 76 of\r\n77 release tags in the trivy-action repository, and all seven tags in setup-trivy, to malicious commits containing a\r\nmulti-stage credential stealer (T1195.002 — Compromise Software Supply Chain). The malicious code scraped\r\nthe Runner.Worker process memory for secrets, harvested cloud credentials and SSH keys from the filesystem,\r\nencrypted the bundle using AES-256-CBC with an RSA-4096 public key, and exfiltrated it to\r\na typosquatted domain (scan[.]aquasecurtiy[.]org, resolving to 45[.]148[.]10[.]212). According to analysis by\r\nCrowdStrike, the legitimate Trivy scan still ran afterward, producing normal output — leaving no\r\nvisible indication of compromise.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 2 of 26\n\nFigure 1 illustrates the chain that made the payload possible, which starts with a compromised security tool.\r\nFigure 1. The attack chain begins with a compromised security tool\r\nThis is the meta-attack: a security scanner, the tool defenders rely on to catch supply chain compromises, became\r\nthe entry point for a supply chain compromise. The Trivy compromise in GitHub Actions gave the attacker the\r\nkeys to publish arbitrary versions of LiteLLM to PyPI. Everything that followed was exploitation of\r\nthat initial foothold.\r\nThe lesson is uncomfortable but critical; your CI/CD security tooling has the same access as your deployment\r\ntooling. If it's compromised, everything downstream is exposed.\r\nTwo versions, two vectors: The 13-minute pivot\r\nThe attack didn't start with the .pth file. It started 13 minutes earlier with a cruder approach, and the rapid iteration\r\ntells a story about the attacker's operational sophistication.\r\nVersion 1.82.7 (10:39 UTC): Payload injected directly into proxy_server.py, executes when the LiteLLM proxy\r\nstarts. More targeted, but more visible in code review. Endor Labs identified three distinct payload\r\niterations within proxy_server.py, suggesting the attacker was testing and refining in near-real-time.\r\nVersion 1.82.8 (10:52 UTC, 13 minutes later): Added the .pth file mechanism, executes at Python interpreter\r\nstartup regardless of what's imported. Stealthier, broader impact. No import LiteLLM required. A\r\nsimple command pip install LiteLLM==1.82.8 activated the payload on every subsequent Python process.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 3 of 26\n\nThis 13-minute iteration, from a function-level injection to interpreter-level persistence, shows an attacker who\r\nunderstood Python's execution model deeply and adapted their delivery mechanism under operational\r\npressure. Figure 2 illustrates how the iteration takes place. \r\nFigure 2. The 13-minute iteration\r\nCatching the malicious payload \r\nLiteLLM is one of the most widely adopted open-source LLM proxy gateways in the AI/ML ecosystem. It sits\r\nbetween application code and model providers, OpenAI, Anthropic, Azure AI, and dozens of others, routing, load-balancing, and logging LLM API calls. Tens of thousands of developers and CI/CD pipelines depend on it daily.\r\nVersion 1.82.8 shipped with something extra: a 34,628-byte file called LiteLLM_init.pth that silently exfiltrated\r\nevery secret it could find to an attacker-controlled server. \r\nA bug in the malicious payload, a fork bomb that spawned runaway processes, is what triggered the analysis.\r\nWithout it, the credential stealer could have run silently for days or weeks before detection. The attacker's own\r\ncoding error became the kill chain's weakest link.\r\nA security researcher opened GitHub issue #24512 against BerriAI's LiteLLM repository with a simple,\r\ndevastating subject line: \"CRITICAL: Malicious LiteLLM_init.pth in LiteLLM 1.82.8 PyPI package, credential\r\nstealer.\" AI researcher Andrej Karpathy noted that the LiteLLM supply chain attack was quickly discovered due to\r\na bug causing a system crash.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 4 of 26\n\nAccording to the security breakdown from FutureSearch, an attacker hijacked the maintainer accounts for\r\nthe litellm project. They bypassed standard GitHub release protocols and pushed compromised versions directly\r\nto PyPI. Because litellm sits between developers and nearly every major LLM endpoint, it gets pulled in as a\r\ndependency by everything from basic scripts to advanced coding agents.\r\nWithin approximately three hours of the first community reports, PyPI yanked versions 1.82.7 and 1.82.8. The\r\nopen-source community self-organized rapidly across GitHub, Twitter/X, and security vendor\r\nchannels. BerriAI engaged Mandiant for incident response. The speed of the defensive response likely limited the\r\nreal-world impact of the credential exfiltration. Though at the time of writing, no public confirmation exists\r\nwhether stolen credentials were successfully used by the attacker before the takedown.\r\n1.82.7 (10:39 UTC): Malicious code injected into proxy_server.py, executed when the LiteLLM proxy\r\nmodule is imported.\r\n1.82.8 (10:52 UTC, 13 minutes later): Retains the same proxy_server.py injection and adds a .pth file\r\n(LiteLLM_init.pth) that executes on any Python interpreter startup — broadening the trigger surface and\r\nproviding a redundant execution path.\r\nTrendAI™ Research has confirmed that both compromised versions, 1.82.7 and 1.82.8, use two attacker-controlled domains serving distinct purposes. Stolen credentials are encrypted with a hybrid RSA-4096 and AES-256 scheme and exfiltrated via HTTPS POST to models[.]litellm[.]cloud, a domain registered just one day before\r\nthe attack. \r\nA separate persistent backdoor polls checkmarx[.]zone every 50 minutes for second-stage payloads, abusing the\r\ntrusted Checkmarx brand name to bypass DNS allowlists. Version 1.82.7 shares code lineage with an earlier\r\nsupply chain campaign that targeted the same infrastructure, while 1.82.8 refines the payload with an identical\r\ndual-domain architecture. \r\nThe malicious versions were discovered not by security tooling, but by accident. Callum McMahon, a researcher\r\nat FutureSearch, was testing a Cursor MCP plugin that pulled in LiteLLM as a transitive dependency. \r\nPyPI quarantined both versions approximately three hours after publication. Multiple downstream\r\nprojects, including DSPy, MLflow, OpenHands, CrewAI, and Arize Phoenix, filed security PRs to pin away from\r\nthe affected versions on the same day.\r\nArchitecture and encoding layers\r\nThe malware is structured as a three-layer base64 encoded Python script. Each layer is decoded and executed at\r\nruntime, creating a chain of in-memory payloads that never touch disk as standalone files.\r\nLayer Name Purpose\r\n0 Launcher One-liner: decodes + executes Layer 1 via subprocess.Popen\r\n1 Orchestrator\r\nContains RSA-4096 public key, embeds Layer 2 \u0026 3, handles\r\nencryption + exfiltration\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 5 of 26\n\n2 Collector (B64_SCRIPT) Comprehensive credential/secret harvester for Linux/cloud\r\n3\r\nPersistence\r\n(PERSIST_B64)\r\nPersistent backdoor with C\u0026C polling loop\r\nTable 1. The multi-layer malware architecture\r\nA technical analysis of how the LiteLLM attack worked\r\nThe PyPI track was the highest-impact vector. Here's exactly what happened when a developer or CI/CD pipeline\r\nran pip install LiteLLM==1.82.8:\r\n1. Package installation: The LiteLLM_init.pth file was deposited into the Python site-packages directory\r\nalongside legitimate LiteLLM files.\r\n2. Automatic activation: On every subsequent Python interpreter startup, the .pth file executed a 3-layer\r\nmatryoshka that contained the orchestrator, the credential harvester, and the persistence daemon. \r\n3. Environment gating: The payload checked for the GITHUB_ACTIONS environment variable. If set, it\r\nactivated, explicitly targeting CI/CD pipeline environments where secrets are most concentrated. It also\r\nperformed locale and registry geofencing to exclude specific regions.\r\n4. Credential harvesting: The payload swept the system for SSH keys, AWS/GCP/Azure IAM credentials,\r\nKubernetes configs, Docker registry tokens, npm auth tokens, HashiCorp Vault tokens, WireGuard private\r\nkeys, cryptocurrency wallets (Bitcoin, Ethereum, Solana, Exodus, Electrum), shell history, database\r\ncredentials, CI/CD secret files, and, critically for the AI ecosystem, LLM API keys for every provider\r\nconfigured in the environment.\r\n5. Encrypted exfiltration: All harvested data was encrypted with a random AES-256-CBC session key, the\r\nsession key was wrapped with a hardcoded RSA-4096-OAEP public key (ensuring only the attacker could\r\ndecrypt), and the bundle was POSTed via HTTPS to models.LiteLLM.cloud, a domain registered the same\r\nday as the trojanized release and designed to blend into normal LiteLLM API traffic.\r\n6. Persistence: On non-CI systems, the payload installed a systemd user service (sysmon.service) that polled\r\nthe C\u0026C server every 50 minutes for stage-2 payloads, creating a persistent backdoor that survived\r\nreboots.\r\nFigure 3 and the following sections provide more details on the execution flow.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 6 of 26\n\nFigure 3. The attack’s execution flow\r\nInitial Launcher (Layer 0)\r\nThe entire file is a single Python line. When executed, it imports required modules and immediately spawns\r\na child process to execute the base64-decoded Layer 1 payload.\r\nOrchestrator (Layer 1)\r\nLayer 1 defines the RSA public key, embeds , a base64-encoded payload and implements the run() entry point. A\r\n4096-bit RSA public key is hardcoded for hybrid encryption of stolen data. The orchestrator creates a temporary\r\ndirectory and executes the collector script (Layer 2) as a subprocess, capturing all stolen data to a file.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 7 of 26\n\nAfter the collector finishes and writes all stolen data to the temp file, the orchestrator encrypts it using a hybrid\r\nRSA+AES scheme. To do this, it first generates a random 32-byte AES session key using openssl rand. Then, it\r\nencrypts the collected data with AES-256-CBC + PBKDF2 key derivation using the session key. It then encrypts\r\nthe session key with the embedded RSA-4096 public key using OAEP padding, and finally bundles\r\nthe payload.enc + session.key.enc into tpcp.tar.gz. The encrypted bundle is then exfiltrated via HTTP POST to the\r\nattacker-controlled domain.\r\nCollector (Layer 2)\r\nThe credential harvester targets over 50 categories of sensitive data (T1552 — Unsecured Credentials):\r\nSystem reconnaissance: hostname, uname, whoami, ip addr, printenv, running processes, auth logs\r\nSSH keys: All private key formats across all user home directories under /home/ and /root/\r\nCloud credentials: AWS credential files, IMDS v1 and v2 token queries, and — notably — authenticated\r\nSigV4 API calls to AWS Secrets Manager (ListSecrets, GetSecretValue) and SSM Parameter Store\r\n(DescribeParameters). The full SigV4 signing implementation is embedded in the script (T1552.005 —\r\nCloud Instance Metadata API)\r\nGCP and Azure: application_default_credentials.json and ~/.azure/ directory\r\nKubernetes: Service account tokens, kubeconfig files, and API enumeration of all secrets across all\r\nnamespaces\r\nApplication credentials: Git, Docker, npm, Vault, MySQL, PostgreSQL, MongoDB, Redis configs\r\nCryptocurrency wallets: Bitcoin, Ethereum, Solana (with particular focus on validator infrastructure), and\r\nseven additional currencies\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 8 of 26\n\nCI/CD secrets: Terraform state files, Jenkins files, .gitlab-ci.yml, .travis.yml, Ansible configs\r\nTLS/SSL private keys, shell history, /etc/shadow\r\nSystem reconnaissance and SSH key and configuration theft\r\nThe collector begins by establishing helper functions for file reading and command execution,\r\nthen immediately runs system identification commands. The emit() function reads any file and writes its contents\r\nto stdout with a marker header (=== /path ===). The run() function executes shell commands with a 10-second\r\ntimeout and captures output.\r\nAll output is written as binary to stdout, which the orchestrator captures to the collected temp file. The\r\nscript enumerates all user home directories under /home and /root, then reads every SSH private key, authorized\r\nkey, and configuration file. It also targets SSH host keys from the system-level SSH configuration:\r\nCloud provider credential theft\r\nThe script reads AWS credential files from all users, dumps AWS environment variables, and queries EC2\r\nInstance Metadata Service (IMDS) for IAM role credentials using both v1 and v2 token mechanisms.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 9 of 26\n\nWhen AWS credentials are found in environment variables, the script makes authenticated AWS SigV4 API\r\ncalls to steal secrets from AWS Secrets Manager and SSM Parameter Store. The full SigV4 signing\r\nimplementation is embedded in the script. It then queries IMDS v2 with a PUT request for a session token,\r\nfollowed by credential retrieval. With credentials in hand, it calls Secrets\r\nManager ListSecrets + GetSecretValue and SSM DescribeParameters:\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 10 of 26\n\nIt steals all Google Cloud and Microsoft Azure credentials from the system including config files, cached tokens,\r\nservice account keys, and related environment variables.\r\nKubernetes secret exfiltration\r\nThe script reads K8s config files and runs kubectl. It also reads the K8s service account token from the well-known mount path, then uses the K8s API to enumerate all secrets across all namespaces. API-based enumeration\r\nfetches secrets globally and per-namespace.\r\nKubernetes cluster-wide lateral movement\r\nThis is the most destructive behavior. The script enumerates all K8s nodes, then for each node, creates a privileged\r\npod in the kube-system namespace with the host filesystem mounted. The pod writes the persistence backdoor\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 11 of 26\n\n(discussed later on) to the host and enables it as a systemd service. The pod specification uses maximum privilege\r\nescalation.\r\nApplication and infrastructure credential theft\r\nThe collector reads credentials from a wide array of application-specific files. This includes Git, Docker, npm,\r\nVault, FTP, SMTP, MySQL, PostgreSQL, MongoDB, and Redis. System-level configs are also targeted.\r\nFigure 13. Git credential theft reads .git-credentials and .gitconfig from all user home directories\r\nand /root/.\r\nCryptocurrency wallet theft\r\nThe script targets wallet files and configuration across 10 cryptocurrencies, with a heavy focus on Solana validator\r\ninfrastructure. \r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 12 of 26\n\nFigure 15. Cryptocurrency wallet theft across 10 currencies (Bitcoin, Litecoin, Dogecoin, Zcash,\r\nDash, Ripple, Monero, Ethereum keystores, Cardano) with particular focus on Solana validator\r\ninfrastructure — targeting validator-keypair.json, authorized-withdrawer-keypair.json, stake-account-keypair.json, and identity.json across multiple deployment paths.\r\nEnvironment file harvesting and DevOps secrets\r\nIt also reads various environment files and DevOps secrets, target WireGuard VPN, Helm, Terraform, CI/CD\r\nconfigs, API keys/webhook URLs, and steals TLS/SSL keys.\r\nLocal persistence installation (Layer 2) and persistent backdoor C\u0026C loop (Layer 3)\r\nAfter collecting credentials and deploying the K8s lateral movement pods, the script installs local persistence on\r\nthe current machine. The persistence is installed under ~/.config/sysmon/ with the service named \"System\r\nTelemetry Service\", designed to blend in with legitimate Linux system monitoring tools.\r\nThe PERSIST_B64 payload, installed as sysmon.py, implements a polling-based remote code execution backdoor.\r\nIt sleeps 300 seconds (five minutes) on first start then polls hxxps[://]checkmarx[.]zone/raw every 3,000 seconds\r\n(~50 minutes) and expects a URL starting with \"http \" in the response. If the URL is different from the currently\r\nstored in /tmp/.pg_state and does NOT contain \"youtube.com\", it downloads the content to /tmp/pglog, sets it with\r\nexecutable permissions (chmod 755), executes it as a detached process (start_new_session=True), and finally\r\nrecords the URL in /tmp/.pg_state to prevent re-download.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 13 of 26\n\nThis constitutes a remote code execution (RCE) backdoor. The attacker can push arbitrary executables to\r\nall compromised machines by updating the content served at the C\u0026C URL. The systemd service configuration\r\nensures the backdoor survives crashes (Restart=always) and system reboots.\r\nThe ‘.pth’ mechanism: A known risk, accepted\r\nPython's .pth file processing is a documented feature, not a bug. Files ending in .pth placed in site-packages are\r\nprocessed automatically every time the Python interpreter starts. CPython core developers have discussed this\r\nrisk, Issues #113659 and #78125, but treated it as a \"won't fix\" because restricting .pth execution would break\r\nlegitimate use cases.\r\nIssue #113659 was addressed, and Python versions 3.8 through 3.13 now skip hidden\r\n.pth files, which reduces some risk. Although the broader proposal to deprecate or remove .pth code execution\r\nentirely (Issue #78125) remains unresolved, these partial mitigations demonstrate ongoing efforts within\r\nthe CPython community to balance security concerns with backwards compatibility.\r\nThis isn't the first exploitation: Volexity observed .pth abuse in CVE-2024-3400 exploitation.\r\nThe npm track (checkmarx-util-1.0.4) followed an identical pattern but targeted DevSecOps engineers through a\r\nfake Checkmarx utility package. It was served directly from attacker-controlled infrastructure\r\nat checkmarx.zone rather than the public npm registry, with a postinstall hook triggering automatic execution.\r\nInternal timestamps were set to October 26, 1985, the \"Back to the Future\" date, a deliberate anti-forensic Easter\r\negg from a Western-culture-aware operator.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 14 of 26\n\nFrom one IP to a multi-ecosystem campaign\r\nThe GitHub issue gave defenders a starting point. Our analysis began with a single seed IOC, IP address\r\n83.142.209.11, and expanded through five systematic enrichment pivots over 50 minutes, consuming\r\n34 VirusTotal API calls. What emerged was not a single-package compromise but a coordinated, multi-ecosystem\r\nsupply chain campaign we track as TeamPCP.\r\nThree supply chain tracks, one actor\r\nAll three tracks converged on the same encryption scheme (AES-256-CBC + RSA-4096-OAEP), the same\r\ncredential targets, the same persistence mechanism, and the same C\u0026C infrastructure, confirming a single unified\r\ntoolchain. The actor embedded their own branding throughout: \"TeamPCP\" strings in payload code, \"tpcp.tar.gz\"\r\nas the exfiltration archive name, and cultural artifacts like the code comment \"ICP y u no radio? ;w;\", an English-language internet-culture reference that would later factor into attribution analysis.\r\nThe credentials harvested from Trivy CI/CD runners became the keys to subsequent compromises, each expanding\r\nthe campaign's reach:\r\nnpm (March 20): Less than 24 hours after the Trivy compromise, TeamPCP deployed a self-propagating\r\nworm — dubbed CanisterWorm by Aikido researchers — across the npm ecosystem. The worm\r\nstole npm tokens from compromised runners, enumerated all packages the tokens had publish access to,\r\nand published malicious versions automatically. Twenty-eight packages in the @EmilGroup scope were\r\ninfected in under 60 seconds. The worm used an Internet Computer Protocol (ICP) canister as its\r\ncommand-and-control dead-drop — the first documented use of ICP for C\u0026C, according to Aikido. ICP\r\ncanisters cannot be taken down by traditional domain registrar or hosting provider action.\r\nCheckmarx KICS (March 23): Using compromised Checkmarx credentials, TeamPCP hijacked all 35 tags\r\n(v1 through v2.1.20) of the KICS GitHub Action, an infrastructure-as-code security scanner. Two malicious\r\nVS Code extensions were also published to the OpenVSX marketplace. The payload used a new\r\nC\u0026C domain (checkmarx[.]zone) but contained the same RSA-4096 public key and tpcp.tar.gz exfiltration\r\nnaming as the Trivy payload, confirming shared infrastructure.\r\nDocker Hub (March 22): Malicious Docker images (aquasec/trivy:0.69.5 and 0.69.6) were pushed directly\r\nto Docker Hub using compromised credentials, bypassing the GitHub release process entirely. These\r\nimages propagated to third-party mirrors including mirror.gcr.io.\r\nPyPI — LiteLLM (March 24): The cascade reached LiteLLM when its CI/CD pipeline ran\r\nthe compromised Trivy as part of its build process. The malicious Trivy code harvested\r\nthe PYPI_PUBLISH token from the GitHub Actions runner environment. The LiteLLM maintainer\r\nconfirmed this was the attack vector: the compromise \"originated from the trivvy [sic] used in our ci/cd\"\r\nInfrastructure: 90 days of preparation for a 48-hour attack\r\nThe infrastructure behind TeamPCP reveals disciplined operational planning that contrasts sharply with the\r\neventual campaign detection timeline:\r\nBoth C\u0026C nodes, 83.142.209.11 (checkmarx[.]zone) and 46.151.182.203 (LiteLLM[.]cloud), were hosted on\r\nAS205759, a bulletproof hosting provider operating under Ghosty Networks LLC / DEMENIN B.V. with a\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 15 of 26\n\nNetherlands/Ukraine jurisdictional gap exploited for abuse reporting friction. JARM TLS fingerprinting revealed\r\nidentical server configurations across both nodes, a fingerprint inconsistent with commodity nginx and consistent\r\nwith the AdaptixC2 framework, an open-source Go C\u0026C toolkit.\r\nAdaptixC2's developer, \"RalfHacker,\" has been linked to the Russian criminal underground. The framework has\r\nbeen used by an Akira ransomware affiliate, based on infrastructure overlap, though the strength of this attribution\r\nlink warrants caution.\r\nThe kill switch: A YouTube URL as a global “off” switch\r\nOne of the campaign's most operationally notable features was its deactivation mechanism. Both supply chain\r\ntracks installed a persistence daemon that polled the C\u0026C server every 50 minutes. Before executing any stage-2\r\npayload, the daemon checked whether the response contained the word \"youtube\", if so, execution was silently\r\nskipped.\r\nAt the time of our analysis, the /raw endpoint was serving a 43-byte YouTube URL. The kill switch was active.\r\nEvery compromised host with a running persistence daemon had been globally deactivated without requiring\r\nindividual C\u0026C commands. The choice of \"youtube\" as the trigger is pragmatic, a YouTube URL\r\nnaturally contains the string, making the deactivation response appear as benign content if intercepted by network\r\nmonitoring.\r\nWhether the actor triggered the kill switch because they detected the on-going analysis, completed a harvesting\r\ncycle, or wanted to reduce forensic exposure remains an open question. The mechanism demonstrates operational\r\nmaturity, the ability to globally shut down a campaign with a single server-side change, though this pattern has\r\nbeen observed in other criminal C\u0026C frameworks and is not unique to this campaign.\r\nThe bot suppression campaign: Information warfare meets vulnerability disclosure\r\nWithin minutes of the GitHub issue being filed, something unusual happened: a wave of comments flooded the\r\nthread.\r\nAccording to community analysis:\r\n121 compromised GitHub accounts activated within minutes of disclosure\r\nStepSecurity documented 196+ bot comments flooding the thread, the majority generic praise spam\r\nidentical to patterns observed in the Trivy compromise\r\n \r\nFlooding the GitHub issue with noise was likely done to delay triage and community response. This is a notable\r\noperational TTP; previous supply chain attacks relied on stealth and hoped for slow detection. TeamPCP actively\r\nfought disclosure.\r\nWhether this constitutes \"information warfare applied to vulnerability disclosure\" or automated spam from a\r\nbotnet operator selling services depends on the actor's organizational structure,\r\nwhich remains unconfirmed. What's clear is that the suppression capability was pre-positioned and activated\r\nrapidly.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 16 of 26\n\nWho is TeamPCP?\r\nFigure 21. TeamPCP onion website\r\nAttribution in supply chain campaigns is inherently difficult; shared tooling, shared infrastructure, and deliberate\r\nfalse flags are common. Operating under various aliases including TeamPCP, Shellforce, PersyPCP, and @pcpcats\r\non X, this threat actor group maintains a broad and coordinated online presence. They utilize multiple Telegram\r\nchannels and an onion website to publicize their exploits and advertise their victims. Through these platforms,\r\nthey provide details about compromised entities and offer contact information for negotiation purposes, directing\r\ninterested parties to reach out via Telegram to make an offer.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 17 of 26\n\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 18 of 26\n\nFigure 22. TeamPCP using aliases and advertising their victims\r\nWe applied a formal Analysis of Competing Hypotheses (ACH) framework against three attribution\r\ncandidates: The @pcpcats account from October 2023 claims they are based in Israel, although indicates they are\r\nconnected via a South Africa Android app. The strong attribution signal is cultural.\r\nThe \"ICP y u no radio? ;w;\" code comment, the \"Back to the Future\" timestamp manipulation, the explicit\r\n\"TeamPCP\" branding in operational payloads, and the English-only targeting profile collectively point toward\r\nan operator or small team that’s knowledgeable in Western culture and internet culture, not a nation-state proxy.\r\nThe tooling development arc (version 1 in December 2025, hardened version 2 in February; deployment in March)\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 19 of 26\n\nreflects a small, motivated developer team with a security research background, not a large-scale criminal\r\noperation.\r\nAttribution is complicated by the Iran-targeted wiper component (kamikaze[.]sh). This could indicate a Russian\r\ncriminal actor with anti-Iran motivation, a deliberate false flag, or a multi-party operation. We assess with\r\nmoderate confidence that TeamPCP is a small criminal team fluent in Western culture. \r\nThe victim landscape reinforces this assessment. TeamPCP's .onion site and Telegram channels\r\ndocument affected systems across the United States, China, Brazil, Philippines, India, Turkey, Chile, South Korea,\r\nVietnam, and Uzbekistan. V from the United States span telecommunications infrastructure, automotive rental,\r\nemployment platforms, and business analytics. Chinese victims operate in SaaS, financial trading, and e-commerce dropshipping. Brazil, Philippines, and Turkey entities run fintech and payment processing operations.\r\nIndia, South Korea, and Vietnam victims operate employment and e-commerce platforms. Chile and Uzbekistan\r\nrepresent sectoral outliers with digital payment/loyalty solutions and fantasy sports infrastructure. \r\nThe concentration in credential-rich commercial sector, employment platforms with PII databases, fintech with\r\npayment processor integrations, POD providers with merchant account access aligns with a criminal monetization\r\nmodel focused on credential resale and access brokering.\r\nThe victimology is opportunistic, not strategic. The actor compromised what was vulnerable, not what was\r\nvaluable to a state intelligence apparatus. This pattern, combined with the cultural indicators and tooling timeline,\r\nsupports the moderate-confidence assessment of a small criminal team that’s fluent in Western culture\r\nand operating for financial gain. The full ACH framework with competing hypotheses is available in our technical\r\nreport.\r\nFigure 23. Their victimology points to TeamPCP as a threat group or operator who knows about\r\nWestern culture\r\nWhat public reporting missed\r\nThe LiteLLM compromise attracted rapid community response. Reports from Wiz, Socket.dev, Snyk, and\r\nindependent researchers quickly documented the .pth mechanism, basic IOCs, and package-level remediation.\r\nHowever, our systematic comparison of public reporting against our analysis findings revealed significant gaps:\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 20 of 26\n\nThe second infrastructure node: No public report identified 46.151.182.203 or\r\nthe LiteLLM[.]cloud/models[.]LiteLLM[.]cloud exfiltration infrastructure. Organizations relying solely on\r\ncommunity IOC feeds had a blind spot for the PyPI exfiltration endpoint.\r\nThe npm campaign arm: The existence of checkmarx-util-1.0.4.tgz, its three-layer nesting structure, and its\r\ndelivery via direct URL from checkmarx[.]zone were not reported externally.\r\nThe AdaptixC2 deployment: No public source linked the seed IP to an active AdaptixC2 team server.\r\nThe C\u0026C framework identification has direct hunting implications, AdaptixC2's distinctive JARM\r\nfingerprint enables passive network detection of deployed team servers.\r\nThe 3.5-month development timeline: The pcpcat.py v1 artifact (first seen December 2025) documents the\r\nactor's tooling development beginning months before the campaign launched, a timeline absent from public\r\nreporting focused on the March 2026 compromise window.\r\nJARM-based infrastructure linkage: The cross-node JARM correlation proving single-operator control\r\nacross two separate /24 networks was not documented publicly.\r\nThe formal attribution framework: Public attribution ranged from confident DPRK attribution to\r\nuncertainty. No public source applied a structured competing-hypothesis methodology to weigh the\r\ncultural, operational, and technical evidence.\r\nIn total, approximately 30% of our analysis findings had zero prior to public coverage. The community response\r\nwas fast and valuable for immediate remediation, but operational understanding of the full campaign scope\r\nrequired deeper infrastructure analysis, cross-ecosystem correlation, and formal analytical rigor that rapid-response reporting didn't provide.\r\nConclusion\r\nThe LiteLLM compromise is a case study on why AI infrastructure can become the next preferred supply chain\r\ntarget. Everyone wants to talk about advanced AI vulnerabilities like prompt injection, data poisoning, and model\r\ninversion, but attackers are exploiting the exact same infrastructure weaknesses we have battled for a decade.\r\nThe AI technology stack is built on standard, fragile, open-source foundations. Threat actors always target the\r\ncentral, weakest link. Why bother engineering a complex LLM jailbreak when a poisoned Python dependency\r\nhands over your Kubernetes cluster on a silver platter? We keep treating AI as a completely novel frontier, but the\r\nadversaries are simply using the same old supply chain crowbars to break in.\r\nThis incident exposes the risks of unmanaged updates from public sources, and the vulnerability that can be\r\ncreated with the lack of caution and supervision in hasty patching. A CI/CD pipeline that automatically pulls the\r\nnewest release without a quarantine period creates a vulnerability for itself. Pin your\r\ndependencies to cryptographic hashes and let someone else's infrastructure test the newest release for supply chain\r\nmalware first.\r\nThe concentration problem\r\nLiteLLM occupies a privileged position in the AI/ML stack; it handles API keys for every model provider it\r\nproxies. In the proxy deployment model (where LiteLLM runs as a centralized gateway), compromising it yields\r\nnot just standard cloud credentials, but LLM API keys for OpenAI, Anthropic, Azure AI, and others\r\nsimultaneously. This is a concentration-of-risk pattern: one package, all keys.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 21 of 26\n\nNote that the risk profile differs for SDK/library usage, where LiteLLM is called with per-request credentials\r\nand doesn't centralize key storage. The proxy deployment model, which is LiteLLM's primary use case in\r\nproduction, carries the higher blast radius.\r\nStolen LLM API keys give attackers:\r\nFree compute for their own operations (API keys for major providers can represent thousands of dollars per\r\nmonth in compute costs)\r\nAccess to conversation histories on some providers\r\nAbility to inject responses in customer-facing AI products\r\nFinancial drain on victim organizations\r\nWhy AI infrastructure Is uniquely exposed\r\nTransitive dependency depth. AI/ML projects have exceptionally\r\ndeep dependency trees. DSPy, MLflow, CrewAI, OpenHands, and dozens of frameworks pull LiteLLM as a\r\ntransitive dependency. Wiz reported that LiteLLM was present in 36% of the cloud environments they\r\nanalyzed, indicating wide adoption, though presence alone doesn't equate to vulnerability.\r\nRapid ecosystem growth outpaces security maturity. Many AI/ML packages are maintained by small teams or\r\nsolo developers. The pressure to ship AI features drives fast adoption of poorly-audited packages. OWASP's LLM\r\nTop 10 includes LLM03 (Supply Chain Vulnerabilities) as a top risk.\r\nSecurity tooling as attack surface. The Trivy-to-LiteLLM chain demonstrated that the tools defenders use\r\nto secure AI infrastructure can become the entry point. This is the same lesson as SolarWinds, applied to the open-source ecosystem.\r\nWhat was demonstrated vs. what was theoretically possible\r\nIt's important to distinguish between capabilities the payload had and the impacts that were confirmed:\r\nCategory Status Detail\r\nCredential harvesting code Demonstrated\r\nPayload code confirmed to sweep\r\nfor over 15 credential types\r\nExfiltration to C\u0026C Demonstrated\r\nHTTPS POST\r\nto ‘models.LiteLLM.cloud’ confirmed\r\nK8s DaemonSet lateral\r\nmovement\r\nCapability present in\r\ncode\r\nNot confirmed exploited in the wild\r\nSuccessful use of stolen\r\ncredentials\r\nUnconfirmed\r\nNo public report of confirmed\r\ndownstream compromise\r\nModel poisoning via supply\r\nchain\r\nTheoretical\r\nNot present in this payload; a general AI supply\r\nchain risk\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 22 of 26\n\nStage-2 payload delivery Capability present\r\nKill switch was active; no confirmed stage-2\r\nexecution\r\nTable 2. Behaviors and code capabilities associated with the LiteLLM payload\r\nThis distinction matters. The payload was sophisticated, and the risk was severe, but responsible reporting requires\r\nseparating demonstrated exploitation from theoretical worst-case scenarios.\r\nThis pattern will repeat\r\nTeamPCP's successful compromise of LiteLLM for AI developers, Checkmarx/KICS for AppSec\r\nengineers, and Trivy for container security teams is proof of the kind of impact created\r\nby compromising those with the most access to production infrastructure. The bigger picture will show that\r\ncompromising AI infrastructure could well be considered collateral damage, albeit equally alarming, to enable\r\nmore catastrophic damage. \r\nAs AI/ML tooling proliferates across enterprise CI/CD pipelines, the attack surface expands with it. The tools that\r\ndevelopers install to interact with AI systems, proxy gateways, model routers, experiment trackers, and inference\r\nservers handle high-value secrets by design. Supply chain attacks against these tools inherit the trust and access of\r\nthe AI infrastructure itself.\r\nThe malicious payload analyzed in this report is a direct exploitation of the systemic secret management failures\r\nextensively documented in a prior TrendAI™ Research publicationnews article. As previously described,\r\ndevelopers have adopted .env files so profusely that they have forgotten their sensitivity, leaving them exposed,\r\nand threat actors are actively scanning for exactly these files. The harvester analyzed here operationalizes that\r\nattack surface at scale: it performs exhaustive filesystem walks targeting .env, .env.local, .env.production, and\r\n.env.staging files across up to six directory levels, while simultaneously extracting AWS credentials, cloud\r\nprovider tokens, Kubernetes service account secrets, CI/CD pipeline configurations, and database connection\r\nstrings; the same categories of secrets TrendAI™ Research previously identified as most commonly stored in\r\nplaintext inside .env files.\r\nSecurity recommendations\r\nThis case highlights the risk of building an entire ecosystem on top of fragile trust. The LiteLLM hack is just the\r\nlatest example of attackers exploiting the reliance on open-source registries and poor secret hygiene. Security is\r\nnot an afterthought you can outsource entirely to a vulnerability scanner. If you have LiteLLM anywhere in your\r\nstack, do not wait for a vendor to issue a critical alert – the attackers already have what they want – and try to get\r\nahead of the adversaries by applying the following immediate directives based on the known indicators\r\nof compromise (IoCs):\r\nImmediate actions\r\nCheck for `LiteLLM_init.pth` in any Python site-packages directory. If present, assume full\r\ncredential compromise.\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 23 of 26\n\nRotate ALL credentials that were present as environment variables or in config files on any system\r\nwhere LiteLLM 1.82.7 or 1.82.8 was installed, including CI/CD runners. This includes LLM API keys,\r\nwhich should be treated as compromised.\r\nBlock the following at DNS and firewall: checkmarx[.]zone, LiteLLM[.]cloud, models.LiteLLM.cloud,\r\n83.142.209.11, 46.151.182.203.\r\nAudit npm packages for any reference to checkmarx-util or postinstall hooks that read\r\nGITHUB_ACTIONS.\r\nSearch for the `sysmon.service` systemd user unit and ~/.config/sysmon/ directory on Linux systems. \r\nPin Trivy and all security scanners in your CI/CD pipeline. If your security tools are compromised,\r\neverything downstream is exposed.\r\n \r\nStructural defenses\r\nEnforce ‘npm install --ignore-scripts’ in CI/CD pipelines unless postinstall scripts are explicitly reviewed.\r\nMonitor for unexpected ‘.pth’ file creation in Python site-packages, any .pth write outside a known-good baseline should trigger a critical alert. Elastic has published a detection rule for this.\r\nPin package versions and verify SHA256 hashes. Use pip install --require-hashes or uv pip install --\r\nrequire-hashes. Generate and enforce software bills of materials (SBOMs) for all production deployments.\r\nPin to a stable and tried-and-tested version. Do this instead of going to the latest version that might not\r\nhave been tested yet to avoid compromise similar to this case. \r\nDeploy behavioral detection for bulk credential file reads (SSH keys + cloud configs + crypto wallets in a\r\nsingle process) rather than relying on signature-based AV.\r\nImplement JARM fingerprint monitoring for TLS connections to bulletproof hosting ASNs.\r\nAudit transitive dependencies. You may not use LiteLLM directly but pull it through DSPy, CrewAI, or\r\nother frameworks. Use pipdeptree or uv pip tree to check.\r\nImplement egress filtering. The payload exfiltrated to models.LiteLLM.cloud; domain allowlisting for AI\r\ninfrastructure would have caught this.\r\nTreat LLM API keys as crown jewels. Rotate immediately if any package in your dependency\r\ntree was compromised. Use provider-specific short-lived tokens where available.\r\nWatch for fork bomb / resource exhaustion as a potential indicator of supply chain compromise, this is how\r\nthe LiteLLM attack was first noticed.\r\nMITRE ATT\u0026CK mapping\r\nTactic Technique Observed Behavior\r\nExecution T1059.006 — Python\r\nMulti-layer base64 Python payloads executed in-memory\r\nPersistence T1543.002 — Systemd Service\r\nsysmon.service installed as user-level systemd service\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 24 of 26\n\nPrivilege\r\nEscalation\r\nT1611 — Escape to Host\r\nPrivileged K8s pods with host filesystem access\r\nvia chroot\r\nDefense Evasion T1027 — Obfuscated Files\r\n3-layer base64 encoding, service disguised as\r\ntelemetry\r\nCredential\r\nAccess\r\nT1552.001 — Credentials In Files SSH keys, cloud creds, .env files, wallet keys\r\nCredential\r\nAccess\r\nT1552.005 — Cloud Instance\r\nMetadata\r\nAWS IMDS v1/v2 queried for IAM role\r\ncredentials\r\nDiscovery\r\nT1082 — System Information\r\nDiscovery\r\nhostname, uname -a, whoami, ip addr\r\nLateral\r\nMovement\r\nT1610 — Deploy Container\r\nPrivileged pods deployed to every K8s cluster\r\nnode\r\nCollection T1005 — Data from Local System\r\nExtensive file harvesting across user homes and\r\nsystem dirs\r\nExfiltration\r\nT1041 — Exfiltration Over\r\nC\u0026C Channel\r\nHTTPS POST to models[.]LiteLLM[.]cloud\r\nExfiltration\r\nT1573.001 — Encrypted Channel:\r\nSymmetric\r\nAES-256-CBC + RSA-4096 hybrid encryption\r\nCommand \u0026\r\nControl\r\nT1071.001 — Application Layer:\r\nWeb\r\nHTTPS polling to checkmarx[.]zone for second-stage\r\nTable 3. MITRE ATT\u0026CK mapping\r\nProactive security with TrendAI Vision One™ \r\nTrendAI Vision One™one-platformone-platform is the industry-leading AI cybersecurity platform that centralizes\r\ncyber risk exposure management, security operations, and robust layered protection.\r\nTrendAI Vision One™ Threat Intelligence Hub\r\nTrendAI Vision One™ Threat Intelligence Hubproductsproducts provides the latest insights on emerging threats\r\nand threat actors, exclusive strategic reports from TrendAI™ Research, and TrendAI Vision One™ Threat\r\nIntelligence Feed in the TrendAI Vision One™ platform.\r\nFocused on the LiteLLM GitHub Actions:\r\nEmerging Threats: Critical Supply Chain Attack: Malicious LiteLLM_init.pth in LiteLLM PyPI Package\r\n(v1.82.8) – Credential Stealer\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 25 of 26\n\nTrendAI Vision One™ Intelligence Reports (IOC Sweeping): Critical Supply Chain Attack: Malicious\r\nLiteLLM_init.pth in LiteLLM PyPI Package (v1.82.8) – Credential Stealer\r\nCovers a more collective TeamPCP compromised GitHub Actions:\r\nEmerging threats: Global CI/CD Supply Chain Attack: TeamPCP Compromises GitHub Actions and Open\r\nSource Security Tools for Credential Theft\r\nTrendAI Vision One™ Intelligence Reports (IOC Sweeping)\r\nIf a zero-day slips through your pipeline, static scanners are useless and you need a behavioral safety net at\r\nruntime. Mapping cloud exposure and risk score surfaces these issues and allows you to respond before a potential\r\nleak is exploited.\r\nTrendAI Vision One™ Code Securityproducts and TrendAI Vision One™ Container Security catches malicious\r\npayloads before it detonates by scanning your container images during the build phase and flagging the\r\ncompromised library. If a seemingly harmless Python script inside your container suddenly dumps Azure\r\ncredentials, reads Kubernetes service account tokens, and attempts to install a background daemon, our XDR\r\nagent flags the behavioral anomaly and kills the process before the attacker exfiltrates your data.\r\nIndicators of Compromise (IoCs)\r\nThe highest-priority IOCs from this campaign can be found in this link. A complete IOC table with 19 indicators\r\nis available in the full technical report.\r\nThis analysis was conducted by the ZDI Threat Hunting team as part of ongoing supply chain threat research.\r\nFor the full technical report including complete IOC tables, infrastructure diagrams, MITRE ATT\u0026CK\r\nmappings, and Snort/Suricata rules, contact the team directly.\r\nTags\r\nSource: https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nhttps://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html\r\nPage 26 of 26\n\n\"TeamPCP\" branding an operator or small in operational payloads, team that’s knowledgeable and the in Western English-only targeting culture and profile collectively internet culture, point not a nation-state toward proxy.\nThe tooling development arc (version 1 in December 2025, hardened version 2 in February; deployment in March)\n  Page 19 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html"
	],
	"report_names": [
		"inside-litellm-supply-chain-compromise.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775791264,
	"ts_updated_at": 1775791339,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3b253990b77e51467b0f57de4f4e14f738604d1b.pdf",
		"text": "https://archive.orkl.eu/3b253990b77e51467b0f57de4f4e14f738604d1b.txt",
		"img": "https://archive.orkl.eu/3b253990b77e51467b0f57de4f4e14f738604d1b.jpg"
	}
}