Wiz 梳理 AI 智能體攻擊特徵及其對歸因與防禦的影響

在我們參與的事件應變工作及威脅狩獵調查中，一個明顯趨勢正逐漸浮現。Wiz 越來越常發現入侵事件中有 AI 代理負責大部分實際操作，甚至可能自行協調整場攻擊。這些代理透過執行框架運作，能編寫自訂工具、檢視結果、作出調整並以機器速度反覆執行，而人類則設定目標和防護界限。

這些攻擊可能會產生大量活動，代理會並行嘗試多種方法。它們出現在攻擊範圍的兩端，既有精準鎖定目標的攻擊，也有廣泛伺機而動的攻擊。攻擊可能由單一暴露的服務開始，逐步擴展至竊取雲端憑證、竊取 Kubernetes 權杖、橫向移動，以及大量外洩機密資料。AI 代理把這類升級攻擊過去所需的專業實際操作工作大幅壓縮。不過，這對防守方而言可能是個優勢。目前的代理式攻擊往往動靜較大，會留下大量可觀察的活動紀錄。  挑戰在於分辨這些活動與合法自動化操作，並把個別訊號關聯起來，拼湊出完整的攻擊情況。

在我們近期的網誌文章AI 驅動雲端攻擊剖析和Storm-0940 擴大對 IT 及軟件供應商的目標範圍中，我們深入探討了具體的代理式入侵事件。本文會從更廣泛的角度出發，檢視私下披露及公開報告的案例，找出代理式活動反覆出現的特徵。我們亦會探討這項轉變對歸因、攻擊規模及防禦未來發展的影響。

從 ARTEX 到 Hermes：真實環境中的代理式攻擊

近期公開披露的資料描述了涉及具名代理式框架的真實入侵事件，例如 ARTEX 和Hermes，以及使用自訂代理式工作流程的案例，還有底層工具尚未確認的事件。

• ARTEX——南韓金融機構及 ConnectWise 供應鏈遭入侵事件：多份公開報告指出，威脅行為者使用代理式滲透測試框架 ARTEX 自動執行攻擊行動。在南韓，研究人員報告金融機構面向互聯網的應用程式遭到利用，約 67,000 人的個人識別資料被外洩（Zscaler、CrowdStrike）。另外，Microsoft將 ConnectWise Cloud Backup 供應鏈遭入侵事件歸因於 Storm-0940（一個與中國政府立場一致的威脅行為者），並報告指 ARTEX 被用來加快偵察、密碼噴灑，以及濫用 OAuth 應用程式，目標是下游 Microsoft 365 環境。該行動曾嘗試登入超過 2,250 個租戶，並有多宗在不到三小時內取得特權雲端存取權限的案例。Microsoft 亦報告指，ARTEX 驅動的活動以全球數百個機構為目標，但大部分攻擊嘗試均未成功。

• Hermes－泰國財政部：Hunt.io發現由攻擊者控制的基礎設施，其中的日誌顯示，入侵期間 Hermes AI 代理以無人值守的「YOLO」模式運作。該代理列舉內部主機、檢查檔案，並調查權限提升的機會。調查人員發現證據，顯示財政部多個系統已遭入侵，並發現 Web Shell、被盜憑證及以 Go 編寫的自訂植入程式。初始存取方式仍然未知，研究人員在發現事件時未找到數據外洩的證據。

• AI 輔助 API 漏洞利用－日本及海外機構。JPCERT/CC調查了影響日本多個機構的一系列攻擊，並發現證據顯示攻擊者利用 AI 掃描已知漏洞並攻擊 API。在部分個案中，攻擊者對 Android 應用程式進行逆向工程，以識別底層 API，並測試當中是否存在伺服器端請求偽造（SSRF）等漏洞。調查亦發現包含漏洞測試相關工具和痕跡的基礎設施，以及嘗試存取內部網絡的活動。調查結果顯示，AI 可協助針對各類目標進行偵察及漏洞發現，而不僅限於使用專用的代理式滲透測試框架。

• 自訂代理式工作流程－多個行業及國家：CrowdStrike記錄了另外四個在針對醫療、政府及私營機構的行動中使用 AI 代理的威脅行為者。他們採用的方式各異，包括以PentestGPT為基礎改造的自訂框架，當中設有分開的監督代理及執行代理；亦包括自主程度及委派方式各有不同的 Claude Code 工作流程。據報活動涉及竊取憑證及醫療紀錄、入侵政府機構，以及外洩企業數據。

