AIDEFEND in Action AIA-0078 實際事件 發布於 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 檢查實際送入模型的文字,辨識單次請求中的機密擷取或繞過指令意圖。個別看似正常的任務不一定足以辨識整場行動的惡意目的;這項控制無法介入攻擊者自行操作的助手,也不能取代受保護資產上的授權檢查。放行前,整合端須另行確認必要的分類類別完整,且分數為有效範圍內的有限數值。目前 G001 範例可能把空結果、缺少類別或 NaN 分數回報為 PASS/NO_FINDING;這些情況應視為錯誤並拒絕放行。這項結果檢查需要另外實作,不能當成公開範例已提供的能力。分類器仍可能漏判,因此工具與輸出須另設管制。
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。

最後更新: