PyPI 上的 LiteLLM 遭到 TeamPCP 攻擊：深入剖析竊取憑證的惡意軟體活動

首页 » 蟒蛇 » PyPI 上的 LiteLLM 遭到 TeamPCP 攻擊：深入剖析竊取憑證的惡意軟體活動

2026年3月24日，一個廣受歡迎的Python包在幾個小時內悄悄變成了一個強大的憑證竊取工具。 LiteLLM（一個被廣泛用作…的庫）的兩個惡意版本被發布，導致該庫遭受攻擊。 大型語言模型（LLM）的統一介面這些漏洞被上傳到 PyPI，短暫地使大量系統暴露於複雜的供應鏈攻擊之下。

惡意版本 1.82.7和1.82.8該攻擊活動捆綁了一個多階段有效載荷，能夠從開發者機器、CI/CD 運行器、雲端基礎設施和 Kubernetes 叢集中竊取金鑰，然後將其洩漏到攻擊者控制的伺服器。 與 TeamPCP 威脅組織有關聯該病毒已持續數月攻擊 Trivy、Checkmarx 工具和 Docker 映像， 對 npm 供應鏈的攻擊 現在還有 PyPI 生態系。

LiteLLM是什麼？為什麼它會成為主要攻擊目標？

LiteLLM 是一個 開源 Python 函式庫和代理伺服器 它充當LLM API的通用適配器。它允許應用程式透過單一的、OpenAI風格的API與一百多種不同的模型進行通信，這些模型來自OpenAI、Anthropic、Google、AWS Bedrock、Vertex AI等供應商。

由於這一角色，該項目已深深融入人工智慧生態系統。多家安全廠商的報告顯示，LiteLLM 約… 每日下載量達 3 萬至 3.4 萬次一些遙測數據表明它存在於大約 36% 的受監控雲端環境對於攻擊者而言，攻破具有這種特徵的軟體包，意味著他們有機會透過一次行動來獲取大量敏感資料和憑證，這是一個難得的機會。

根據設計，LiteLLM 通常直接位於兩者之間 應用程式和多個人工智慧服務提供商這意味著它需要定期處理存取外部LLM端點所需的API金鑰、環境變數、設定檔和其他敏感資訊。這種依賴項中的後門程式可以悄無聲息地攔截並竊取這些值，而無需直接入侵上游平臺本身。

這次事件也凸顯了現代開發流程的複雜性：本地工作站、CI/CD 管線、Kubernetes 叢集和雲端帳戶都透過共享金鑰和自動化流程緊密相連。 該圖中的依賴關係受損 最終可能導致組織架構中許多層的憑證暴露，從而將影響力遠遠擴大到單一主機之外。

惡意 LiteLLM 版本是如何引入的

中毒釋放 LiteLLM 1.82.7 和 1.82.8 大約在2026年3月24日上午被推送到PyPI。 08：30 UTC它們在被 PyPI 安全團隊隔離並被第三方防禦系統屏蔽之前，仍然可用近兩個小時，據報道，移除工作大約在 [時間] 左右完成。 11：25 UTC.

此案引人注目之處在於… 後門並未出現在對應的 GitHub 原始碼中。Endor Labs 和其他研究人員發現，惡意邏輯被注入到 PyPI 上分發的已建置 wheel 檔案中，而不是注入到公共儲存庫中，這表明入侵發生在建置/發布過程中或之後，而不是透過可見的程式碼提交。

具體而言，分析師觀察到該文件 litellm/proxy/proxy_server.py 包含一個嵌入式 base64 編碼的有效載荷，該有效載荷是 在 GitHub 提交的同一文件中缺失大約有十幾行程式碼被插入到原本合法的程式碼區塊之間（例如，在定義附近）。 REALTIME_REQUEST_SCOPE_TEMPLATE 和 showwarning （函數）。每當模組被導入時，這些額外的程式碼行都會靜默地解碼並執行一個隱藏的腳本。

在版本中 1.82.8攻擊者更進一步，投放了一個 .pth 文件名為 litellm_init.pth 進入 Python 環境。因為 Python 會處理所有 .pth 在解釋器啟動時執行文件，這確保了有效載荷能夠運行。 每次 Python 呼叫即使 LiteLLM 本身從未被應用程式導入。

這項升級導致 1.82.8 明顯更危險任何在安裝了被入侵軟體包的環境中啟動的 Python 腳本、測試運行器、建置工具或自動化程式都會在後台悄悄觸發竊取憑證的邏輯。

