TeamPCP Backdoored the Telnyx Python SDK — And Left a Self-Erasing RAT Behind

title: "TeamPCP Backdoored the Telnyx Python SDK — And Left a Self-Erasing RAT Behind"

slug: teampcp-telnyx-python-sdk-backdoor-2026

tags: [supply-chain, python, pypi, malware, teamtnt, credential-theft]

On March 27, 2026, a threat actor known as TeamPCP uploaded two malicious versions of the Telnyx Python SDK to PyPI. The compromised packages — `telnyx==4.87.1` and `telnyx==4.87.2` — were live for roughly four hours before PyPI quarantined them.

Four hours is long enough.

The Telnyx SDK pulls approximately 750,000 downloads per month. Any developer, CI/CD pipeline, or automated build system that ran `pip install telnyx` during that window could be sitting on a full credential compromise right now.

What Got Hit

The attack was surgical. Exactly one file inside the package was modified — everything else was byte-for-byte identical to the legitimate version. The malicious code fired the moment any application imported the library. No user interaction. No configuration. No visible error.

The payload followed a three-stage structure:

1. A platform-specific loader triggered on import
2. That loader fetched a hidden payload from a remote C2 server — concealed inside a WAV audio file using steganography
3. The decoded payload deployed a credential harvester that collected SSH keys, AWS/GCP/Azure credentials, Kubernetes secrets, Docker configs, database passwords, API keys, and `.env` files, then encrypted everything with AES-256-CBC and exfiltrated it to the attacker's server

The encryption used a hardcoded RSA-4096 public key — meaning only the attacker can decrypt what was stolen.

Look for this network indicator: any HTTP POST with the header `X-Filename: tpcp.tar.gz` headed toward `83.142.209.209:8080`. That signature appears across every known TeamPCP campaign. Block `83.142.209.0/24` at the firewall now.

Steganography in the Kill Chain

The steganography angle is worth stopping on. The Windows infection path downloaded a file called `hangup.wav` from the C2. It was a valid WAV container — pass it to any media player and it plays. But inside the audio frames, an executable was hidden and extracted with an XOR key, then written to the Windows Startup folder as `msbuild.exe`, borrowing the name of a legitimate Microsoft build tool.

On Linux and macOS, the approach was fileless. The harvester ran entirely in memory as a detached child process — never touching disk. The parent process closed, the infection stayed.

Every possible error was caught and silently discarded. The application using the Telnyx library would never crash or throw an alert.

Bigger Pattern: This Is a Campaign

Hexastrike analysts tracking TeamPCP — linked to the older TeamTNT threat actor — identified the Telnyx compromise as part of a fast-moving supply chain campaign. In nine days, the same group hit:

• Trivy (Aqua Security's container vulnerability scanner)
• Checkmarx packages
• LiteLLM (AI orchestration library popular in enterprise deployments)
• Over 46 npm packages

Each successive attack showed more sophistication than the last. The Telnyx compromise is the most complete version Hexastrike has analyzed. LiteLLM is particularly notable — it's concentrated in environments where developer AI tools are running, meaning the credential surface includes API keys for OpenAI, Anthropic, and similar services alongside traditional cloud creds.

Spread Across Kubernetes

This wasn't limited to individual developer machines. The malware included capability to spread through entire Kubernetes clusters by deploying privileged pods on every node. If a compromised package was installed inside a container running in a cluster, the blast radius could extend to every node in that environment.

If You Installed 4.87.1 or 4.87.2: Start Incident Response

Simply removing the package is not enough. The persistent backdoor survives uninstallation.

Linux: Remove `~/.config/sysmon/sysmon.py` and its associated systemd service (`sysmon.service`). Check for unexpected pods named `node-setup-*` in the `kube-system` namespace.

Windows: Delete `msbuild.exe` from the Startup folder and locate and remove any hidden `.lock` file in the same directory.

Kubernetes: Audit all nodes for `sysmon.service` and remove any `node-setup-*` pods.

All systems: Rotate everything. SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, Docker credentials, database passwords, API keys, any secret in a `.env` file on disk. Assume all of it was exfiltrated.

Network: Block outbound connections to `83.142.209.203`, `checkmarx.zone`, and `83.142.209.0/24` at the firewall.

Systemic Fixes

Beyond this incident, the attack exposes a structural issue in how most teams handle Python dependencies:

• Pin exact versions in all requirements files. Floating ranges like `telnyx>=4.0` are how malicious patch versions land in production without anyone noticing.
• Use lockfiles. `pip-compile` with `--generate-hashes` makes any tampered package fail cryptographically.
• Enable 2FA on PyPI accounts — including maintainer accounts for packages your codebase depends on.
• Restrict outbound connections from build infrastructure. CI/CD runners reaching arbitrary IPs on port 8080 should be blocked by default.
• Avoid long-lived credentials in `.env` files on disk. Use short-lived credential providers or secrets managers. Credentials at rest on a developer machine or CI runner are exactly what supply chain attacks harvest.

TeamPCP has been iterating quickly. The sophistication gap between each successive attack in this campaign is notable. The Telnyx compromise represents the current ceiling — expect the next one to clear it.

*CybrPulse tracks supply chain threat activity across PyPI, npm, and other package registries. IOCs from this campaign have been added to our feed.*