實際事件發布於 AIA: 2026年9月15日

攻擊工具已經摸熟 AI 系統內部：Wiz 九十天蜜罐遙測看到的手法

資安公司 Wiz 的威脅研究團隊架設了一批蜜罐（刻意曝露、用來誘捕並記錄攻擊行為的假系統），模擬 LiteLLM、Flowise、LangChain、Langflow、ChromaDB、Ollama 等服務，連續觀察九十天。除了一般的漏洞利用之外，這批流量還顯示攻擊工具是專門針對 AI 產品內部構造寫的：把提示詞（prompt）注入 agent 框架，誘導它執行作業系統命令，再靠一次 DNS 查詢回呼來確認命令真的跑了，而不是等畫面上出現輸出；直接從執行中的程序記憶體讀出代理服務的憑證，而不是去翻硬碟上的檔案；以及把挖礦程式藏在以 AI 工具命名的目錄裡。

Prompt InjectionCredential TheftAI Deployment SecurityAI InfrastructureAgentic AI

7 項對應的 AIDEFEND 防禦手法

來源: Inside 90 days of attacks on AI infrastructure

作者: Yaara Shriki, Wiz Threat Research

原文發布: 2026年8月27日

威脅分析

注入攻擊瞄準的是 shell，不是回答內容。 針對 LangChain、Flowise、OpenWebUI 與 Node-RED，攻擊者送出的提示詞目的就是讓 agent 去執行作業系統命令。命令有沒有成功執行，是靠 agent 對攻擊者控制的網域發出一次 DNS 查詢來確認，而受害主機的位址就編碼在子網域名稱裡，所以回應內容裡完全不需要出現任何執行結果。第二階段的內容則從 Pastebin 抓取，並經過 Base64 編碼，讓惡意內容不會直接留在應用程式記錄裡，也能避開只看關鍵字的提示詞過濾。
取得權限之後的手法，是針對產品量身打造的。 在 LiteLLM 上，攻擊者沒有去硬碟裡找憑證檔案，而是直接匯入執行中應用程式自己的 Python 模組，從模組狀態把 master key 讀出來，因為這個值只存在於記憶體、根本不落在磁碟上。他們也逐一檢查已知的設定檔路徑，並用官方文件裡的預設 key 去辨識後端接的是哪一家模型。
挖礦程式偽裝成 AI 工具的檔案。 其中一個 Langflow 案例，把挖礦程式放進 .claude 目錄並改名為 unicorn；Node-RED 的案例則刻意選了一條能混進 Node.js 程序樹的路徑。
證據界線。 這些都是蜜罐，報告沒有公布事件數量、觀察起訖日期，也沒有具名的受害組織。Wiz 也明講，文中那段注入用的提示詞是他們「重建」出來的示意內容，不是實際攔截到的流量；真正觀察到的是程序樹、DNS 回呼，以及最後被放上去的挖礦程式。

適用的 7 項 AIDEFEND 防禦手法

AID-M-001.005

Public AI Endpoint & Agent-Service Exposure Discovery

極高

Wiz 點名 Marimo、Flowise、Langflow、Ollama、ChromaDB 與 Milvus 這些工具預設都不需要身分驗證，並主張只要是不需驗證又能從網際網路連到的服務，就該直接當成已經被入侵。要把這個主張變成可以排程處理的工作清單，做法是用不帶企業憑證的外部連線掃描自家曝露面，再把每一個有回應的 AI 路徑，逐一對應到負責人與核准過的曝露狀態。

AID-H-017.002

Least-Privilege Tool Architecture

極高

這批遙測裡的每一次注入，前提都是 agent 手上握有一個通用的 shell 工具。只提供範圍明確、型別固定、單一用途的工具，並且除非有另一套獨立隔離的控制明確放行，否則一律不開放通用命令執行，夾帶進來的指令就沒有東西可以呼叫；勝負在提示詞過濾介入之前就已經決定。

AID-I-001.004

Sandbox Network Egress Restrictions

極高

