近期安全研究機構 QiAnXin XLab 揭露了一個名為 NadMesh 的 Go 語言編寫的殭屍網路（Botnet）。與以往單純追求佔用 GPU 算力來挖礦的攻擊者不同，NadMesh 的核心目標是透過暴露在公網上的 AI 服務作為跳板，竊取高價值的雲端憑證（Cloud Credentials）與叢集管理權限。
這類攻擊之所以危險，是因為許多開發團隊在快速部署 AI 實驗環境時，往往採取先上線、後設定防火牆的習慣，導致大量管理介面直接暴露於公網。
攻擊路徑與目標服務
NadMesh 利用 Shodan 等網路掃描工具，精準鎖定那些未經認證或設定錯誤的 AI 相關服務。被重點掃描的服務包括：
ComfyUI（AI 圖像生成工作流） Ollama（本地 LLM 運行環境） n8n（工作流自動化工具） Open WebUI 與 Langflow（AI 代理與對話界面） Gradio（機器學習模型展示界面）
攻擊者並不滿足於控制單台主機，他們將這些 AI 服務視為進入企業內網的入口。一旦進入系統，Bot 會優先搜尋環境變數、.env 檔案、~/.aws/config 以及 ~/.docker/config.json 等設定檔，旨在奪取 AWS 金鑰（AWS Keys）或 Kubernetes 服務帳戶令牌（K8s Service Account Tokens）。
重點分析：MCP 協議的風險
本次攻擊中值得關注的是對 MCP（Model Context Protocol，模型上下文協議）的利用。MCP 旨在讓 AI 模型能安全地與外部工具（如資料庫、檔案系統）互動。
然而，MCP 的早期規範將身份驗證（Authentication）設計在核心協議之外，導致許多部署環境跳過了認證步驟。NadMesh 專門尋找具有 execute_command 功能的 MCP 服務，直接透過 JSON-RPC 調用來執行系統指令，實現遠端程式碼執行（RCE）。這提醒工程師，任何能讓 AI 呼叫外部工具的接口，若缺乏嚴格的權限控管，等同於在伺服器上開了一個遠端終端機（Shell）。
除了 AI 服務，NadMesh 同時利用傳統的漏洞進行擴散，包括：
未經認證的 Docker API（Port 2375） Jenkins 腳本控制台（Script Console） 弱密碼的 Telnet 或 SSH 服務 未認證的 Redis 實例 以及較新的 CVE 漏洞，如 Marimo notebooks 的遠端執行漏洞（CVE-2026-39987）。
防禦與應對實務
對於維運與開發工程師來說，應採取以下防禦措施：
封鎖不必要的公網暴露。優先檢查 ComfyUI (8188)、Ollama (11434)、Gradio (7860) 與 n8n (5678) 等連接埠，確保其位於 VPN 或身份驗證閘道後方。
實施憑證最小權限原則。不要將具有高權限的 AWS 金鑰或 K8s Token 儲存在伺服器的環境變數或明文檔案中。建議使用 AWS IAM Roles for Service Accounts (IRSA) 或 HashiCorp Vault 等動態憑證管理工具。
徹底撤銷而非僅是輪換。若發現主機被入侵，必須立即撤銷（Revoke）所有該主機可接觸到的金鑰與令牌。單純的輪換（Rotate）在殭屍網路依然潛伏的情況下沒有意義，因為新金鑰會立刻被再次竊取。
清除持久化後門。NadMesh 具有強大的生存能力，會同時在多個路徑（如 /etc/cron.d/ 或 /tmp/.a）建立持久化機制，且使用 Garble 混淆與 UPX 壓縮，導致每個樣本的雜湊值（Hash）不同。發現入侵後，建議直接重建主機（Rebuild）而非嘗試手動刪除檔案。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。