Ein gezielter Supply-Chain-Angriff auf die Python-Softwarelieferkette hat das beliebte Paket Telnyx auf PyPI getroffen. Hinter der Kampagne steht die Gruppe TeamPCP, die bereits durch Angriffe auf Trivy, KICS und die Bibliothek litellm aufgefallen ist. In zwei manipulierten Versionen des Telnyx-Pakets wurde ein verstecktes Modul zur Kompromittierung von Zugangsdaten platziert – ausgeliefert über scheinbar harmlose WAV‑Audiodateien.
Manipulierte Telnyx-Versionen auf PyPI: Umfang und aktueller Status
Die kompromittierten Versionen telnyx 4.87.1 und 4.87.2 wurden am 27. März 2026 auf PyPI veröffentlicht. Ziel der Angreifer ist die Kompromittierung sensibler Informationen von Entwicklern und automatisierten CI/CD-Pipelines, darunter Zugangsdaten, Tokens und Konfigurationsdateien. Der bösartige Code ist in den Paketquellen verborgen und wird unbemerkt beim Import in beliebige Python-Anwendungen aktiv.
Sicherheitsforscher und Maintainer empfehlen ausdrücklich, sofort auf Version 4.87.0 zurückzurollen, die als letzte bekannte saubere Version gilt. Das Telnyx-Projekt wurde auf PyPI in eine Art Quarantänestatus versetzt, um die weitere Verbreitung der infizierten Builds zu begrenzen.
Technische Analyse: Code-Injektion und plattformübergreifende Angriffskette
Unabhängige Analysen von Aikido, Endor Labs, Ossprey Security, SafeDep, Socket und StepSecurity zeigen, dass der Schadcode in das Modul telnyx/_client.py injiziert wurde. Dadurch startet die Malware bereits beim Import des Pakets, ohne dass zusätzlicher Code aufgerufen werden muss. Der Angriff ist plattformübergreifend ausgelegt und zielt auf Windows-, Linux- und macOS-Systeme ab, was ihn besonders gefährlich für heterogene Dev- und Build-Umgebungen macht.
Linux und macOS: flüchtige Datendiebstahl-Kette mit Audiosteganografie
Auf Linux- und macOS-Systemen realisieren die Angreifer eine dreistufige Ausführungskette. Kern der Technik ist Audiosteganografie: Schadcode wird in einem legitimen wirkenden WAV‑File verborgen und zur Laufzeit extrahiert. Für diese Plattformen wird ein WAV-File mit dem Namen „ringtone.wav“ von einem Command-and-Control-Server heruntergeladen.
Aus dem Audiostream wird im Speicher ein weiterer Collector extrahiert, der ohne Ablage permanenter Binärdateien auf der Festplatte läuft. Dieses Modul sammelt umfangreiche sensible Daten wie Zugangsdaten, API‑Tokens, Umgebungsvariablen, Konfigurationsdateien und CI/CD‑Secrets. Anschließend werden die Informationen in einem Archiv „tpcp.tar.gz“ gebündelt und per HTTP POST an 83.142.209[.]203:8080 exfiltriert.
Alle temporären Artefakte werden nach Ausführung rekursiv gelöscht. Diese Strategie reduziert forensisch verwertbare Spuren auf ein Minimum und erschwert die nachträgliche Aufklärung erheblich – ein Muster, das laut Berichten wie der ENISA Threat Landscape zunehmend bei modernen Supply-Chain-Angriffen beobachtet wird.
Windows: Persistenz über gefälschtes „msbuild.exe“
Unter Windows verfolgen die Angreifer eine andere Taktik mit Fokus auf Persistenz. Von der C2-Infrastruktur wird ein WAV‑File „hangup.wav“ geladen. Aus dessen Audiodaten extrahiert die Malware ein ausführbares Windows-Binary, das im Autostartordner als „msbuild.exe“ abgelegt wird.
Da msbuild.exe ein legitimes Microsoft-Build-Werkzeug ist, fügt sich der Dateiname unauffällig in typische Entwicklerumgebungen ein. Das Programm wird bei jedem Benutzerlogin automatisch gestartet und übersteht Neustarts. Damit erhalten die Angreifer einen langfristigen Zugang zu kompromittierten Workstations – ein signifikanter Risikofaktor insbesondere in Unternehmensnetzwerken.
Die Rolle von litellm: vermutete Kompromittierung des Telnyx-PyPI-Tokens
Wie genau der PYPI_TOKEN des Telnyx-Projekts entwendet wurde, ist noch nicht abschließend geklärt. Forscher von Endor Labs halten es jedoch für wahrscheinlich, dass bereits zuvor gestohlene Zugangsdaten aus derselben Kampagne erneut genutzt wurden.
Im Zuge der litellm-Kompromittierung hatte TeamPCP einen Collector eingebaut, der Umgebungsvariablen, Inhalte von .env-Dateien und Shell-Historien auslas. In Entwicklungs- oder CI/CD-Umgebungen, in denen litellm installiert war und zugleich PyPI-Zugriff auf Telnyx konfiguriert wurde, konnten so mit hoher Wahrscheinlichkeit auch Telnyx-PyPI-Tokens abgegriffen werden. Dieser Kaskadeneffekt illustriert, wie ein einzelnes kompromittiertes Paket zu einer breiten Gefährdung der gesamten Softwarelieferkette führen kann.
Strategische Einordnung: von Typosquatting zu Angriffen auf vertrauenswürdige Werkzeuge
Auffällig ist, dass TeamPCP nicht auf klassische Typosquatting-Pakete setzt, sondern gezielt vertrauenswürdige, weit verbreitete Projekte ins Visier nimmt. Mit Trivy (Container-Scanner), KICS (IaC-Analyse) und litellm (Routing für KI-Modelle) wurden bewusst Werkzeuge angegriffen, die typischerweise weitreichende Leserechte auf Konfigurationen und Secrets in CI/CD-Pipelines besitzen.
Mehrere Branchenberichte, darunter der jährliche State of the Software Supply Chain von Sonatype, weisen seit Jahren darauf hin, dass Entwicklungs- und Sicherheitstools selbst zu attraktiven Zielen werden. Die mutmaßlichen Verbindungen von TeamPCP zu Gruppen wie LAPSUS$ und der sich formierenden Ransomware-Gruppe Vect unterstreichen zudem das Zusammenwachsen von klassischer Erpressungskriminalität und Software-Supply-Chain-Angriffen.
Sofortmaßnahmen und langfristige Schutzstrategien für DevSecOps-Teams
1. Organisationen sollten umgehend die eingesetzte Telnyx-Version prüfen. Wird 4.87.1 oder 4.87.2 verwendet, ist ein Rollback auf 4.87.0 erforderlich, ergänzt um Log-Analysen und eine Überprüfung betroffener Systeme.
2. Alle PyPI-Tokens und weiteren Secrets, die in Umgebungen mit litellm oder kompromittiertem Telnyx eingesetzt wurden, sollten widerrufen, rotiert und neu ausgestellt werden. Dies gilt insbesondere für CI/CD-Credentials und Cloud-Zugänge.
3. Es empfiehlt sich eine konsequente Versionsfixierung (Pinning) aller Abhängigkeiten, idealerweise kombiniert mit Hash-Prüfungen, Signaturvalidierung (z.B. Sigstore) und der Nutzung interner Mirror-Repositories, um unkontrollierte Upgrades aus öffentlichen Registern zu vermeiden.
4. Netzwerk- und Sicherheitsteams sollten nach Indikatoren einer Kompromittierung (IOC) suchen – darunter Verbindungen zu 83.142.209[.]203:8080 sowie ungewöhnliche Downloads von WAV- oder anderen Mediendateien aus Build- und CI/CD-Umgebungen.
5. CI/CD-Systeme, Scanner und Build-Werkzeuge sollten strikt nach dem Prinzip der minimal erforderlichen Rechte konfiguriert werden. Secrets gehören in dedizierte Secret-Management-Lösungen und sollten nicht direkt in Umgebungsvariablen oder Konfigurationsdateien harterkodiert werden.
6. Regelmäßige Audits der Entwicklungs- und Sicherheitswerkzeuge – inklusive IDE-Plugins, Container-Scanner und Python-Bibliotheken – sind entscheidend, um anomal wirkende Updates oder ungewöhnliches Verhalten frühzeitig zu erkennen.
Der Angriff auf das Telnyx-Python-Paket zeigt deutlich, dass Software-Supply-Chain-Sicherheit heute eine zentrale Disziplin moderner Cybersicherheitsstrategien ist. Organisationen, die ihre CI/CD-Pipelines, Abhängigkeitsverwaltung und Token-Policies jetzt kritisch überprüfen und mehrstufige Vertrauensprüfungen für Open-Source-Pakete etablieren, reduzieren das Risiko nachhaltig, dass sich ein versteckter Schadcode – verpackt in einer unscheinbaren WAV-Datei – seinen Weg bis in produktive Systeme bahnt.
