Alert: Telnyx Python SDK committed to PyPI by TeamPCP steals secrets and points to Kubernetes

Today an attack on the Python supply chain was detected that affected the official Telnyx package in the PyPI repository: malicious versions were published and distributed as if they were legitimate updates of the SDK. Modern application security researchers gave the alarm voice and attributed the intrusion to the group known as TeamPCP, based on exfiltration patterns and RSA keys already observed in previous campaigns. You can read the technical reports that describe the incident in Aikido, Socket and Endor Labs.

The affected package is the official Telnyx SDK for Python, the library that many developers use to integrate communications services - such as voice, SMS, WhatsApp and IoT connectivity - into their applications. It is a very used unit: in PyPI more than hundreds of thousands of monthly downloads, so the potential impact is high. The researchers' suspicion is that the attackers got access to the account with publication permits in PyPI, and from there two compromised versions came up.

The first malicious version published failed to activate its payload, but the second, up shortly thereafter, ran hostile code at the time the package was imported into an application. The malicious code was hidden inside the file telnyx / _ client.py for the library to appear to function normally, allowing the vector to pass unnoticed while the SDK continued to comply with its public API.

The threat behavior varies according to the system: in Linux and macOS the installer / loader starts a separate process that downloads a second stage from a remote server. This second stage is delivered as a WAV audio file, with names like ringtone.wav; however, within the audio frames malicious code has been embedded by means of steganography techniques. The attacker draws these data, disfigures them with a simple XOR-based routine and runs them directly in memory. The goal is to collect secrets: SSH keys, credentials in configuration files, cloud tokens, cryptomoneda coins, environment variables and other secrets that can be found in the host.

In hosts with Kubernetes, the threat is not limited to stealing local secrets: malware tries to list cluster secrets and create pods with high privileges on different nodes, with the intention to escape to the host system and expand the scope of the intrusion. On Windows the strategy changes slightly: the payload downloads another WAV (for example hangup.wav) that uncovers an executable called msbuild.ex. This binary is installed in the user's start folder to get persistence at each login, and a lock file prevents repeated execution in 12-hour windows.

The technical analyses published by the teams that investigated the incident detail both the placement of the malicious code and the concealment and exfiltration tactics. These descriptions are useful for detection and mediation; you can consult them directly in the reports of Endor Labs, Aikido and Socket.

If your environment installed the compromised versions, experts warn that it should be assumed that these machines are already compromised: the code is run in import time and may have exfiltered secrets immediately. The immediate technical recommendation is to return to the previous clean version of the package, which in this case corresponds to the release 4.87.0 available in PyPI ( package page in PyPI), and remove any trace of versions 4.87.1 and 4.87.2 where they are installed.

While the committed unit is removed, it is appropriate to take containment and response measures: rotate potentially exposed keys and tokens, regenerate credentials in cloud services and purse, audit users and pods in Kubernetes clusters and review the persistence entries in Windows machines (e.g. search for msbuild.exe in the Startup). It is also a priority to audit package publishing systems: change passwords, enable multifactor authentication in the involved PyPI account and review publication logs to detect unauthorized access.

Beyond the response to a particular incident, this case again highlights a point that development and security teams should always bear in mind: external dependencies are a critical attack route. Good practices that reduce the risk area should be applied, such as setting (pin) specific versions in production environments, using private repositories or controlled caches for units, validating integrity where possible and requiring security controls on accounts with publication permits. Organizations and initiatives such as OpenSSF and SLSA publish guides and working frameworks to improve the resilience of the software supply chain; consult OpenSSF and SLSA can help prioritize measures.

For managers and developers in need of concrete steps: confirm if any of their images, containers or virtual environments included versions 4.87.1 or 4.87.2; replace these facilities by 4.87.0; consider rebuilding artifacts and containers from clean sources; round any credential that may have been exposed; and deploy detections for out-of-room traffic anomalous to unknown infrastructure. In addition, review the publication accounts in PyPI and enable 2FA on all critical accounts (see the security options in PyPI for developers in PyPI: two-step authentication).

This incident is not the first and will not be the last in the field of open source package intrusions: the actor pointed out by the researchers already accumulates multiple operations against popular projects, from risk analysis utilities to general-use bookstores. The lesson for product equipment and platforms is clear: confidence in external components must be accompanied by technical and organizational controls that detect, limit and respond quickly when that confidence is broken.

If you want to go into the technical details or follow the analysts' recommendations, see the original reports of the teams that investigated the campaign: Aikido, Socket and Endor Labs and act as soon as possible if your organization could be affected.