• 身份不明的代理式工具－DIVD：荷蘭漏洞披露研究所披露一宗資料外洩事件，觀察到的作案手法顯示，攻擊可能由代理式 AI 驅動。DIVD 報告了可疑活動，並展開事件應變及取證調查，但其首次公開聲明並未指出所涉代理或框架。

綜合而言，這些報告顯示，代理式 AI 已用於真實入侵事件的多個階段，包括偵察、漏洞利用及入侵後活動。各個案的自主程度及現有證據的充分程度各有不同，但工具和工作流程的多樣性顯示，這種情況並不限於單一框架或威脅行為者。

Wiz 調查的代理式攻擊

本節介紹我們調查的三宗真實攻擊個案，並剖析代理式活動的主要特徵，透過各個個案的例子加以説明。 

個案研究：代理式活動的三個例子

AI 代理指紋識別準則

分析這些代理式攻擊後，我們歸納出一組有助識別這類攻擊的準則。以下各項準則會在適用時列出上述三宗攻擊中的具體例子。

1. 以機器速度持續反覆執行

這種節奏既不像人手編寫專用工具（速度太慢），也不像預設掃描器重播固定流程（過於一致）。關鍵在於節奏會隨步驟複雜程度改變（模型讀取輸出、推理並生成下一步所需的延遲），而且持續時間異常長。

• 攻擊 A：平均每一至兩分鐘便會出現一個全新、獨特、專門編寫的指令碼，持續約 24 小時，合共 99 個指令碼。速度遠快於人手編寫，內容也比掃描器專用得多。

• 攻擊 B：在約 4.5 小時內，連續執行 602 個獨特步驟，逐一遍歷不同技術類別，每個階段之間只有數秒；而該工作負載過去從未出現過類似情況。確定性的自動漏洞利用鏈會在毫秒內執行相依命令；固定間隔的信標則會集中在同一時間值。延遲以秒計、會隨步驟複雜程度改變，正是 LLM 讀取、推理及生成的特徵。

• 攻擊 C：操作者的註釋附有時間戳記；每一至兩分鐘便會出現一個全新、獨特、專門編寫的指令碼，並以突發形式持續近 21 小時，中間沒有任何人類操作者常見的疲勞間歇。節奏會隨複雜程度改變：在 403s 上快速重試；需要解析 SPA JS 區塊以提取 GraphQL 端點時，間隔則較長。這既不像人手編寫工具（以這種數量而言，速度太快而且過於專門），也不像預設掃描器（適應能力太強）。

2. 工具中嵌入自然語言推理

指令碼和其他產物中包含文字説明（攻擊計劃，以及對做甚麼和為甚麼這樣做的解釋）。

• 攻擊 A：99 個指令碼中，幾乎每個都以文字計劃開頭（原文為中文，以下為譯文），例如分階段偵察的標題，如 # Stage 1: system identity / environment variables / cloud-credential files / SSH … and # restart-free activation: SIGUSR1 opens the inspector → register a hidden route in the live process via CDP → close the inspector。其中一個批量利用指令碼以完整攻擊計劃開頭，解釋會測試甚麼及原因（經翻譯和刪節）：

• 攻擊 B：指令碼在執行時自行記錄説明：echo "[runtime]", [tools], [route], [client], [IMDSv2 token] wget_rc=4 bytes=0, [IMDSv1 probe]，並建立有標籤的結果表 (printf '%s\t%s\t%s\n' "$path" "$code" "$size") 和權限矩陣 (pod_eviction false / deploy_scale_patch false)。這顯示操作者在收集證據的同時為證據加上説明，是生成式工具會解釋做甚麼及原因的典型特徵。

• 攻擊 C：證據最為確鑿。取回的操作者工具中，/tmp 個指令碼合共有 803 行各不相同、可供人閲讀的註解，而且幾乎每個指令碼都會説明正在做甚麼及原因（經翻譯和刪節）：

最有力的證據：評述點名推動這次行動的 Agent 框架，並推理自身的平行執行個體。它提到「另一個 <agent>」，即同一 Agent 的第二個執行個體，並試圖推斷該執行個體完成了甚麼（翻譯並刪節）：

一則推理「另一個 <agent>」完成了甚麼的筆記，是攻擊者以自己的措辭直接在文中承認，有 Agent 正在實際執行操作。

3. 自我修正與適應性執行

