TeamPCP Compromises Telnyx: WAV Steganography, Windows Persistence, and the Credential Chain Continues

Day 7 Campaign Update · March 27, 2026 | Phoenix Security Vulnerability Intelligence

Executive Summary

On March 27, 2026 — seven days into the most consequential software supply chain campaign on record — TeamPCP struck again. The threat actor, also tracked as DeadCatx3, PCPcat, and ShellForce, published two backdoored versions of telnyx to PyPI without corresponding GitHub releases or tags. Telnyx is a telecommunications API SDK with approximately 742,000–790,000 monthly downloads; its SDK handles telephony credentials, session tokens, and API keys by design, making it a high-value target with maximum credential density per compromised host.

The telnyx payload shares the byte-for-byte identical RSA-4096 public key as the litellm compromise three days earlier, providing unambiguous attribution to TeamPCP. But the attacker has not stood still. Every major delivery and evasion mechanism has been redesigned: the 34,000-character inline payload from litellm is replaced by a 4,428-character thin dropper; the real 332-line credential harvester is now hidden inside a WAV audio file, fetched at runtime from a bare IP-address C2 server, invisible to static analysis. Windows targeting — absent from every prior TeamPCP campaign wave — appears for the first time, with a native binary extracted from a second WAV file and installed in the Startup folder masquerading as msbuild.exe.

The credential chain driving these attacks is propagating. TeamPCP’s March 24 litellm compromise harvested PyPI publishing tokens from thousands of CI/CD pipelines that import LiteLLM. Three days later, one of those stolen tokens enabled direct publication to telnyx’s PyPI account, bypassing GitHub entirely. Each compromised package produces credentials that unlock the next target. PyPI quarantined both malicious versions within approximately three hours of discovery by Endor Labs. Version 4.87.0, published March 26, is the last known-clean release.

TL;DR for Engineering Teams

What it is: Supply chain compromise of telnyx versions 4.87.1 and 4.87.2 on PyPI. Thin dropper in telnyx/_client.py fetches a 332-line credential harvester hidden inside a WAV audio file. Attributed to TeamPCP via identical RSA-4096 key. No CVE assigned.

Where it bites: Any Python environment with telnyx==4.87.1 or telnyx==4.87.2 installed. Payload fires at import time on both Linux/macOS (FetchAudio) and Windows (setup). Version 4.87.1 had a NameError typo that killed the payload — 4.87.2 fixed it sixteen minutes later.

Why it matters: New WAV steganography delivery makes the payload invisible to static analysis and most content filters. Windows targeting added for the first time. Kubernetes lateral movement deploys privileged pods across every node. Persistence via audiomon.service polls C2 every 45–55 minutes.

Patch status: Both versions quarantined by PyPI. Last known-clean version: telnyx 4.87.0 (published March 26, 2026, verified clean by Endor Labs).

Immediate action: Check pip show telnyx. Downgrade to 4.87.0 immediately if running 4.87.1 or 4.87.2. Block 83.142.209.203 at network perimeter. Remove audiomon.service and ~/.config/audiomon/. Delete Startup/msbuild.exe on Windows. Rotate all credentials accessible to the affected host.

Vulnerability Overview

Technical Anatomy

Root Cause: Stolen PyPI Token via Credential Cascade

There are no GitHub commits, tags, or releases for versions 4.87.1 or 4.87.2. The attacker bypassed telnyx’s automated release pipeline entirely and published using a stolen PyPI API token. Telnyx does not use PyPI Trusted Publishers (OIDC-based publishing) — it relies on a long-lived API token. Anyone holding that token can publish from any machine, anywhere.

The most probable acquisition vector is the litellm PyPI compromise of March 24. TeamPCP’s credential harvester sweeps environment variables, .env files, .npmrc files, and shell histories from every system that imports the compromised package. Any developer workstation or CI runner that had both litellm installed and access to the telnyx PyPI token had that token in TeamPCP’s exfiltration archive. The three-day gap between litellm and telnyx fits the operational tempo of sifting through harvested credentials and selecting the next high-value target.

