LiteLLM供應鏈攻擊：TeamPCP如何為人工智慧基礎設施植入後門

歸屬：TeamPCP

這次攻擊背後的威脅行為者已被追蹤到為： TeamPCP又稱 PCPcat、Persy_PCP、ShellForce 和 DeadCatx3。

已知特徵：

• 維護 Telegram 頻道 @Persy_PCP 以及  @teampcp 他們在那裡嘲諷安保公司
• 可在多個生態系統中運作（GitHub Actions、PyPI、npm、OpenVSX）
• 在行銷活動的每個階段使用特定供應商的網域搶注網域（例如， checkmarx.zone 對於 Checkmarx， models.litellm.cloud （供 litellm 使用）
• 一致的基礎設施標記：相同的 RSA 金鑰對， tpcp.tar.gz 命名規則 tpcp-docs-* GitHub 倉庫用作死信箱暫存區
• 將安全工具作為進入下游供應鏈的入口。

歸因置信度高。共享的RSA公鑰， tpcp 五天行動中工件命名、C2 基礎設施重疊和操作節奏都強烈表明，Trivy、KICS、npm、OpenVSX 和 litellm 的漏洞利用與同一攻擊者有關。

動機很可能是經濟利益驅動（加密錢包被偷、雲端憑證變現）加上惡名昭彰（Telegram 嘲諷）。憑證竊取範圍之廣——從 AWS IAM 到 Solana 驗證器金鑰對再到 WireGuard 配置——表明攻擊者以經濟利益為驅動，試圖從每次攻擊中最大化收益。

可能的AI輔助此憑證擷取器系統性地涵蓋了 15 個以上的類別，包括 Cardano 簽章金鑰、WireGuard 配置和 Kaniko Docker 憑證等特定目標，且其擷取方式與 AI 輔助枚舉相符。有效載荷迭代速度（三種不同加密方案的變體）、跨生態系統協調（5 天內涵蓋 5 個生態系統）以及運行安全措施（廠商仿冒域名、混合加密、偽裝成遙測數據的 systemd 持久化）表明，其吞吐量水平可能體現了 AI 輔助開發帶來的效率倍增效應。當然，這只是推測；熟練的操作人員即使不使用 AI 工具也能達到類似的規模。

新的戰術、技術和方法

1. 安全工具供應鏈投毒（T1195.002 變體）

攻擊者以攻破安全掃描器（例如 Trivy、KICS）為第一跳，進而攻擊下游目標，這是一種新的攻擊手段。攻擊者不僅攻破了一個函式庫，也攻破了組織用來執行安全操作的工具。 檢測 庫文件已被篡改。這就造成了一個盲點：本來應該捕捉惡意程式碼的掃描器本身卻成了惡意程式碼的傳播機制。

2。 蟒蛇 .pth 文件持久性 (T1546)

这 litellm_init.pth v1.82.8 版本中的技術尤其陰險。 Python .pth 在文件 site-packages/ 每次解釋器啟動時都會進行處理；任何以…開頭的行 import 以代碼形式執行。透過將有效載荷連結到單個 import 根據該聲明，攻擊者可以對所有 Python 進程執行程式碼，而不僅僅是在導入 litellm 時。這意味著即使 litellm 已安裝但從未使用，有效載荷仍然會執行，並且即使在修復程式取代了被入侵的 Python 進程後，它仍然有效。 .py 文件未進行檢查 .pth 文件。

3. 透過特權 Pod 部署實現 Kubernetes 叢集範圍內的橫向移動（T1610、T1611）

在每個叢集節點上自動建立特權 Pod—透過 hostPID, hostNetwork主機檔案系統掛載，以及 chroot 安裝持久性－將容器部署（T1610）與逃逸到主機（T1611）結合，將單一受損工作負載轉換為整個叢集受損。

4. 冒充供應商的C2基礎設施

使用 models.litellm.cloud （模仿 litellm）和 checkmarx.zone （模仿 Checkmarx）作為 C2/資料外洩端點，其設計目的是為了規避網路監控。安全營運中心 (SOC) 分析師在審查出站流量時，會看到看似合法的供應商網域的 HTTPS 連線。

5. 快速飛行中有效載荷迭代

發布 v1.82.7 版本時會在導入時執行攻擊，13 分鐘後發布 v1.82.8 版本時會在啟動時執行攻擊，這表示攻擊者在即時監控並調整攻擊策略。原始碼中保留的被註解掉的有效載荷變體（採用不同的加密方案）證實了攻擊者在攻擊期間一直在積極開發新版本。

有什麼可以做

