部落格 發布於 AIA: 2026年7月2日

暴露的 LLM 後端，正被攻擊者拿來當免費 AI 運算資源

Zenity 的 honeypot（誘捕式偵測環境）觀察到，有攻擊者把自主 agent（可自行規劃並呼叫工具的 AI 程式）和 LLM client（呼叫大語言模型的用戶端）直接指向暴露在外的 Ollama、LiteLLM 模型後端。這不一定需要惡意程式或主機入侵；只要模型服務連得到、沒有驗證，或只靠測試用的預設 API key 保護，就足以讓它變成攻擊者不用付錢的推理資源。

Authentication BypassAI Deployment SecurityRuntime IsolationAgentic AIAI Infrastructure
8 項對應的 AIDEFEND 防禦手法
來源: Bring Your Own Agent: Hijacking Exposed AI Backends to Power Offensive Operations 
作者: Ayush RoyChowdhury & Avishai Efrat
原文發布: 2026年6月30日 下午1:43

威脅分析

  • 這條攻擊路徑的起點不是複雜的提示詞注入（Prompt Injection）攻擊，而是暴露在網路上的服務。 攻擊者找到可以從網路連到的 Ollama /api/generate 或 /api/chat 端點，常見開在 11434 連接埠；也找到 LiteLLM 開在 4000 連接埠上的 /v1/responses proxy（代理服務，負責轉接模型請求）。
  • 真正的風險來自沒有適當的存取控制。 Ollama 的預設 API 介面沒有內建驗證；LiteLLM 也只有在正確設定 master key 後，才會啟用 proxy 層的驗證。如果部署時允許空白 key，或接受像 sk-1234 這種測試用的預設 API key，只要連得上服務的人，就能消耗組織的 token 和運算資源。
  • agent 的任務內容其實都在 request body（請求內容）裡。 Zenity 看到 Strix、HexStrike AI，以及客製過的 Codex 風格 agent，把系統提示詞（system prompt，模型執行任務時遵守的內部指令）、工具定義和任務內容送進暴露的後端。後端看似只是模型引擎，但它仍然在替攻擊者的自動化迴圈提供推理能力。
  • 這讓自架 AI 的風險模型變了。 暴露的模型端點不只是資料外洩或帳單爆量問題；它也可能被攻擊者拿來當成自動化攻擊工具背後的 AI 大腦，用你的模型資源去支援對第三方目標的攻擊。
  • 這裡的修法是部署方自己做得到的。 模型後端應該只綁在私有介面，要求真正的服務驗證，對每個呼叫者計量用量，記錄看起來像 agent 任務的請求內容，並在低信任或高消耗的工作階段（session）觸發時自動切斷。

適用的 8 項 AIDEFEND 防禦手法

AID-H-004.002
Service & API Authentication
極高
最直接的阻斷點是在推理開始前。Ollama 和 LiteLLM 後端應該要求真正的服務或管理者身分，例如受管理的 API key（用來驗證服務呼叫的金鑰），或 OAuth 這類服務憑證。測試用 key 或未設定 master key，都不應該成為正式環境存取模型運算的入口。
AID-I-002.001
Internal AI Network Segmentation
極高
模型服務連接埠不應該直接暴露在公網。把 Ollama 和 LiteLLM 放在私有網段，只允許流量從 gateway（閘道）進來，並用最小權限 firewall rule（防火牆規則）控制來源，可以直接把網路掃描者擋在模型 API 外面。
AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
高
這類事件正是安全基準檢查要擋下來的東西：模型伺服器綁在 0.0.0.0 或公網介面、允許任意外部來源連到推理 API、缺少驗證，或使用預設 key。只要部署檢查發現這些問題，就不應該讓這套 AI 基礎設施上線。
AID-D-005.001
AI System Log Generation & Collection
高
證據通常就在 request body（請求內容）裡：agent 系統提示詞、工具結構、模型名稱、caller header（呼叫者標頭），以及從小型 probe（探測請求）一路變成完整任務請求的過程。結構化、已遮蔽機敏資料的 AI 請求紀錄（request log），才能把這種流量和一般推理使用區分開來。
AID-D-005.007
Token, Tool-Use, Request-Parameter & Cost Spike Detection & Alerting
高
攻擊者控制的 agent 會留下資源訊號：token 用量異常、重試次數暴增、超長 context（上下文）、帶有工具呼叫結構的請求，以及按呼叫者身分拆分後的費用暴增。這些訊號應該在組織繼續替攻擊迴圈付錢前就先觸發警示。
AID-D-005.009
AI-Service C2 & Abuse-Channel Detection
高
這是本篇更精準的偵測層。防守方不只要看 token 用量或成本暴增，也要偵測 AI 服務流量裡是否出現 agent system prompt、tool schema、攻擊框架名稱、異常的 payload 形狀或熵值，並把 API key、gateway、身分、端點和 proxy 記錄串起來看。
AID-I-003
Quarantine & Throttling of AI Interactions
高
偵測之後要能把狀況收住。依預算觸發的節流（降低或限制請求量）、安全模式、來源封鎖和 key 停用，可以在濫用訊號超過政策門檻後，阻止暴露的後端繼續提供運算資源。
AID-E-004
Post-Eviction System Patching & Hardening
中
發現被濫用後，團隊要關閉的是那條實際不安全路徑：改成只在私有網路介面監聽、補上驗證、停用測試用 key、限制網路可達性、把新的偵測規則寫進去，並重跑原本的 request pattern（原始請求模式），證明它已經打不進來。

身為資安防禦者，我們應該這麼做

  • 盤點所有自架 Ollama、LiteLLM、vLLM、TGI、LM Studio，以及 OpenAI-compatible proxy（相容 OpenAI API 格式的代理服務）端點。記錄 bind address（服務監聽位址）、公網可達性、驗證模式、負責人、模型清單和所在網段。
  • 把模型後端移到私有介面或有驗證的 gateway（閘道）後面。即使只是測試，也不要讓後端推理服務連接埠直接暴露在網際網路上。
  • 在部署檢查裡拒絕測試用憑證和未設定 master key。像 sk-1234、空白 key、無驗證 proxy 模式，都應該視為正式環境的阻擋項目。
  • 針對大型 request body（請求內容）、帶有工具呼叫結構的 agent 請求、攻擊框架名稱、反覆重試、異常 user agent，以及按呼叫者身分拆分後的 token 用量或費用暴增建立 log 和警示。
  • 加上自動處置機制：對低信任呼叫者節流、停用可疑 key、封鎖濫用來源 IP，並在 token 或成本預算被打穿時切到安全模式。

結論

這起事件的重點，不是每一台暴露後端都已經被完整入侵。更精準的教訓是：模型服務能力本身，已經是攻擊者想借用的基礎設施。只要 LLM 後端少了強身分驗證、預算控管、請求紀錄和私有網路邊界，它就可能變成別人的 AI 運算層（替攻擊者跑模型推理的資源）。