Exploit Path

Step 1 — Entry point: TeamPCP published malicious telnyx wheels directly to PyPI using a stolen API token. No GitHub interaction, no CI pipeline, no code review. Users importing telnyx or any dependency that transitively imports it become victims.

Step 2 — Vulnerability trigger: All malicious code lives in a single modified file: telnyx/_client.py (7,825 lines). The legitimate SDK code ends around line 7,758. The attacker appended malicious imports (lines 4–10), a base64 decoder helper (lines 41–42), a 4,428-character base64 payload blob (line 459), and two attack functions (lines 7,761–7,825). Both attack paths are invoked at module scope, meaning execution begins the moment Python imports telnyx — before any application code runs.

Step 3 — Execution impact: On Linux/macOS, FetchAudio() spawns a detached subprocess (start_new_session=True) that decodes the inline payload and fetches the real harvester hidden inside ringtone.wav from 83.142.209.203:8080. On Windows, setup() downloads hangup.wav, extracts a native PE binary using the same XOR-key WAV steganography, and installs it as msbuild.exe in the Startup folder for persistence across reboots.

WAV Steganography: The Core Technical Innovation

The defining advancement in this attack is the use of WAV audio files as payload carriers. The WAV files (ringtone.wav on Linux/macOS, hangup.wav on Windows) are structurally valid audio files. They pass MIME-type checks, content filters, and inspection. The audio frame data, however, is not audio — it is base64-encoded, XOR-encrypted Python code.

Extraction: read WAV frames, base64 decode, take the first 8 bytes as an XOR key, XOR-decrypt the remainder. What emerges is the full 332-line Python credential harvester. To any network monitoring system watching the wire, the application downloaded a ringtone. The actual payload never exists on disk in the package and is not visible to any static analysis of the installed wheel.

Python:

with wave.open(wf, 'rb') as w:
    b = base64.b64decode(w.readframes(w.getnframes()))
    s, m = b[:8], b[8:]
    payload = bytes([m[i] ^ s[i % len(s)] for i in range(len(m))])

Aikido researcher Charlie Eriksen first documented this technique on March 22 in the TeamPCP Kubernetes wiper payload, five days before it appeared in the telnyx package. This is not an experimental tactic — it is now an established TeamPCP delivery primitive.

This architecture has significant operational implications for defenders. The package footprint is 87% smaller than litellm. The payload is updatable without republishing. If the C2 server goes dark, forensic recovery of the full attack capability breaks down. No post-incident analysis can reconstruct what payload was delivered without a contemporaneous network capture.

Stage 1: The Thin Dropper and Credential Harvester

The base64-encoded _p variable in _client.py decodes to an 85-line audioimport() script whose sole purpose is to fetch the WAV file and extract the real harvester. The harvester is a 332-line Python orchestrator covering:

Stage 2: Active Cloud Exploitation

The harvester does not stop at filesystem reads. If AWS credentials are found, it implements a full AWS SigV4 signing routine to directly query Secrets Manager (ListSecrets + GetSecretValue) and SSM Parameter Store (DescribeParameters). Secrets that exist only in managed services, never on disk, are pulled and included in the exfiltration archive.

Stage 3: Kubernetes Lateral Movement

If a Kubernetes service account token exists at /var/run/secrets/kubernetes.io/serviceaccount/token, the harvester deploys a privileged pod to every node in the cluster. Each pod runs in kube-system with privileged: true, hostPID, hostNetwork, and the host root filesystem mounted at /host. Pods tolerate all taints, ensuring they schedule on control-plane nodes as well as workers. Each pod chroots into the host filesystem to install the audiomon.service persistence implant directly on the node.

Stage 4: Encryption and Exfiltration

Collected data is encrypted with AES-256-CBC (32-byte random session key, PBKDF2 derivation), the session key wrapped with the hardcoded RSA-4096 public key using OAEP padding. The bundle is packaged as tpcp.tar.gz and POSTed to http://83.142.209.203:8080/ with the header X-Filename: tpcp.tar.gz. This C2 operates over plain HTTP on port 8080 — network inspection is possible if defenders are monitoring.

