The TeamPCP hacking group continues its supply-chain rampage, now compromising the massively popular "LiteLLM" Python package on PyPI and claiming to have stolen data from hundreds of thousands of devices during the attack.

LiteLLM is an open-source Python library that serves as a gateway to multiple large language model (LLM) providers via a single API. The package is very popular, with over 3.4 million downloads a day and over 95 million in the past month.

According to research by Endor Labs, threat actors compromised the project and published malicious versions of LiteLLM 1.82.7 and 1.82.8 to PyPI today that deploy an infostealer that harvests a wide range of sensitive data.

The attack has been claimed by TeamPCP, a hacking group that was behind the recent high-profile breach of Aqua Security's Trivy vulnerability scanner. That breach is believed to have led to cascading compromises that impacted Aqua Security Docker images, Checkmarx KICS project, and now LiteLLM.

The group has also been found targeting Kubernetes clusters with a malicious script that wipes all machines when it detects systems configured for Iran. Otherwise, it installs a new CanisterWorm backdoor on devices in other regions.

Sources have told BleepingComputer the number of data exfils is approximately 500,000, with many being duplicates. VX-Underground reports a similar number of 'infected devices."

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

LiteLLM supply chain attack

Endor Labs reports that threat actors pushed out two malicious versions of LiteLLM today, each containing a hidden payload that executes when the package is imported.

The malicious code was injected into 'litellm/proxy/proxy_server.py' [VirusTotal] as a base64 encoded payload, which is decoded and executed whenever the module is imported. 

Version 1.82.8 introduces a more aggressive feature that installs a '.pth' file named 'litellm_init.pth' [VirusTotal] to the Python environment. Because Python automatically processes all '.pth' files when the interpreter starts, the malicious code would be executed whenever Python is run, even if LiteLLM is not specifically used.

Once executed, the payload ultimately deploys a variant of the hacker's "TeamPCP Cloud Stealer" and a persistence script. Analysis by BleepingComputer shows the payload contains virtually the same credential-stealing logic used in the Trivy supply chain attack.

"Once triggered, the payload runs a three-stage attack: it harvests credentials (SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and .env files), attempts lateral movement across Kubernetes clusters by deploying privileged pods to every node, and installs a persistent systemd backdoor that polls for additional binaries," explains Endor Labs.

"Exfiltrated data is encrypted and sent to an attacker-controlled domain."

The stealer harvests a wide range of credentials and authentication secrets, including:

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

The cloud stealer payload also includes an additional base64 encoded script that is installed as a systemd user service disguised as a "System Telemetry Service," which periodically contacts a remote server at checkmarx[.]zone to download and execute additional payloads.

Stolen data is bundled into an encrypted archive named tpcp.tar.gz and sent to attacker-controlled infrastructure at models.litellm[.]cloud, where the threat actors can access it.

Rotate exposed credentials!

Both malicious LiteLLM versions have been removed from PyPI, with version 1.82.6 now the latest clean release. 

Organizations that use LiteLLM are strongly advised to immediately:

• Check for installations of versions 1.82.7 or 1.82.8
• Immediately rotate all secrets, tokens, and credentials used on or found within code on impacted devices.
• Search for persistence artifacts such as '~/.config/sysmon/sysmon.py' and related systemd services
• Inspect systems for suspicious files like '/tmp/pglog' and '/tmp/.pg_state'
• Review Kubernetes clusters for unauthorized pods in the 'kube-system' namespace
• Monitor outbound traffic to known attacker domains

If compromise is suspected, all credentials on affected systems should be treated as exposed and rotated immediately.

BleepingComputer has repeatedly covered breaches that stemmed from companies not rotating credentials, secrets, and authentication tokens found in previous breaches.

Both researchers and threat actors have told BleepingComputer that while rotating secrets is difficult, it is one of the best ways to prevent cascading supply chain attacks.