攻擊者有兩個環節需要對外連線：一次是用來證明命令確實執行的 DNS 回呼，另一次是去 Pastebin 取回第二階段內容。在 agent 執行環境之外強制執行預設拒絕的目的位址政策，等於一次拿掉確認訊號和酬載下載這兩件事；這也是為什麼就算注入本身成功了，這項控制依然有效。

AID-H-004.002

Service & API Authentication

高

這些服務有好幾套把身分驗證當成「可選設定」，而不是「啟動的前提條件」。在閘道或服務邊界要求通過驗證的工作負載身分，請求才能進到模型或 agent 的處理程式，就能直接消除這批流量正在到處尋找的那一群不需驗證的目標。

AID-D-005.003

Proactive AI Threat Hunting

高

一個藏在 .claude 目錄裡、名字叫 unicorn 的挖礦程式，不會觸發那些針對常見惡意程式路徑寫的規則。要事後把這種偽裝找出來，得靠以假設為起點的主動獵捕：在 AI 主機的遙測資料裡，尋找出現在 AI 工具目錄下的非預期執行檔，以及推理服務或 agent 程序去啟動 shell 的情況。

AID-D-005.007

Token, Tool-Use, Request-Parameter & Cost Spike Detection & Alerting

高

被偷走的供應商 API key，變現方式是拿受害者的帳單去跑推理，所以這類濫用浮現的形式是用量，而不是一則入侵警示。依呼叫者身分分別建立 token 用量與供應商費用的基準線，再對明顯偏離的情況發出警示，就算金鑰被偷的當下沒有在檔案系統留下任何痕跡，仍然有訊號可以抓。

AID-H-002.002

Inference-Time Prompt & Input Validation

中

在推理入口放一道同步檢查，先把傳入文字正規化並篩選，再交給 agent 執行，確實能提高隨手嘗試注入的成本。不過在這個案例裡，它僅適合作為補強層而不是主要邊界：觀察到的第二階段內容之所以用 Base64 編碼，目的就是要通過提示詞層級的過濾，因此真正決定結果的是 AID-H-017.002 與 AID-I-001.004。

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

列出環境裡所有正在執行的 AI 服務，逐一確認哪些從外部連得到、哪些需要憑證才能使用。只要是不需驗證又對網際網路開放的 AI 服務，就先當成已經被入侵，把它從網際網路上移下來，再來討論版本有沒有更新。
盤點你的 agent 實際握有哪些工具。只要有任何 agent 能執行任意 shell 命令，真正決定安全與否的就是這項能力，而不是提示詞過濾器；應改成範圍明確的型別化工具，或把執行動作移到隔離的中介服務後面。
對 agent 與推理工作負載採用預設拒絕的對外連線政策，只放行它們真正需要的端點。這一步能同時拿掉這次觀察到的帶外確認通道與第二階段下載。
建立主動獵捕規則，尋找出現在 AI 工具目錄下的執行檔，以及推理或 agent 程序去啟動 shell 的情況。這批遙測中的偽裝，刻意做成看起來就像正常的 AI 工具檔案，靠路徑直覺是抓不到的。
依呼叫者身分建立 token 用量與供應商費用的基準線並設定警示，因為閘道金鑰被偷之後，浮現的形式是別人替你多出來的推理帳單，而不是磁碟上多了一個檔案。

結論

真正值得注意的變化，不是 AI 服務會被攻擊，而是打過來的工具是由讀過這個產品的人寫的。知道某個代理服務把 master key 放在模組狀態而不是檔案裡，或知道開發者主機上出現 .claude 目錄一點也不奇怪，這些都是把產品知識直接用在入侵上。AIDEFEND 指出的，是那些不管攻擊者多熟悉內部構造都仍然成立的控制：每個 AI 服務都要通過驗證才能存取、用範圍明確的工具取代通用 shell、在執行環境外圍採用預設拒絕的對外連線政策，以及用用量監控讓被偷走的金鑰現形，即使它從頭到尾沒在磁碟上留下任何東西。