A sophisticated supply‑chain attack targeting the official telnyx Python SDK on PyPI, in which two malicious versions of the package (4.87.1 and 4.87.2) were published that contain embedded credential‑harvesting malware.
The telnyx library is the vendor‑supported Python SDK for the Telnyx communications platform. It is widely used to integrate voice, SMS/MMS, WhatsApp, fax, SIP trunking, and IoT connectivity into backend systems. Because it commonly runs in environments that hold API keys, telephony infrastructure, and customer communications, a compromise of this SDK can expose sensitive credentials and operational workflows.
The malicious releases were identified and quarantined by PyPI, and users are advised to downgrade to version
telnyx package is downloaded tens of thousands of times per month, and those figures likely undercount real‑world deployment because many teams rely on internal PyPI mirrors and pinned dependencies. The SDK is particularly dangerous as a supply‑chain vector because it is often deployed in production‑facing services that possess long‑lived credentials, cloud‑provider tokens, and access to customer messaging systems.
Socket’s analysis describes a three‑stage, cross‑platform attack chain that runs at runtime on Linux/macOS and Windows, using audio steganography to deliver a second‑stage harvester before exfiltrating data via encrypted HTTP POST. All malicious code is injected into a single file, src/telnyx/_client.py, the core HTTP client that any application loads when import telnyx is called.
Instead of using a postinstall hook (which many security scanners monitor), the attacker triggers execution via top‑level calls at import time: setup() for Windows and FetchAudio() for Linux/macOS.
This technique bypasses many standard PyPI‑malware heuristics and ensures the payload runs only when the library is actually used, giving it full access to the host’s environment variables, credentials, and filesystem permissions.
Inside the SDK, the dropper adds imports such as subprocess, tempfile, os, wave, and urllib.request, then embeds a large base64‑encoded blob (_p) that, when decoded, contains the full Linux‑targeted payload. The malware on Windows uses audio steganography to download a hangup.wav file from the attacker’s server, extracts a PE binary from the audio frames, and drops it msbuild.exe in the Windows Startup folder, enabling persistence after reboot.
The Linux/macOS path takes a “smash‑and‑grab” approach: it spawns a detached Python process to decode and execute the harvester in‑memory, collect data, encrypt it with AES‑256‑CBC and RSA‑4096, and exfiltrate the bundle tpcp.tar.gz to the same C2 server.
Rather than embedding the harvester directly in the PyPI package, the malware downloads a .wav file (ringtone.wav) from the command‑and‑control server 83.142.209.203:8080 using a spoofed Mozilla/5.0 User‑Agent to blend in with normal traffic.
The WAV file’s raw audio frames are base64‑decoded and XOR‑decoded with an 8‑byte key, yielding a second‑stage Python script that is then executed via stdin into a new Python interpreter (sys.executable), never touching the disk. This fileless execution complicates traditional file‑based detection, as the harvester exists only in memory and in pipe buffers, leaving no persistent artifacts on Linux/macOS hosts.
The exfiltration phase uses a hybrid encryption scheme: the collected data is encrypted with a randomly generated AES‑256‑CBC key, which is then RSA‑4096‑OAEP‑wrapped using a hardcoded public key embedded in the malware.
The resulting archive (tpcp.tar.gz), containing both payload.enc and session.key.enc, is sent via curl to the C2’s root endpoint with a custom header X‑Filename: tpcp.tar.gz That likely helps the attacker tag and route stolen data.
The use of OpenSSL command‑line tools and system‑installed curl avoids adding suspicious dependencies to the package metadata, making the malicious payload harder to spot through static‑analysis checks.
The attack ties into a broader campaign associated with a group named “TeamPCP,” which has been observed targeting multiple package registries.
Both the Windows and Linux paths connect to the same C2 83.142.209.203:8080 over plain HTTP, exposing three endpoints for payload delivery and exfiltration. The lack of TLS weakens the actor’s operational security, but the hybrid encryption on the exfiltration path still renders captured data unusable without the attacker’s private key.
The malware is designed to self‑clean: all temporary files are created inside a tempfile.TemporaryDirectory() context, which Python automatically deletes on exit, and nearly all subprocess errors are silently swallowed.
On Linux/macOS, there is no persistence mechanism (no cron jobs, launch agents, or systemd services), so the payload triggers only once at import time, trading long‑term access for a higher chance of going undetected. This contrasts with the Windows path, which relies on the Startup folder for persistent access and is therefore more likely to leave forensic traces on endpoint‑detection systems.
Users should audit their Python environments and dependency files for telnyx==4.87.1 or telnyx==4.87.2 and immediately replace these versions with 4.87.0 or earlier.
Any credentials, API keys, SSH keys, or secrets accessible in environments where the malicious package was imported should be treated as compromised and rotated without delay. On Windows, security teams should inspect %APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\ for msbuild.exe, .lock, or .tmp files that indicate the deployment of the persistent implant.
Organizations with internal PyPI mirrors or build‑service caches should confirm that the quarantined versions have been purged and are no longer resolvable.
Security teams should block and log traffic to 83.142.209.203:8080 and search for historical connections to that address, since any such communication indicates the dropper was triggered.
Analysts should also tune detection rules to flag anomalous imports of standard‑library modules (e.g., subprocess, tempfile, wave, urllib.request) in core client libraries, and monitor for new package versions that lack corresponding source‑control tags or commits, a strong indicator of compromised publishing credentials.
Site: cybersecuritypath.com
About the Author