Windows Attack Path: setup()

The setup() function is the first Windows-targeting capability in the TeamPCP campaign. It builds a path to the Windows Startup folder using runtime-decoded base64 components, checks a hidden lock file (msbuild.exe.lock with a 12-hour cooldown), fetches hangup.wav from the C2, extracts a native Windows PE binary using identical XOR-key WAV steganography, drops it as msbuild.exe in the Startup folder, and launches it silently (CREATE_NO_WINDOW). The binary executes on every user login.

Persistence

On Linux/macOS, the WAV-delivered harvester installs audiomon.service (“Audio Controller”) as a systemd user service, writing the backdoor to ~/.config/audiomon/audiomon.py. The implant polls http://83.142.209.203:8080/raw every 45–55 minutes (jittered) for new WAV payloads. The kill switch is identical to litellm and the Checkmarx wave — if the response contains youtube.com, execution aborts.

Version 4.87.1: The Typo Wave

Version 4.87.1 was the attacker’s first publication attempt. A single-character typo — Setup() (capital S) instead of setup() (lowercase) — caused a Python NameError on import. Neither the Windows nor Linux attack chains executed. Sixteen minutes later at 04:07 UTC, the attacker pushed 4.87.2 with the fix. The error is consistent with the “vibe-coded” (AI-assisted, minimally reviewed) development pattern Aikido researchers observed in CanisterWorm.

Affected Versions

Telnyx (This Compromise)

Prior TeamPCP Waves — Cumulative Affected Scope

Exposure Analysis

Detection Guidance

Indicators of Compromise

File Hashes (SHA-256)

Verification Steps

1. Check installed version: pip show telnyx 2>/dev/null | grep Version
2. Check all lock files: grep telnyx requirements.txt poetry.lock uv.lock Pipfile.lock 2>/dev/null
3. Scan for Linux persistence: ls -la ~/.config/audiomon/audiomon.py ~/.config/systemd/user/audiomon.service /tmp/.initd_state 2>/dev/null
4. Check Windows Startup: dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe"
5. Check Kubernetes: kubectl get pods -n kube-system | grep node-setup
6. Review network logs for outbound connections to 83.142.209.203 port 8080
7. Check systemd: systemctl - user status audiomon.service 2>/dev/null

Remediation Guidance

Immediate Actions

1. Identify affected systems: pip show telnyx | grep Version across all environments, CI/CD runners, container images, and developer workstations. Check lock files.
2. Downgrade immediately: pip install telnyx==4.87.0 — the last known-clean version.
3. Remove Linux persistence: systemctl --user stop audiomon.service && systemctl --user disable audiomon.service. Remove ~/.config/audiomon/, ~/.config/systemd/user/audiomon.service, /tmp/.initd_state, and any /tmp/pglog.
4. Remove Windows persistence: Delete msbuild.exe and msbuild.exe.lock from %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\.
5. Kubernetes cleanup: kubectl get pods -n kube-system | grep node-setup and delete all hits. Inspect all nodes for ~/.config/audiomon/ persistence installed by privileged pods.
6. Block C2: 83.142.209.203 (all ports). Also maintain blocks on checkmarx[.]zone and scan.aquasecurtiy[.]org from prior waves.
7. Rotate every credential accessible to affected hosts: SSH keys, AWS/GCP/Azure credentials, Secrets Manager and SSM secrets, LLM API keys, database passwords, Docker registry tokens, CI/CD secrets, npm/PyPI tokens, Kubernetes service account tokens, telephony API keys and webhook secrets.
8. Check cloud audit logs for unauthorised API calls: AWS CloudTrail for Secrets Manager and SSM access, GCP Audit Logs, Azure Activity Log.

Long-Term Hardening

• Pin all Python dependencies to exact versions with hash verification using pip install --require-hashes
• Enable PyPI Trusted Publishers (OIDC) for every package your organisation publishes — this single change would have prevented both the litellm and telnyx compromises
• Pin all GitHub Actions to full commit SHAs using Zizmor, pinact, or Renovate pinGitHubActionDigests
• Implement network-isolated builds where CI/CD runners only permit traffic to explicitly allowlisted registries
• Apply a 48–72 hour hold before adopting new package patch versions in production