與更廣泛的TeamPCP活動建立聯繫

LiteLLM漏洞並非孤立發生。 Sonatype、Wiz、Endor Labs和其他機構的調查將其與…聯繫起來。 TeamPCP 正在進行的供應鏈活動該組織於 2025 年底引起關注，此後一直以一系列開源專案和開發者生態系統為目標。

3月初，同樣的幾位演員就被牽涉到後門入侵事件。 Aqua Security 的 Trivy 漏洞掃描器和相關的 GitHub Actions，以及 Checkmarx 工具的惡意變種，包括 韓國科學技術協會GitHub Actions 和 OpenVSX 擴充功能。該活動還涉及 npm 套件、Docker Hub 映像和 Kubernetes 環境，經常重複使用基礎設施、加密方案和持久化元件。

追溯 LiteLLM 事件，維護人員透露： PyPI 發布令牌 儲存在 LiteLLM GitHub 程式碼庫中的環境變數被透過被攻破的 Trivy 工作流程竊取。該令牌隨後被濫用。 發布被污染的 PyPI 版本這使得攻擊者能夠繞過用戶帳戶的雙重保護，並在不更改公共原始程式碼的情況下注入惡意 wheel 檔案。

研究人員還指出，在與 LiteLLM 相關的程式碼庫中，3 月 23 日前後出現了可疑的提交和工作流程，其中包括一個短暫存在的分支和一個 GitHub Actions 工作流程，該工作流程攜帶了一個在其他 TeamPCP 有效載荷中也出現的熟悉的 RSA 公鑰。工作流程運行的遙測資料表明，這些 CI 運行器可存取的金鑰可能已被存取和竊取。

在歷起事件中，該組織都表現出一致的模式： 在一個環境中竊取憑證，然後轉移到下一個生態系統。在這種情況下，Trivy 的 GitHub Actions 配置錯誤導致特權令牌被盜；該令牌導致惡意 Trivy 版本和 Docker 映像被發布；這些惡意版本和映像反過來又導致 Checkmarx 工具和最終 LiteLLM PyPI 套件遭到破壞。

LiteLLM惡意軟體的運作方式

多家供應商的分析都將 LiteLLM 後門描述為 多階段、base64 混淆的 Python 有效載荷 設計上兼具隱蔽、彈性和彈性。其邏輯大致分為三層，每一層都處理攻擊的不同階段。

在第一層中，注入的程式碼 proxy_server.py 或者 litellm_init.pth 文件 解碼並啟動一個隱藏的協調器與其使用容易被標記的函數，例如 exec()該腳本依靠子進程調用和標準庫功能來運行解碼後的有效載荷並捕獲其輸出，從而幫助其融入正常的應用程式行為。

此協調器運作後，會收集後續階段的輸出， 使用 AES-256-CBC 對收集的資料進行加密 然後使用程式碼中硬編碼的 RSA 公鑰對 AES 會話金鑰本身進行加密。加密後的資料塊和金鑰被打包到一個名為 的歸檔檔案中。 tpcp.tar.gz與 TeamPCP 的其他行動類似，並做好了撤離準備。

第二層負責 積極的系統偵察和憑證竊取它會列舉主機名稱、使用者和網路資訊以及環境變量，然後掃描一長串路徑和設定文件，尋找敏感資訊。目標包括：

• SSH金鑰和設定檔 （客戶端和伺服器）
• 雲端憑證 適用於 AWS、GCP 和 Azure，包括元資料派生令牌
• Kubernetes kubeconfig 文件服務帳戶令牌和叢集金鑰
• 環境文件 如 .env 常用於儲存 API 金鑰的變體
• CI/CD 配置密鑰和存取令牌
• Terraform、Helm 和其他 IaC 或部署工件
• 資料庫連接字串 和設定檔
• TLS/SSL 私鑰 以及鑑定材料
• 加密貨幣錢包 及相關數據

在某些情況下，竊賊並不會止步於收割。它會嘗試… 主動使用已發現的憑證例如，透過查詢雲端提供者 API、拉取 Kubernetes 金鑰或探索可達資源，增加橫向移動和後續入侵的可能性。

