Google 的 Mandiant 與威脅情報團隊(GTIG)在 11 月 3 日發表〈The Rise of LLMJacking〉,指出攻擊者盜用企業的雲端憑證與 LLM 存取權,把推論費用轉嫁給受害者,單日詐欺費用可超過 10 萬美元,部分組織累計達 100 萬美元才被撤銷。昨日(robots.txt 訓練拒絕訊號)談內容取用規則,今天轉到模型存取被盜用的攻防。
讀到的程度:我讀到 Google 官方部落格全文(圖片只讀得到說明文字,看不到圖內細節)與 SiliconANGLE 的報導;兩者數字一致。完整 IOC 清單需註冊 VirusTotal,我沒有看到。
📖 學
一、LLMjacking 是什麼
依 Google 報告,LLMjacking 是劫持企業對大型語言模型服務的存取權,讓攻擊者用受害者的帳單跑推論。它與 cryptojacking 的差別在於速度:挖礦是慢慢吃掉算力,LLM 的計費以 token 為單位,費用可在數小時內暴增。Mandiant 說處理了 2026 年的多起事件,受害者分布在北美、南美與亞太,產業涵蓋金融、零售、科技與運輸。
二、入口:多半是憑證,不是模型漏洞
報告把主要入口歸為外洩或被盜的雲端身分憑證,包括 IAM 憑證、服務帳號金鑰、GitHub 個人存取權杖與 session token。其他途徑有對外開放的 LLM 端點(報告舉 Ollama 的 /api/create 為例),以及從公開 GitHub 儲存庫撈出的 API 金鑰。一個具體案例是名為 UNC6993 的叢集:先利用設定錯誤的服務帳號金鑰進入雲端執行個體,又架了假註冊頁,誘使訪客把含有效存取權杖的原始 JSON 貼回來,藉此繞過密碼與 MFA,之後建立新的 API 金鑰、啟用額外服務,費用推過 10 萬美元。
三、變現:先驗金鑰、再轉賣
攻擊者拿到金鑰後,會先用 max_tokens=1 的請求驗證金鑰是否有效,這種請求量小,不容易觸發以流量為基準的警報。接著有幾種做法:在受害者帳號啟用託管的生成式 AI 服務(有些受害者從未啟用過任何 LLM 服務)、訂閱隨用隨付方案、建立「用完即丟」的短命服務帳號輪替以躲開速率限制,或要求提高配額、佈建 GPU。
報告也描述一個轉售生態,稱為 LLM Mixers:用開源閘道(報告點名 new-api 與 gcli2api)與自製中繼,把被盜金鑰集中成池、計量用量、隱藏請求來源。其中 Jet Night 這項 token 路由服務,在不到八小時內被用來發出超過 50 萬次 API 呼叫,一名受害者被轉嫁近 100 萬美元。它的無限量方案約每月 60 美元,而同類消費級方案要 100 到 250 美元,GTIG 據此推斷其成本靠偷來的金鑰支撐;服務曾公告中斷,報告認為多半是受害者撤銷了金鑰。這個價差推論是 GTIG 的判斷,不是帳務證據。
四、閘道本身也成了弱點
報告提到一組後續活動,取得預先驗證過的虛擬金鑰後,利用 LiteLLM 金鑰重新產生端點(/key/regenerate)的使用者 ID 重綁定缺陷,編號 CVE-2026-40217,把一般虛擬金鑰升級成 PROXY_ADMIN 主控憑證。另有名為 D1337-KAIROS 的角色,在逆向代理後面重新包裝多個前緣模型,並部署基於 Manus agent 框架的容器化後門:讓上游模型推理出指令,再在被入侵的主機上執行。這代表 LLM 閘道(多模型、金鑰集中管理的中介層)本身是高價值目標。
五、防禦建議與偵測點
報告的建議偏向基本功:集中式密鑰管理、自動輪替與儲存庫密鑰掃描;最小權限,預設拒絕包括 LLM 服務在內的所有未明確需要的權限;抗釣魚 MFA;API 金鑰依模型與環境切分並設用量上限;花費上限、各模型配額與預算警報;及時修補 LiteLLM 這類閘道;限制對外連線;把「未經授權啟用 LLM 服務」視為重大資安事件。
偵測面按雲別列出具體事件名稱,可直接拿來寫告警規則:
| 雲端 | 要盯的事件 | 提醒 |
|---|---|---|
| AWS | Bedrock 的 InvokeModel、Converse、InvokeModelWithResponseStream;ListFoundationModels、PutUseCaseForModelAccess(偵察與解鎖);非 IaC 的 Model Invocation Logging 設定變更 | 後者報告列為高嚴重度 |
| Azure | Microsoft.CognitiveServices/accounts/deployments/write;診斷設定被改 | 資料平面呼叫需開診斷日誌 |
| GCP | EnableService(AI 平台服務);aiplatform.googleapis.com 的 Predict、GenerateContent | Data Access 日誌預設關閉,要手動開 |
六、我的判讀
GTIG 預期 LLMjacking 會逐步取代 cryptojacking,理由是變現快、毛利高、轉售市場成熟,這是對未來的預測,不是已發生的統計。從報告細節看,實際防線多半不是「保護模型」,而是身分與憑證管理加上成本護欄;尤其「從未啟用 LLM 的帳號被人啟用」這點,代表即使組織沒用 AI,也該把這些 API 預設鎖住。報告的受害數量與損失分布沒有給出總樣本數,我無法判斷這些案例有多典型。
🧠 記
- LLMjacking 是用受害者的帳單跑推論;費用數小時內暴增,單日超過 10 萬美元、累計達 100 萬美元(GTIG 自報案例)。
- 入口以被盜或外洩的雲端憑證為主,不是模型漏洞;金鑰驗證用
max_tokens=1請求躲警報。 - 變現靠 LLM Mixers 轉售;LiteLLM 的 CVE-2026-40217 讓一般虛擬金鑰升為管理員。
- 防線:最小權限(含鎖住未使用的 LLM 服務)、金鑰切分、花費上限、盯「啟用服務」事件。
✍️ 實踐
- 檢查自己雲端帳號(AWS、GCP、Azure 任一)是否設有預算警報與 AI 服務的用量配額;沒有就設一個。
- 搜尋自己的儲存庫歷史與
.env檔,看是否有 API 金鑰或 GitHub 權杖被提交過,有就視為已外洩並輪替。 - 若使用 LiteLLM 或類似閘道,確認版本已修補 CVE-2026-40217,並列出誰持有哪些虛擬金鑰。
- 在日誌平台寫一條規則:AI 平台服務被啟用、或單一金鑰出現大量
max_tokens=1的請求就告警(GCP 要先手動開 Data Access 日誌)。
🔗 延伸學習
- Google Cloud 部落格:The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources:事件主要來源,讀到全文(圖片除外)。
- SiliconANGLE:Google finds ‘LLMjacking’ attackers running up $100K a day in fraudulent cloud charges:二手報導,讀到全文。
💬 問 AI
我讀到 Google GTIG/Mandiant 2026-11 發表〈The Rise of LLMJacking〉:攻擊者盜用雲端憑證與 LLM 存取權,先用 max_tokens=1 請求驗證金鑰,再啟用 Bedrock、Gemini API 等服務、轉售給 LLM Mixers;單日費用超過 10 萬美元,LiteLLM 的 CVE-2026-40217 可把虛擬金鑰升為 PROXY_ADMIN。
請幫我:
1. 比較 LLMjacking 與 cryptojacking 在入侵路徑、損失速度與偵測難度上的差異。
2. 為一個小型團隊設計最低成本的防護清單(預算警報、金鑰切分、日誌告警),並排出優先順序。
3. 說明為什麼「抗釣魚 MFA」仍可能被 session token 貼回的假頁面繞過,以及該怎麼補。
回答時請標示哪些是報告原文說的、哪些可查證、哪些是你的推論。