TeamPCP’s Telnyx Attack Marks a Shift in Tactics Beyond LiteLLM

TeamPCP 在入侵了 LiteLLM AI 代理器 (proxy) 套件三天之後，又再度發動攻擊。Telnyx Python SDK 這個在 2 月份擁有 70 萬次下載的雲端通訊函式庫出現了兩個惡意的版本在 2026 年 3 月 27 日被發布到 PyPI 上。此惡意檔案象徵該集團的攻擊手法出現明顯轉變'，不僅利用 WAV 隱碼術 (WAV-based steganography) 將竊取登入憑證的程式碼內嵌在 WAV 檔案中，更結合了檔案分割程式碼注入技巧來躲避視覺化檢查，而'且首次加入了常駐於 Windows 的機制。根據該專案'的 GitHub 資安公告，PyPI 已在 UTC 世界協調時間 10:13 隔離了 4.87.1 和 4.87.2 兩個版本 (大約暴露在外 6.5 個小時)。

本文探討 Telnyx 入侵事件並提供我們的技術分析，詳細說明了這些惡意套件如何變成駭客的攻擊武器，以及自從上次 LiteLLM 事件之後有何變動，還有資安人員該注意些什麼。我們會隨時監控和分析最新發展，一有最新消息就會更新本文。

如需有關整起 TeamPCP 攻擊行動以及 LiteLLM 入侵事件的背景資訊，請參閱我們先前的分析：您的 AI 閘道就是後門：深入探討 LiteLLM 供應鏈入侵事件。

簡介

世界協調時間 (UTC) 3 月 27 日 03:51，Telnyx 4.87.1 和 4.87.2 兩個版本在上游 GitHub 儲存庫中並無相關提交 (commit) 記錄的情況下出現在 PyPI 上。我們的分析證實，惡意程式碼是被注入到「telnyx/_client.py」當中，所有執行路徑都在模組範圍內觸發，意味著只要單純匯入 telnyx 就足以啟動惡意檔案。

可以肯定的說，這是 TeamPCP 所為。根據我們分析發現，其中有多項元素與 LiteLLM 惡意檔案幾乎在位元組 (byte) 層次完全相同：RSA-4096 公開金鑰、tpcp.tar.gz 攻擊行動 ID、X-Filename: tpcp.tar.gz 外傳標頭、OpenSSL 加密鏈 (Rand + AES-256-CBC + RSA-OAEP + tar)、暫存檔案命名慣例，以及子處理程序使用 stdin 管線 (pipe) 來執行的模式。如此可確認駭客重複使用了同一套工具。

截至本文撰稿為止，我們仍無法判斷 TeamPCP 是如何取得 Telnyx 專案'的 PyPI 發布登入憑證。該專案'的 GitHub 公告指出，沒有發現任何工作流程層級的登入憑證外流，而且 PyPI 也沒有設定信任的發布者 (OIDC)。

檔案分割注入：提高躲避能力

LiteLLM 惡意檔案在兩個正常的程式碼區段之間注入一段連續的惡意程式碼，使得任何人在該檔案內捲動查看時都可以看到。Telnyx 變種在這個基礎上加以改良，將惡意元素散布在「_client.py」當中的三個間隔很開的位置：

Base64 解碼包裝函式「_d()」：埋藏在正常匯入函式中。
Linux 協調器與登入憑證蒐集器：這是一個 4,428 個字元的 Base64 字串，放在 __all__ 與類別定義之間。
Windows 執行路徑與 WAV 隱碼術邏輯：附加在檔案末端的所有合法類別之後。

Figure 1. Base64 decode wrapper function, buried among legitimate imports

Figure 2. Linux orchestrator and harvester as a 4,428-char Base64 string, placed between __all__ and class definition

Windows 路徑中的所有敏感字串都會使用「_d()」包裝函式來加密編碼，變成 Base64 字串，然後在執行時期解開。這一點與 LiteLLM 不同，LiteLLM 的字串在 Base64 編碼的惡意檔案內仍保留為明碼形式。解碼後的數值包括：Startup 開機資料夾路徑、msbuild.exe 檔案名稱，以及幕後操縱 (CC) 網址。

