The hacking group TeamPCP is continuing its supply chain attacks, now targeting the widely used “LiteLLM” Python package on PyPI and claiming to have obtained data from hundreds of thousands of devices as a result.

LiteLLM is an open-source Python library that acts as a unified interface for interacting with various large language model (LLM) providers. It’s a popular package, boasting over 3.4 million daily downloads and more than 95 million downloads in the last month.

Research from Endor Labs indicates that malicious actors compromised the project and released harmful versions of LiteLLM 1.82.7 and 1.82.8 on PyPI today. These versions include an infostealer designed to collect a wide array of sensitive data.

TeamPCP, the same group responsible for the recent, significant compromise of Aqua Security’s Trivy vulnerability scanner, has claimed responsibility for the attack. That earlier breach reportedly sparked follow-on compromises that affected Aqua Security Docker images, Checkmarx KICS project, and now LiteLLM.

The group has also been observed targeting Kubernetes environments utilizing a destructive script that erases all data on systems identified as being configured for Iran. Otherwise, a new CanisterWorm backdoor is installed on devices in other regions.

Sources have informed BleepingComputer that the approximate quantity of data breaches is 500,000, although many are duplicates. VX-Underground is reporting a similar quantity of infected devices.

However, BleepingComputer has not been able to confirm these numbers independently.

Endor Labs’ research reveals that the attackers distributed two tainted versions of LiteLLM today, each embedding a hidden component that activates upon package import.

The malicious code was inserted into ‘litellm/proxy/proxy_server.py’ [VirusTotal] as a base64-encoded payload, which is decoded and executed when the module is imported.

Version 1.82.8 includes an even more intrusive element: a ‘.pth’ file named ‘litellm_init.pth’ [VirusTotal] is added to the Python environment. Python inherently processes all ‘.pth’ files at startup, meaning the malicious code runs whenever Python is executed, regardless of whether LiteLLM is explicitly used.

Upon execution, the payload deploys a version of the attacker’s “TeamPCP Cloud Stealer” and a persistence-ensuring script. BleepingComputer’s analysis indicates that the payload contains nearly identical credential-stealing functionality as the Trivy supply chain attack.

“Once triggered, the attack unfolds in three stages: it gathers credentials (SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and .env files), attempts to spread laterally across Kubernetes clusters by deploying privileged pods to every node, and installs a persistent systemd backdoor that waits for instructions to download and run additional malicious software,” Endor Labs explained.

“The stolen data is encrypted and sent to a server controlled by the attackers.”

The stealer collects a broad range of credentials and authentication information, including

• System information gathered via hostname, pwd, whoami, uname -a, ip addr, and printenv commands
• SSH keys and configuration files
• Cloud access credentials for AWS, GCP, and Azure
• Kubernetes service account tokens and cluster secrets
• Environment files such as `.env` variations
• Database credentials and configuration files
• TLS private keys and CI/CD secrets
• Cryptocurrency wallet data

An additional base64-encoded script is part of the cloud stealer’s payload. That script is disguised as a “System Telemetry Service” installed as a systemd user service, which periodically connects to a remote server at checkmarx[.]zone to fetch and execute further malicious code.

The extracted data is compressed into an encrypted archive named tpcp.tar.gz and transmitted to attacker-controlled infrastructure located at models.litellm[.]cloud, enabling threat actors to access it.

Both compromised versions of LiteLLM have been taken down from PyPI. Version 1.82.6 is now the most recent secure release.

Organizations relying on LiteLLM are strongly urged to immediately:

• Check for installations of versions 1.82.7 or 1.82.8
• Immediately replace all secrets, tokens, and credentials used on or located within code on affected systems.
• Look for persistence mechanisms such as ‘~/.config/sysmon/sysmon.py’ and connected systemd services
• Check systems for suspicious files, for example, ‘/tmp/pglog’ and ‘/tmp/.pg_state’
• Examine Kubernetes clusters for unauthorized pods within the ‘kube-system’ namespace
• Monitor outgoing network traffic headed towards known attacker domains

If a compromise is suspected, treat all credentials on impacted systems as if they have been exposed and replace them at once.

BleepingComputer has previously reported on numerous security incidents arising from organizations failing to replace credentials, secrets, and authentication tokens compromised in earlier attacks.

Researchers and threat actors alike have emphasized to BleepingComputer that while rotating secrets presents challenges, it stands as one of the most effective steps in preventing cascading supply chain compromises.