Phoenix Security Recommendations

The telnyx compromise confirms the operational pattern: each compromised tool generates credentials that unlock the next target. TeamPCP is working through a credential cache assembled over seven days of CI/CD pipeline harvesting. Trivy credentials funded the first PyPI attack; litellm credentials funded telnyx. The next target is likely already selected.

This campaign has no CVE, no CVSS score, and no NVD entry — for any of the nine attack vectors to date. Traditional vulnerability management programmes that rely on CVE feeds and CVSS prioritisation have zero signal on this threat. The attack targets the security and developer tooling your teams trust most.

Attack surface management: Phoenix identifies which environments have telnyx, litellm, trivy-action, and Checkmarx actions installed and maps installed versions against known-compromised releases.

Contextual deduplication: A single compromised PyPI package deployed across 50 microservices and 20 CI pipelines generates 70 potential findings. Phoenix correlates across environments and teams into a single prioritised backlog.

Reachability analysis: Phoenix distinguishes between environments where the compromised telnyx version was installed versus where it was imported and the payload actually executed.

Remediation campaigns: Create a campaign in Phoenix to track across all affected waves: SHA migration, telnyx/litellm downgrade verification, persistence artifact removal, credential rotation, Kubernetes pod cleanup, and cloud audit log review.

Ownership attribution: When telnyx is deployed across multiple teams, Phoenix maps vulnerable components to responsible teams automatically.

Campaign Timeline: Day 7 Update

References

1. Endor Labs — TeamPCP Strikes Again: telnyx Compromised Three Days After LiteLLM
2. GitHub Issue #235 — [SECURITY] PyPI versions 4.87.1 and 4.87.2 are compromised (kiran-sec)
3. Endor Labs — TeamPCP Isn’t Done: Threat Actor Behind Trivy and KICS Compromises Now Hits LiteLLM
4. JFrog Security Research — Popular litellm Python package is the latest victim of TeamPCP
5. Wiz Research — Trivy Compromised by TeamPCP
6. Wiz Research — KICS GitHub Action Compromised: TeamPCP Supply Chain Attack
7. CrowdStrike — From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise
8. Socket Security — Trivy Under Attack Again: Widespread GitHub Actions Tag Compromise
9. Socket Security — CanisterWorm: npm Publisher Compromise Deploys Backdoor Across 29 Packages
10. Aikido Security — TeamPCP Deploys CanisterWorm on NPM Following Trivy Compromise
11. Sysdig TRT — TeamPCP Stealer Detected in Checkmarx ast-github-action
12. StepSecurity — Trivy Compromised a Second Time
13. PyPI Advisory — telnyx 4.87.1 and 4.87.2 quarantine (March 27, 2026)

How Phoenix Security Fixes What Actually Matters

Your team doesn’t have a finding problem. They have a fixing problem.

Most platforms hand you a list. Phoenix hands you a plan — ranked by real risk, mapped to the team that owns it, with a clear path to close it.

What remediation looks like with Phoenix:

• One backlog, not five. Findings from SAST, SCA, containers, and cloud — deduplicated, correlated, and surfaced in a single prioritized queue. No more reconciling lists across tools.
• Ownership that sticks. Team attribution and inheritance mean the right ticket goes to the right engineer, first time. No routing, no guessing, no back-and-forth.
• Campaigns that move the needle. Group related findings into targeted remediation campaigns. Track progress, measure closure rates, and report real reduction — not raw counts.
• AI that does the legwork, not the deciding. Phoenix’s Remediator agent drafts fixes, creates tickets, and opens PRs. Your team reviews, approves, and merges. Every fix is traceable.

Phoenix Security changes the game.

The pattern is the same every time: teams that move from find and report to analyze and fix close more risk with less effort.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

👉 Book a demo today

Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.

Fix with remediaiton don’t chase ghost vulnerabilities

Get Fixing today