第三層提供 持久性和遠端控制它將 Python 腳本寫入磁碟（通常表現為 sysmon.py並將其註冊為長期運作的服務，通常偽裝成諸如「系統遙測服務」之類的良性服務。該服務會定期（通常每 50 分鐘一次）聯繫攻擊者的基礎設施，以獲取額外的命令或有效載荷。

研究人員注意到這裡存在一些奇怪的行為：當某些安全廠商試圖從命令與控制端點獲取有效載荷時，伺服器返回了一個指向歌曲“Bad Apple!!”重製版的鏈接，顯然是為了… 針對自動化分析的轉移策略然而，在受感染的系統中，同樣的機制可以隨著時間的推移而悄悄地提供新的功能。

資料外洩管道和攻擊者基礎設施

在 LiteLLM 事件中，分析人員觀察到至少與兩個主要攻擊者控制的領域存在通訊： modelslitellmcloud 以及 checkmarxzone這些與早期 TeamPCP 活動中使用的基礎設施一致，並發揮不同的作用。

加密存檔 tpcp.tar.gz 通常是 已上傳至 models.litellmcloud這使得操作人員能夠從數千個下游環境中檢索被盜憑證。在某些變體中，不同的子路徑 checkmarxzone （例如， checkmarxzone/raw or .../vsx) 用於傳遞持久化腳本或其他階段。

在被入侵的系統中，防禦者報告了一系列反覆出現的問題 妥協指標（IoC） 與 LiteLLM 惡意軟體相關：

• 檔案的存在 tpcp.tar.gz 在暫存目錄或工作目錄中
• 臨時文件，例如 /tmp/pglog 以及 /tmp/.pg_state
• 與 Python 腳本和配置路徑相關的 sysmon.py 以及一個相符的服務檔案（通常位於使用者或 systemd 設定目錄下）
• 意外 litellm_init.pth Python 1.82.8 版本 site-packages 中的文件
• 指向的出站流量或 DNS 查詢 modelslitellmcloud or checkmarxzone

惡意邏輯被追溯到以下文件： proxy_server.py （LiteLLM 1.82.7 和 1.82.8） litellm_init.pth （1.82.8）安全廠商已對雜湊值和其他 IoC 進行分類，並隨著更多取證細節的出現而繼續更新其安全公告。

對人工智慧、雲端運算和持續整合/持續交付 (CI/CD) 環境的影響

因為 LiteLLM 在以下方面被大量使用： 人工智慧驅動的應用與服務然而，這種妥協的實際影響範圍遠不止於簡單的軟體包消費者。在雲端環境中，如果 LiteLLM 作為 LLM 提供者的網關，則很可能在相同執行時間或配置空間中存在共存的金鑰。

Wiz和其他觀察者估計LiteLLM大約出現在 三分之一的觀測雲環境這凸顯了此事件的潛在影響範圍。 BleepingComputer 引述的一些消息來源表明，資料外洩事件的數量可能高達數十萬起，但確切數字仍有待獨立證實。

值得注意的是，該惡意軟體強調 Kubernetes知覺行為在許多分析中，有效載荷試圖在叢集中的所有節點上部署特權 Pod，然後利用這些 Pod 存取金鑰和設定物件。在與 TeamPCP 相關的其他行動中，研究人員發現 Kubernetes 叢集遭到腳本攻擊，這些腳本會在環境看似位於伊朗時擦除節點，同時在其他地方安裝後門（例如所謂的 CanisterWorm）。

對 CI/CD 工具的關注同樣顯而易見。攻擊者透過攻破 Trivy GitHub Actions、Checkmarx VS Code 擴充功能和 GitHub Actions，以及現在的 LiteLLM，獲得了攻擊入口點。 自動化已經擁有廣泛的權限 這種方法會洩漏程式碼庫、建置工件和部署憑證。它將原本面向安全的工具變成了更大範圍攻擊的跳板。

聯邦調查局官員和產業研究人員警告說， 手中掌握大量被盜憑證因此，可以合理預期，在 LiteLLM 首次披露後的幾週和幾個月內，會出現更多的違規通知、二次入侵和勒索企圖。

檢測、遏制和補救步驟

對於可能已經提取或執行過 LiteLLM 版本的組織 1.82.7或1.82.8 來自 PyPI 的資訊顯示，安全廠商和 PyPI 維護者的指導非常明確： 將受影響的系統視為已受損系統。僅僅卸載軟體包並不能移除持久化機制，也無法撤銷可能已經發生的任何憑證盜竊。

建議立即採取的行動包括：