Agent 不會盲目地執行固定的攻擊負載。它會讀取回傳結果並作出調整：診斷失敗原因並重新設計架構、在某些方法行不通時改用後備方案，或改變做法後重試。靜態操作手冊做不到這些。這種能力體現在帶有版本編號、自我説明的腳本，以及因應情況即時作出的流程修正上。

• 攻擊 A：三者中最能體現 Agent 特性的單一產物：一個金鑰驗證工具的版本 2，開頭便解釋版本 1 為何失敗，以及它因此作出了哪些改動（翻譯並刪節）：

它檢查了一份經安全性自訂的設定，找出先前的方法為何受阻，並改寫其方法以繞過限制。同樣的模式也出現在版本序列中：最初的 --remote-debugging-port=0 方法失敗後，便重新設計為 SIGUSR1→CDP 技術；還有 act3 → act3b … act3k、inv3 → 4 → 5 和 apikey_test → test2 → use 等一系列方法。

• 攻擊 B：因應目標回傳結果，即時重新設計架構。中繼資料的處理順序是：IMDSv2 PUT → wget_rc=4 失敗 → IMDSv1 → ECS 憑證端點（169.254.170.2, .170.23/v1/credentials）→ IPv6（[fd00:ec2::254]）→ 最後以 InfluxDB-Flux SSRF 作為取得同一個 Token 的替代路徑。它讀取每個回應，診斷失敗原因，並設計新的原語。Kubernetes 儀錶板也採用同樣做法：先進行匿名探測（tokenPresent:false）→ 再使用遭竊的 Bearer $T 重試相同端點。

• 攻擊 C：教科書式的自我除錯，跨越多代編號腳本。叢集 Token 轉向過程以四代腳本逐步除錯請求簽署（nodepivot.py → 2 ("SigV4 edge cases") → 3 ("pure-stdlib, SignedHeaders=host only") → 4），每一代都會診斷上一代的 401/403，並重新推導所需條件（翻譯並刪節）：

靜態操作手冊無法讀取 AWS 錯誤訊息，並重新推導出區域 STS 的要求。同樣的推理式後備方案模式貫穿 dynamo2 → 3 ("create a TokenRequest for the service SA") → 4 ("403 on TokenRequest; legacy SA tokens may exist as pre-1.24 k8s Secrets") → 5 ("cheaper: call the service's INTERNAL API directly")，以及 ir_x → x2 → x3 和 s2s4 → s2s5 → s2s6（「使用無效欄位觸發『你是否想找……』提示」）。

4. 結構化、由廣至深的方法／近乎完整的 TTP 覆蓋範圍

以範本化步驟進行系統性枚舉，按部就班地逐一測試各種技術，而非直奔單一目標。以機器速度執行時，這看起來就像 Agent 正按清單逐項處理。

• 攻擊 A：以上明確列出的 A 至 E 探測矩陣（工具中嵌入自然語言推理），一致地套用於每個目標；此外，還有明確編號的階段，依序涵蓋身分 → 環境 → 各雲端供應商的憑證檔案 → SSH → 資料庫憑證解密 → 持久化 → 掃描 → 橫向移動 → IMDS → API 濫用。

• 攻擊 B：三者中最全面的一個：涵蓋 12 個技術類別的 602 個獨特步驟，依序為：偵察 → 工具枚舉 → IMDS → 容器逃逸檢查 → Kubernetes RBAC 枚舉 → 訊息傳遞（RabbitMQ）→ Kubernetes API → 記憶體內資料儲存庫（Hazelcast）→ 連接埠掃描 → 服務探索（ArgoCD／儀錶板）→ 時序資料庫（InfluxDB）→ 反序列化研究。它按清單逐項執行，有條不紊地測試各種技術，而非直奔單一目標：

• Attack C：一條緊湊、教科書式的雲原生攻擊鏈（RCE → UID 偵察 → IMDSv2 憑證 → SA 權杖 → SelfSubjectRulesReview → 機密資料 → 叢集驗證設定 → 節點 → 命名空間 → Pod → 持久化），之後有條不紊地擴展至所有可觸及的資料路徑：Postgres、DynamoDB、Redis 個人檔案快取、Consul 服務目錄、gRPC 反射、S3 bucket 列表、數個 MCP 伺服器，以及整個 GraphQL 聯邦。例如，從 IMDSv2 竊取雲端憑證並傾印叢集機密資料：

5. 詳盡程度：同時大量掃射多條橫向移動路徑

