PyPI上のTelnyx Python SDKは、複数段階のWAVステガノグラフィペイロードを使用して、Windows、macOS、Linuxシステム全体で認証情報を盗みます。
バックドアはtelnyx/_client.pyに存在し、モジュールスコープでトリガーされるため、telnyxを簡単にインポートするだけで、アプリケーションコードが実行される前にペイロードが実行されます。
プロジェクトのセキュリティ通知によると、不正なリリースはPyPIが約10:13 UTCに隔離するまで、約6.5時間利用可能なままでした。
これらのバージョンをインストールまたはインポートした環境は完全に侵害されたものとして扱う必要があり、Telnyxはユーザーに最後の既知のクリーンビルドであるバージョン4.87.0に戻すことを促しています。
2026年3月27日、攻撃者は2つの悪意のあるTelnyx SDKバージョン4.87.1と4.87.2を、公式GitHubリポジトリ内の対応するコミットなしにPyPIに直接公開しました。
TeamPCP脅威アクターへの帰属は、以前のLiteLLMサプライチェーンインシデントとの強い技術的重複によって支持されています。
研究者は、同一のRSA‑4096公開鍵、同じtpcp.tar.gzキャンペーン識別子、共有されたX-Filename: tpcp.tar.gz流出ヘッダー、およびコマンド・アンド・コントロール・サーバーにアーカイブを送信する前にランダムデータ、AES‑256‑CBC、およびRSA‑OAEPを組み合わせた再利用されたOpenSSLベースのチェーンに注目しています。
これらの共有される要素は明らかに同じツールチェーンを指しており、Telnyxがより広い継続中のTeamPCPキャンペーンの一部であることを確認しています。
PyPI Telnyx Python SDK
単一の連続した悪意のあるブロックを挿入した以前のLiteLLMバックドアとは異なり、Telnyxペイロードは簡単な検査を避けるためにtelnyx_client.pyの複数の領域に分割されています。
アナリストは3つの主要コンポーネントを観察しました：正当なインポートの中に隠された小さなBase64デコードヘルパー関数_d()、Linux/macOSオーケストレーターを含む4,428文字のBase64ブロブ、およびSDKの通常のクラス定義の後に追加されたWindows固有の実行パス。
WindowsとUnix系のパスの両方がインポート時に呼び出され、サポートされているプラットフォームでの自動実行が確保されます。
Windows分岐内のすべての機密文字列は難読化されており、_d()Base64ラッパーを通じて実行時にのみ明らかになります。
デコードされた値には、Startupフォルダーパス、永続性に使用されるmsbuild.exeファイル名、およびHTTPコマンド・アンド・コントロールURLが含まれており、静的分析をさらに複雑にしています。
対照的に、LiteLLMの悪意のあるブロックは単一のBase64ペイロード内に多くの平文文字列を含んでおり、防御者が疑わしいインフラストラクチャ指標を発見しやすくなりました。
最も重要な技術的変化は、認証情報盗取ツールをパッケージコードに直接埋め込むから、実行時にダウンロードされるWAVオーディオファイル内に隠すことへの転換です。
バックドアが実行されると、攻撃者が制御するサーバーから一見有効なWAVファイルを取得し、Python標準waveモジュールを使用して生オーディオフレームを解析し、その後Base64でデータをデコードします。
デコードされたバイトは、最初の8バイトがXORキーになり、残りがXOR暗号化されたペイロードを形成するように分割されます。8バイトの回転キーでブロブを反復処理することで、平文の盗取ツールを再構成します。
これらのWAVファイルは構造的に有効なメディアオブジェクトであり、MIMEタイプチェックに合格し、基本的なファイル拡張子フィルターをバイパスし、簡単に検索可能な文字列を含まないため、LiteLLMで見られるインラインBase64アプローチよりも大幅に回避を改善しています。
研究者は以前、Kubernetesワイパースクリプト（kamikaze.sh）でTeamPCPがWAVステガノグラフィを試験しているのを観察していました。Telnyxインシデントは技術が1週間以内にプロトタイプから本番に移行することを示しています。
クロスプラットフォーム認証情報盗取
LiteLLMがLinuxのみに焦点を当てた場合、TelnyxバックドアはLinuxおよびmacOS機能を維持しながら、専用のWindowsサポートを追加しています。
Windowsでは、マルウェアは83[.]142[.]209[.]203:8080からhangup.wavをダウンロードし、XORステガノグラフィルーチンを介してPE実行ファイルを抽出し、ユーザーレベルのブート永続性を実現するために%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\配下にmsbuild.exeとしてドロップします。
バイナリはCREATE_NO_WINDOWフラグを使用して起動され、目に見えるウィンドウを避け、アンチリプレイメカニズムは隠されたmsbuild.exe.lockファイルをチェックし、ロックが過去12時間以内に変更されている場合は再実行をスキップして、ノイズと検出を減らします。
LinuxおよびmacOSでは、Base64エンコードされたペイロードがデコードされ、新しいセッションとI/O抑制を使用してsubprocess.Popenで分離されたバックグラウンドプロセスとして実行されます。
このプロセスは同じC&CIPからringtone.wavをダウンロードし、同じXORベースのルーチンを使用して認証情報盗取ツールを抽出して実行し、収集した認証情報とシークレットを既知のTeamPCP流出パイプラインに供給します：データをtpcp.tar.gzにアーカイブし、AES‑256‑CBCおよびRSA‑4096で暗号化し、カスタムX-Filename: tpcp.tar.gzヘッダーでHTTP POSTで送信します。
ターゲットはSSHキー、環境変数、クラウド認証情報、およびCI/CD、開発者、本番環境内の他の高価値シークレットです。
TelnyxはまたLiteLLMなどの以前のTeamPCPステージで使用されたドメインベースのHTTPSインフラストラクチャからの離脱を示しています。
models.litellm.cloudおよびcheckmarx.zoneなどのドメインの背後に隠れるのではなくHTTPS経由で行うのではなく、TelnyxペイロードはプレーンテキストHTTP経由でWAVダウンロードと流出したアーカイブの両方について83[.]142[.]209[.]203:8080に直接通信します。
研究者は以前のC2ドメインが報告または破壊された可能性があると推測しており、アクターはネットワーク可視性の増加の代償としてrawIPアドレスへのフォールバックを余儀なくされています。
このシフトは、出口トラフィックを監視している防御者のための新しい検出機会を開きます。疑わしい指標には、ポート8080上の非メディアIPからのWAVファイルダウンロード、X-Filename: tpcp.tar.gzヘッダーを持つtpcp.tar.gzアーカイブを携行するアウトバウンドHTTP POST、およびWindowsStartupディレクトリ内の異常なmsbuild.exeバイナリまたは隠された.lockファイルが含まれます。
ネットワークセキュリティチームはプロキシ、ファイアウォール、IDS/IPSログ全体でこれらのシグネチャを検索できます。一方、EDRツールはTelnyxをインポートするPythonを含む異常なプロセスチェーンをフラグして、その後シェルまたはmsbuild.exe活動を実行するように調整できます。
Telnyxバージョン4.87.1または4.87.2をインストールした組織は、すぐにTelnyx 4.87.0にダウングレードし、影響を受けるシステムが完全に公開されていると仮定する必要があります。
インシデント対応チームは、APIトークンを含むそれらの環境からアクセス可能なすべての認証情報を回転させ、SSHキーとCI/CDシークレット、およびパッケージがインポートされた開発者ワークステーション、ビルドサーバー、本番ホスト上で完全な侵害評価を実行する必要があります。
防御者はまた、ユーザーStartupフォルダー内のmsbuild.exeの存在、隠された属性を持つmsbuild.exe.lockファイル、および83[.]142[.]209[.]203:8080からの異常なWAVダウンロードの証拠を検索する必要があります。
より長期的には、チームはすべてのPyPI依存関係をバージョンとハッシュでピン留めし、再現可能なビルドを強制し、ハードウェアバックアップ認証とスコープされたトークンを使用して公式パッケージリポジトリに公開できるユーザーを制限することを強くお勧めします。
翻訳元: https://gbhackers.com/pypi-telnyx-python-sdk/