• 識別所有已安裝的裝置 在開發人員機器、CI/CD 運行器、容器和生產環境中部署 LiteLLM 1.82.7 或 1.82.8。
• 刪除惡意版本 並將 LiteLLM 固定到已知的良好版本（截至報告時，1.82.6 被廣泛認為是最後一個乾淨的版本）。
• 輪換所有憑證 受影響環境中可存取的內容：SSH 金鑰、雲端提供者金鑰和令牌、Kubernetes 金鑰、CI/CD 金鑰、資料庫憑證、TLS 金鑰以及任何錢包或支付相關金鑰。
• 搜尋持久化工件如 sysmon.py可疑的 systemd 服務定義，以及位於以下位置的異常文件 ~/.config 或像暫存目錄 /tmp/pglog 以及 /tmp/.pg_state.
• 檢查 Kubernetes 集群 對於意外的特權 Pod，尤其是在命名空間中，例如 kube-system以及不尋常的服務帳戶或角色綁定。
• 監控出站連接 以及針對已知攻擊者網域的 DNS 查詢，例如 models.litellmcloud 以及 checkmarxzone.

在後門可能已持續運行相當長一段時間的環境中，許多專家建議： 基於可靠基線進行完全重建 這可能是最安全的途徑，尤其對於關鍵基礎設施而言。考慮到惡意軟體的特性，僅僅移除 LiteLLM 軟體套件並不能排除被惡意篡改或植入其他有效載荷的可能性。

各組織也被鼓勵採取更強有力的措施 依賴性管理和供應鏈防禦：鎖定到特定的、經過驗證的版本，啟用在攝入時阻止或標記已知惡意軟體包的工具，並整合自動化行為分析，以檢測建置和測試期間的意外網路或檔案系統活動。

LiteLLM案例對人工智慧軟體供應鏈的啟示

LiteLLM事件凸顯了近年來逐漸形成的一個更廣泛的趨勢： 人工智慧和雲端堆疊中的高槓桿組件正成為主要目標 對於供應鏈攻擊者而言，威脅行為者不再直接攻擊終端用戶應用程序，而是越來越多地尋找工具鏈中的關鍵節點，透過攻破單個庫或插件，就能獲得對眾多下游組織的存取權限。

像 LiteLLM 這樣的軟體包實際上處於一個 秘密的咽喉要道它們負責協調與人工智慧提供者的調用，影響持續整合/持續交付 (CI/CD) 和基礎設施自動化系統，並且通常擁有更高的權限。隨著越來越多的企業爭相使用開源工具整合生命週期管理 (LLM) 功能，此類元件的價值——以及對其進行後門攻擊的動機——只會與日俱增。

同時，此次攻擊也凸顯了建置和發布流程防禦所面臨的挑戰。據稱，攻擊者利用 Trivy 工作流程配置錯誤竊取了一個令牌，然後使用該令牌將受污染的軟體包推送到 PyPI，而公共原始碼樹表面上保持乾淨。 版本標籤和建置步驟也成為了攻擊面的一部分。利用了許多管線依賴標籤而不是固定提交這一事實，並且可能隱式地信任來自熟悉的維護者的工件。

像 Sonatype、Wiz 和 Endor Labs 這樣的供應商強調了以下方面的重要性： 自動化、即時安全保障 即使軟體包元資料和儲存庫歷史記錄看起來合法，它也能發現異常行為，例如以前未曾見過的網路目標或加密資料外洩。儲存庫防火牆、威脅情報驅動的掃描器和依賴關係情境分析正日益被視為必不可少的層級，而非可有可無的附加功能。

對於維護者和組織而言，LiteLLM 的妥協方案提醒我們： 金鑰管理、CI/CD 強化和憑證輪換 供應鏈安全的基礎在於憑證輪換的不完整或非原子性，這些漏洞使得 TeamPCP 能夠在數週後重新利用這些漏洞，這表明事件回應中的一個失誤如何在整個生態系統中引發連鎖反應。

席捲 LiteLLM 的運動始於一個看似有限的工作流程問題，但隨後蔓延至 GitHub Actions、Docker Hub 等多個平台。 Shai-Hulud npm 事件OpenVSX 和 PyPI。由於後門隱藏在廣受信任的工具和 AI 連接器中，被盜憑證流入攻擊者的基礎設施，這一事件凸顯了軟體供應鏈如何迅速成為一個極具吸引力且高效的攻擊面。