準則 4 著眼於按次序涵蓋目標；這裏講的是數量和噪音：Agent 不會選定一條橫向移動路徑再沿線追查，而是一次嘗試多條路徑（數十個連接埠、多個服務、數部主機），並持續大量發送請求，因為它不像人類，不會因為疲勞或謹慎而有所顧忌。這正是機會主義式危險的另一面：同樣是見甚麼都攻擊，才令這些行動既快速又異常嘈吵。這種嘈吵本身就是偵測機會。

• Attack A：同一行為的對外版本：它沒有在單一環境內橫向移動，而是同時將相同的漏洞利用手法掃向數十個外部目標的 3000 連接埠，並按主機分支。把廣度作為策略，目標指向外部。

• Attack B：它按照每種 Helm chart 和命名空間慣例，產生 100 多個 ArgoCD 主機名稱變體；並行掃描 5 部主機上的 15 個連接埠（& … wait），同時列舉記憶體內儲存區所有已知的 map 名稱，並同時嘗試連接機密資料介面、GitOps 控制器、Kubernetes 控制台，以及雲端 Pod 身分代理程式。基本上是同時嘗試所有橫向移動途徑，而非選定一條路徑：

• Attack C：同時攻擊所有目標，而非選定一條路徑：以粗略的 /24 掃描資料庫子網，尋找開放的 5432（逐步抽樣以加快速度）；進行 gRPC 反射及常見連接埠探測，並設定較短的逾時；在約 ~21h 內，並行執行 150 多個不同腳本，追查約 25 個目標機構（大型加密貨幣交易所及金融科技公司）。它大聲行事不會付出疲勞代價。

6. 投放載荷前先探測，以及具 OPSEC 意識的包裝器

先用無害的方式確認攻擊原語有效，再投放真正的載荷；並以包裝器控制執行過程，限制輸出並保持低調。這種有條理的「先驗證，再行動」模式，是生成式工具的典型特徵。

• Attack A：先發送無害標記，只有在收到回傳標記後才投放真正的漏洞利用；確認其 hook 確實生效（grep -c <tag>）；載入後門前先檢查語法（node -c）；並在任何經驗證的預測呼叫前，先執行 GET /api/v1/version 和一次無需驗證的金鑰測試：

執行過程以格式統一的自我清理單行命令包裝（printf … | base64 -d > /tmp/.cXXXX.sh; sh …; rm）。

• Attack B：每條命令都在具備 OPSEC 意識的 beacon 包裝器內執行；包裝器會解碼命令、執行命令、將輸出截斷至固定大小、重新編碼，再以同一個 session ID 傳回，並刻意控制哪些內容會離開主機。它亦會先探測再行動（先執行 sleep 4/sleep 0；先進行原始的 >/dev/tcp/$h/$p echo，才發出任何 HTTP 請求；使用工具前先執行 command -v <tool> || true），讓每個載荷保持靜音並限制其執行範圍（head -c 49152, 2>/dev/null, set -e, 逾時、一次性 -t 1），並在事後自行清理 (unlink /tmp/<app>_auth_header)，甚至把 RabbitMQ 連線終止偽裝成 reason=<app>_queue_repair：

• 攻擊 C：首次接觸經由帶外互動端點（.../stdio-rce-a）進行，先完成經典的「確認回呼正常運作」驗證步驟，之後才展開規模較大的資料外洩行動。每次探測都設有較短的逾時時間（curl --max-time 5, -m 3），以保持低調並避免程序掛起；評論中亦明確説明 OPSEC 考量：「以最高 OPSEC 標準測試通往 DynamoDB 的路徑：不部署、不寫入」以及「連接至 DynamoDB 端點的 TCP 443 流量，與任何 AWS 呼叫的流量使用相同出口，無法與工作負載正常使用 ASM/STS 的流量區分。」先驗證，再行動，並刻意融入工作負載的正常流量。

7. 用途描述性／一次性暫存產物（及自行標記的 IOC）

一次性、名稱能描述用途的暫存檔，位於 /tmp 或記憶體路徑中的測試殘留物，以及一個值得留意的特徵：產物中包含攻擊者自己的識別資訊。人類攻擊者通常會避免在自己的作品上署名；即時生成名稱的 Agent 往往不會。