這種攻擊利用了每一層的信任：對安全工具的信任、對軟體包註冊表的信任、對看似熟悉的網域的信任、對…的信任。 CI/CD 自動化。抵禦自動化需要加強以下每一個信任邊界：

面向包裝消費者

• 透過哈希值鎖定依賴項，而不僅僅是版本。 pip install litellm==1.82.6 --hash=sha256:... 即使被竄改的版本短暫以最新版本的形式出現，也能阻止其安裝。
• 使用鎖定檔案。 pip-compile, poetry.lock以及 uv.lock 取得確切的版本號碼和雜湊值。 CI/CD 應該從鎖定檔案安裝，而不是從浮動版本說明符安裝。
• 監控 .pth 文件。 定期審核 site-packages/ 對於意外的 .pth 檔案——它們在每次 Python 啟動時執行，是一種被低估的持久化機制。
• 實施出口網路控制。 撤離 models.litellm.cloud 以及 C2 輪詢 checkmarx.zone 在生產環境中，可以透過基於允許清單的出口過濾來捕獲此漏洞。

致軟體包維護者

• 置頂 CI/CD 行動 commit SHA，不是標籤。 LiteLLM的 pipeline 使用了 Trivy，但沒有使用固定版本。如果它引用了 aquasecurity/trivy-action@<commit-sha> 而不是 @latest否則，被竄改的行動就不會執行。
• 使用有效期短、作用範圍有限的發布令牌。 PyPI 支援可信任發布者（基於 OIDC）和作用域 API 令牌。外洩的數據 PYPI_PUBLISH 令牌不應該擁有長期、不受限制的發布權限。
• 在 PyPI 上啟用雙重認證。 要求所有維護人員啟用雙重認證，並儘可能使用硬體安全金鑰。
• 簽署包裹。 Sigstore/PEP 740 認證可讓消費者驗證軟體包是否由預期製造商製造。 CI/CD pipeline並非由使用被盜令牌的攻擊者所為。

適用於平台業者（PyPI、npm、GitHub）

• 檢測異常發布模式。 如果兩個新版本在 13 分鐘內發布，且來自與平時不同的 IP 位址或令牌，則在軟體包可安裝之前，應該會觸發暫緩審核或自動掃描。
• 加速採用可信賴發布商。 基於 OIDC 的發布機制將軟體包與特定的儲存庫和工作流程綁定，使得被盜的代幣在原始儲存庫之外毫無用處。 CI/CD 上下文。
• 實施發佈時惡意軟體掃描。 proxy_server.py 中的 base64 解碼有效載荷在發佈時可透過靜態分析檢測。

為了生態系統

• 將安全工具視為關鍵基礎設施。 Trivy 和 Checkmarx KICS 被數百萬用戶使用。 pipeline他們的 GitHub Actions 應該像他們掃描的軟體包一樣，進行簽署、鎖定和監控。
• 投資於運行時檢測。 僅靠靜態分析無法偵測到所有混淆技術。運行時監控軟體包安裝過程至關重要。 hooks意外的網路連線和可疑的檔案存取模式提供了縱深防禦。
• 更快地分享威脅情報。 如果跨廠商協調速度較快，litellm 的 5.5 小時暴露窗口期本來可以更短。 Xygeni MEW、Socket 和 Snyk 等自動化掃描服務檢測到了異常情況——瓶頸在於人工確認和註冊機構的回應時間。

結語

TeamPCP運動是一個具有里程碑意義的時刻 software supply chain security攻擊者首先攻破安全掃描器，並將其作為通往高價值人工智慧基礎設施的跳板，這表明供應鏈的強度取決於其最薄弱的傳遞依賴項，而這個依賴項可能就是你信任的、能夠保護你安全的工具。

Litellm 漏洞尤其凸顯了人工智慧基礎設施面臨的日益增長的風險。隨著 LLM 代理網關變得越來越重要， standard 模式 enterprise 在人工智慧部署中，他們將API金鑰、雲端憑證和敏感資料的存取權限集中在一個元件中。攻破該組件就等於獲得了打開整個人工智慧堆疊的萬能鑰匙。

在 5.5 小時窗口期內安裝了 litellm 1.82.7 或 1.82.8 的組織應將此視為憑證完全洩漏：輪換受影響系統上的所有金鑰，並對 Kubernetes 叢集進行審計。 node-setup-* 豆莢 kube-system刪除任何 sysmon.service systemd 單元，並檢查 litellm_init.pth 在 Python 中 site-packages/ 目錄。官方 Docker 映像的使用者（ghcr.io/berriai/litellm由於影像固定了其依賴項，並且在曝光視窗期間沒有重建，因此不受影響。