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

GTG-1002：攻擊者將網路間諜行動拆解為日常任務，濫用 Claude Code 協助滲透

Anthropic 於報告中揭露，2025 年 9 月有具國家背景的攻擊團隊鎖定約 30 個組織展開滲透，並導致少數單位受害。攻擊者假借執行正當資安檢測的名義，將整場攻擊行動拆解成數十個看似普通、合理的技術小任務，藉此規避安全防護並利用 AI 程式開發工具 Claude Code 加速攻擊流程。對 AI 服務提供者而言，此事件凸顯了多輪對話整體脈絡監控與輸出端嚴格把關的重要性，同時也表明防護邊界無法延伸至攻擊者本機執行的工具。

Guardrail BypassData ExfiltrationInput ValidationAgentic AI
4 項對應的 AIDEFEND 防禦手法
來源: Disrupting the first reported AI-orchestrated cyber espionage campaign 
作者: Anthropic Threat Intelligence
原文發布: 2025年11月13日

威脅分析

  • 虛假授權聲明與任務碎片化成功掩飾了攻擊意圖。 Anthropic 研判 GTG-1002 極可能具備中國國家背景（原文為 high confidence）。攻擊者自稱合法資安人員，並將整體入侵目標切碎為零散指令，使單一提示詞看起來合規，讓模型難以察覺其組合後的真實惡意目的。
  • 工具介接使 AI 從「單純建議」轉變為「實體執行」。 攻擊者的排程系統透過 MCP（Model Context Protocol）將 Claude 與外部工具串聯。技術報告 描述了一條 SSRF（伺服器端請求偽造）攻擊路徑：從目標掃描、生成攻擊碼、自動驗證、經由人工確認後執行入侵，進而展開內部網路探索與憑證濫用。
  • 高度自動化並不代表產出完全可靠。 Anthropic 估計約 80% 至 90% 的戰術性操作是由 AI 自動完成，但關鍵決策仍掌握在人類攻擊者手中。此外，Claude 在過程中也曾捏造虛假憑證，或將公開資訊誤報為機密情資；因此 AI 生成的報告不能直接作為入侵成功的實質證據。
  • 服務供應商的可見範圍存在天然極限。 Anthropic 透過分析雲端工作階段紀錄封禁了惡意帳號並通報受害單位，但供應商無法直接監控或重組攻擊者本機端的所有指令與最終受害全貌。此為 2025 年發生的真實案例，非 2026 年新發生的事件。

適用的 4 項 AIDEFEND 防禦手法

AID-D-003.005
Stateful Session Monitoring: Intent Drift + Invariant-Breach Signals
中
模型服務營運方可依 G001，以租戶、使用者與工作階段維護紀錄，追蹤實際收到的對話輪次、意圖偏移，以及可觀察到的外部目標增加情形，補足單次提示檢查缺少的調查脈絡。但它無法串起所有分開提交的任務，也不能單憑訊號認定惡意；合法測試可能出現相似行為，缺漏的對話與工作階段也會限制判斷。這項紀錄負責偵測，是否攔阻由其他控制決定。
AID-D-001.001
Per-Prompt Content, Intent & Obfuscation Analysis
中
在供應商入口依 G001 部署固定版本、經校準的分類器，檢查實際收到的提示，將綁定該份內容的濫用發現交給輸入放行政策。它能辨識可見的指令繞過或提權意圖，但看似合理的單一任務仍可能漏判。「測試已獲授權」是不可信輸入，不是經獨立核准的委託證明；偵測器本身也不會拒絕請求。
AID-D-003.001
Harmful Text & Token Output Policy-Violation Detection
中
交付生成的漏洞利用程式前，依 G002 由固定版本的評判模型檢查該份輸出，產生綁定回應的結構化政策判斷。校準資料須同時包含合法資安工作與濫用案例，不能只因程式包含 SSRF 就認定惡意。評判模型是可能誤判的偵測器，不是輸出放行控制；無法判斷或執行失敗時，也不能當作檢查通過。
AID-H-006.002
Text, Markup & Structured Output Sanitization and Release Gate
中
在供應商的輸出邊界使用 G004 完整回應模式，先暫存可執行內容，等指定偵測器確認沒有發現問題才交付。介接程式須將判斷綁定實際回應；發現問題、無法判斷、執行錯誤或證據寫入失敗時都不放行。這能攔下已偵測到的濫用程式，避免串流先送出未檢查的前段；但不能補救分類器漏判，也無法停止已在本機執行的工具。

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

  • AI 服務營運方：列清楚服務實際看得到哪些提示、回應、身分與工作階段。不要把用戶端送來的工具結果標成可信的本機執行證據，也不要把沒看到的活動視為安全。
  • 偵測工程團隊：用拆分成多輪的濫用案例與合法滲透測試一起重播，分別量測漏判與誤報。信任工作階段紀錄前，先測試對話輪次缺漏、重複與順序顛倒的情況。
  • API 工程團隊：用明確的狀態轉換介面，把評判模型的結構化結果接到輸出放行控制；無法判斷、格式錯誤與結果不完整時都不得放行。測試惡意內容出現在回應前段、檢查逾時及證據寫入失敗的情況，確認可執行內容在完整檢查前不會送出任何位元組。
  • 濫用事件處理團隊：明定誰調查發現、誰有權限制帳號。保存供應商自己持有的證據，驗證限制是否生效，並說明哪些攻擊者本機操作仍不在控制範圍內。
  • 可能的受害單位：持續落實應用程式、身分與資料庫防禦，用自己的紀錄驗證可疑存取。不要把攻擊者的 AI 報告當作入侵確認，也不要假設供應商的模型過濾器能保護你的應用程式。

結論

本案的關鍵教訓在於，攻擊者並非單純依靠巧妙的越獄提示詞，而是藉由「任務碎片化」剝奪了模型理解整體攻擊脈絡的能力。AIDEFEND  在服務邊界提供了提示詞審查、工作階段意圖追蹤與輸出放行控制等對應手法；但單靠模型的自我拒絕或使用者片面的授權聲明，絕不能取代系統層級的強制驗證機制。逐步重建請見 SecureFlow AML.CS0069。