Figure 3. The malware's Windows and Linux Execution path functions, both called at module scope import

改用音訊隱碼術

Telnyx 變種從上次 LiteLLM 攻擊事件之後最大的改變是不再將登入憑證蒐集器內嵌在原始程式碼當中。而是在執行時期從 CC 伺服器下載蒐集器，該蒐集器隱藏在結構完整的 WAV 音訊檔案中。

根據我們對其擷取程序的分析顯示，WAV 檔案'的原始音訊是使用 Python '的 wave 模組來讀取 (採用 Base64 編碼)，然後再進行分割：前 8 個位元組是 XOR 金鑰，其餘位元組則是以 XOR 加密的惡意檔案。每個位元組都會使用一個循環式 8 位元組金鑰進行 XOR 運算來還原成原本的明碼文字。

Figure 4 . The decoded Base64 payload for Linux downloading the WAV file, which it then decodes, and runs the resulting payload

所以，如果對該套件的原始程式碼進行靜態分析，並不會看到任何蒐集器的程式邏輯，因為實際的登入憑證竊取腳本只存在於 CC 伺服器上的音訊檔案內。這些 WAV 檔案會被 MIME 類型檢查視為正常的媒體檔案，還能躲過副檔名過濾條件，並且躲過靜態字串分析。這比起 LiteLLM 變種的躲避能力可算是大幅提升，整個蒐集器就是一個內嵌的 Base64 靜態二進位大型物件 (Blob)。

根據 Aikido 的記載，TeamPCP 攻擊行動最早使用 WAV 隱碼術的是 3 月 22 日的 Kubernetes 清除器變種 kamikaze.sh。Telnyx 入侵事件顯示，其技巧已從實驗用途成熟到可部署至 PyPI，從原型進化至營運的週期已壓縮到短短五天之內。

瞄準雙重平台

LiteLLM 惡意檔案只會攻擊 Linux 系統，但到了 Telnyx 變種，目標已擴大涵蓋至 Windows。

Windows 執行過程分析

在 Windows 上執行時，它會從 83[.]142[.]209[.]203:8080 下載 hangup.wav 檔案，接著利用 XOR 隱碼術技巧解出一個 PE 執行檔案 msbuild.exe，然後安裝到「%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\」路徑來建立開機常駐機制。這個檔案名稱刻意模仿了 Microsoft '的 MSBuild 工具。

此執行檔啟動時會指定 CREATE_NO_WINDOW 旗標 (0x08000000)，這樣就不會產生任何看得見的視窗。它還有一個反制回放的機制會檢查 msbuild.exe.lock 這個鎖定檔案 (lock file) 的狀態，如果它在過去 43,200 秒 (12 小時) 當中曾經被修改過，那就會略過執行的動作。此鎖定檔案會透過 attrib +h 指令來將它隱藏，這樣可防止重複下載和執行，避免套件被匯入多次，同時也可減少網路流量，降低被偵測的風險。

Figure 5. The anti-replay lock file mechanism checks msbuild.exe.lock modification time, skips if it less than 43,200 seconds (12 hours), and hides lock via attrib +h

Linux/macOS 執行過程分析

在 Linux/macOS 上執行時，Bas64 惡意檔案是以分離的背景處理程序來啟動，並使用 subprocess.Popen 搭配 start_new_session=True 參數並關閉輸出結果。接著，惡意檔案會從同一台 CC 伺服器下載 ringtone.wav 檔案，然後使用相同的 WAV 隱碼術技巧解開登入憑證蒐集器，然後執行標準的 TPCP 資料外傳流程 (AES-256-CBC + RSA-4096 OAEP -> tpcp.tar.gz -> HTTP POST)。

基礎架構轉型

Telnyx 變種捨棄了在 LiteLLM 攻擊行動中使用的 HTTPS + 網域的基礎架構，改用明碼的 HTTP 搭配原始 IP 位址，這有可能是因為 LiteLLM 網域已被人通報並下架，迫使駭客轉而直接使用 IP 位址。然而，改用明碼 HTTP 會讓 WAV 檔案下載和外傳的 tpcp.tar.gz 壓縮檔暴露於網路監控，因此有機會遭到偵測，這是 HTTPS LiteLLM 基礎架構不會遇到的問題。

	LiteLLM	Telnyx