• 攻擊 A：一次性、帶有實驗室測試風格的腳本名稱（p10rce.py, batch_new_rce.py, scan_guard12.py, inv3/4/5.py、隨機的 /tmp/.cNNNNN.sh），以及以每個目標的地址八位組機械式產生每部主機識別碼的攻擊活動記錄（一部位於 a.b.c.d 的主機會以 host_a_b_c_d 作記錄）。它還會自行留下標記：固定的啟動標籤（<tag>）、後門權杖（<token>），以及注入執行中程序的隱藏路由（/<rand>）。

• 攻擊 B：即時產生約 40 個以自身命名的暫存檔（/tmp/influx-imds.flux, influx-imds.out, dash-auth-body, argo-login.json, argo-session, k8s_ssar_all.sh, read-sa.flux, oidc-k8s.out, <app>_auth_header, <app>_current_bearer, cp1/cp2/cp3, Test.java），全部名稱具描述性、屬一次性且由機器命名。最明顯的自行標記特徵是：透過訊息代理（RabbitMQ）的 HTTP API 注入以攻擊者自己的 C2 主機命名的全域參數，另外還有 C2 工作階段 ID，以及每項任務各自的 MD5 結果路徑：

• 攻擊 C：全程使用一次性、名稱具描述性的 /tmp 腳本（dump.py, refl.py 用於 gRPC 反射、nodepivot*.py, dynamo*.py, coh1-48.py, s2s*.py, intro*.py）；在記憶體路徑下藏有隱藏的反向 Shell 持久化腳本（/dev/shm/.x/c.py，連接至 <C2>:19001）；RCE 端點本身也有自行標記的 IOC：/stdio-rce-a內含攻擊者對漏洞利用方式的自我描述（stdio 傳輸 RCE）。人類攻擊者很少會以這種方式留下署名。

這一趨勢對未來的意義

歸因會變得更困難。過去，成熟的威脅行為者會建立並重用大量工具、漏洞利用程式及 TTP。追蹤這些反覆出現的模式，有助防禦者將攻擊活動互相連結，並隨時間推斷其來源。但隨着攻擊工具愈來愈容易分享、調整及改作他用，這些模式作為歸因線索的可靠性也會降低。Shai-Hulud 供應鏈攻擊活動正好説明瞭這種轉變：TeamPCP 公開發布惡意軟件的源碼後，後續攻擊活動的歸因便受到質疑。其後的活動，包括以 Red Hat npm 套件為目標的 Miasma 攻擊活動，重用了該程式碼並加以擴充，令單憑技術相似之處更難區分 TeamPCP 自身的行動與模仿者的活動。隨着 AI Agent 令針對個別攻擊活動生成及修改工具變得更容易，防禦者或需減少單靠程式碼和工具相似之處作判斷，並更重視受害者特徵、目標選取模式、基礎設施及攻擊目標等背景資訊。

攻擊規模可以超越人類操作人員的極限。 過去，攻擊行動的主要限制之一是熟練人員可投入的工時。這項限制正在改變。如今，單一操作人員可以監督更多針對更多目標的攻擊活動，而代理程式則以較少的人工介入尋找機會並調整策略。無論是機會型還是目標式攻擊，都可以結合自動化的觸及範圍與適應性強、近似專家水平的行為，令這種能力可能擴展至廣泛得多的目標。

能力更強不一定代表更隱蔽。 AI 代理程式可能會犯錯、生成無法正常運作的工具、走進死衚衕，或誤解結果。它們反覆迭代的方式亦可能留下大量可觀察的活動痕跡，例如探測環境、執行命令，以及根據發現作出調整。這些行為不一定會令攻擊更容易被偵測，但有適當可視性及行為偵測能力的防禦方可以藉此找到機會。挑戰在於區分由代理程式發起的攻擊活動與正常的自動化操作，將個別訊號關聯起來，形成連貫的整體情況，並在攻擊進一步升級前有效應對。

AI 可以加快防禦，但準備就緒才是發揮成效的關鍵。 當攻擊可以更快地由初始入侵發展至大範圍失陷，安全團隊便不能單靠人手調查及應對。AI 可以協助調查警示、關聯活動、確定影響範圍、識別已遭入侵的憑證及受影響系統，並加快遏止攻擊。但這些能力的成效，取決於背後的可視性、脈絡及應變流程。防禦方仍須減少暴露的攻擊面、優先處理可被利用的風險、在整個環境中保持可視性，並在事故發生前建立清晰的遏止及修復工作流程。正如我們的 AI Threat Readiness Framework 所述，目標是建立所需的可視性及行動速度，以便在攻擊加速時有效應對。