Exfiltration	`hxxps[://]models[.]litellm[.]cloud/`	`hxxp[://]83[.]142[.]209[.]203:8080/`
C&C server / payload	`hxxps[://]checkmarx[.]zone/raw`	`hxxp[://]83[.]142[.]209[.]203:8080/` (WAV files)
Protocol	HTTPS (encrypted)	HTTP (plaintext)
Addressing	Domain names	Direct IP

表 1：LiteLLM 與 Telnyx 變種的基礎架構比較。

Figure 6. TeamPCP exfiltration pipeline comparison; LiteLLM (HTTPS domains) vs Telnyx (plaintext HTTP on raw IP).

結論與建議

Telnyx 入侵事件顯示，TeamPCP 的供應鏈攻擊所使用的技巧一直在不斷變換，包括工具、派送方式及支援的平台皆有所調整。在短短八天之內，駭客的目標就從資安掃描工具轉移至 AI 基礎架構，然後這次是電信產業。其派送方式也從內嵌 Base64 換成 .pth 自動執行，最後再換成檔案分割 WAV 隱碼術。而平台方面也從單純的 Linux 版拓展至雙平台，而且在 Windows 上還能常駐。

從使用加密的 HTTPS + 網域改成使用明碼 HTTP + 原始 IP 位址，有可能對基礎架構帶來更大壓力，但這也同時帶來被偵測的機會。在受害環境可能看到的徵兆包括：從非影音網站 IP 位址 8080 連接埠下載 WAV 檔案、使用者的 Startup 開機資料夾出現非預期的 msbuild.exe 二進位檔案、外送 HTTP 請求中含有「X‑Filename: tpcp.tar.gz」標頭，以及使用像「attrib +h」這樣的指令來隱藏「.lock」檔案。

為了謹慎起見，企業若已安裝 Telnyx 4.87.1 或 4.87.2 版，最好降級至上次已知乾淨的版本 (4.87.0)，並且將匯入受影響版本的系統視為已遭入侵。此外，企業也應根據雜湊碼來緊盯著所有 PyPI 相依元件，並密切監控 CI/CD 環境是否有非預期的音訊檔案下載行為。

採用 TrendAI Vision One™ 的主動式防護

TrendAI Vision One™ 是唯一將資安曝險管理、資安營運以及強大的多層式防護集中在一起的業界領先 AI 網路資安平台。

TrendAI Vision One™ Threat Intelligence Hub

TrendAI Vision One™ Threat Intelligence Hub 威脅情報中心提供了有關新興威脅與駭客集團的最新洞見、TrendAI™ Research 的獨家策略性報告，以及 TrendAI Vision One™ 平台的 TrendAI Vision One™ Threat Intelligence Feed 威脅情報來源。

新興威脅：TeamPCP 攻擊 Telnyx：使用 WAV 隱碼術並瞄準 WindowsTeamPCP Hits Telnyx: WAV Steganography and Windows Targeting

TrendAI Vision One™ Intelligence Reports (IoC 掃描)

TeamPCP 攻擊 Telnyx：使用 WAV 隱碼術並瞄準 Windows

TrendAI Vision One™ Search 應用程式

TrendAI Vision One™ 客戶可以使用 Search 應用程式來尋找或追蹤本文提到的惡意指標，看看是否也出現在自己的環境中。

追蹤查詢

偵測連線至攻擊行動' C&C 伺服器的網路連線

eventSubId:201 AND request:"*83.142.209.203*"

除此之外，TrendAI Vision One™ 客戶還可啟用 Threat Insights Hub 權利來取得更多追蹤查詢。

入侵指標 (IoC)

如需本文提到的入侵指標完整清單，請至此處。

從 LiteLLM 到 Telnyx：TeamPCP 攻擊戰術轉型，威脅範圍再擴大

Key Takeaways

簡介