2026-11-10 by 高田鑑識

本文整理自 Checkmarx Zero 研究團隊發表的〈Fears of Advanced AI Attacks Haven’t Materialized, but There’s Still a Threat〉。作者彙整 Mandiant、Verizon、Microsoft 等機構的最新事件調查與資料外洩報告，檢視「AI 讓攻擊者變成超級駭客」的說法，是否有真實入侵案例佐證。

重點摘要

• 結論：現有證據顯示，AI 讓攻擊者在既有手法上更快、更大規模、品質更高，但尚未出現防禦措施完全無法應對的全新攻擊類別。
• 真正造成入侵的原因：仍以可被利用的程式漏洞、外洩的權杖與憑證，以及權限過大的身分為主。
• 最明確的變化是速度：平均漏洞利用時間已降到負值，攻擊者在修補程式推出前就已動手；入侵後移交給下一組攻擊者只需數十秒。
• AI 的新風險：開發環境中的 AI 代理程式、命令列工具與權杖並存，本身就成為新的攻擊面。
• 防禦建議：把基本功做得更快、更一致，而不是追逐資料中看不到的「AI 專屬攻擊」。

近幾個月的新聞標題，讓許多資安長與防禦人員認為 AI 即將帶來難以防禦的新型態攻擊。作者列舉的例子包括：7 月 Hugging Face 通報有自主 AI 代理系統入侵其基礎設施，OpenAI 後來表示那些代理是從資安測試環境中逃脫的自家模型；8 月底 OpenAI、Anthropic、AWS、Microsoft 等百餘家公司發表公開信，警告組織只剩數個月準備 AI 攻擊；9 月則有媒體報導專家預期將出現前所未有的 AI 攻擊浪潮。

相較之下，Google Cloud 的《Cybersecurity Forecast 2026》語氣較為克制，預測攻擊者會用 AI 提升行動的速度、範圍與成效，也就是「同樣的攻擊，更快、更大規模」，而非新型態攻擊。Semperis 的 2026 勒索軟體風險報告則指出，超過八成受訪的勒索軟體受害者表示攻擊者使用了 AI，但報告並未說明受訪者如何判斷 AI 的介入。

作者認為，這兩份報告都值得一讀，但一份是預測，一份是自我回報的問卷，都不是對真實入侵起點的調查。許多 AI 攻擊相關說法也是如此：屬於預測、示範或廠商主張，而非來自實際事件的觀察。

要了解入侵到底怎麼發生，作者轉向事後重建入侵過程的事件應變（IR）案件與大型資料外洩資料集：

• Mandiant M-Trends 2026（3 月）：所調查的入侵來自被利用的程式碼漏洞、外洩的權杖與權限過大的身分。AI 最多只是加速因素，而非根本原因，案件中沒有任何「AI 超級攻擊者」的證據。
• Verizon DBIR 2026（5 月，涵蓋 22,000 件以上確認的資料外洩）：攻擊者主要是用 AI 擴大並強化既有的攻擊模式，而不是發明新的模式。
• Microsoft Digital Defense Report 2026（10 月 1 日）：得出同一方向的結論。

三份資料各有侷限：Mandiant 的樣本來自自家事件應變案件，偏向有聘請 Mandiant 的受害企業；Verizon 的資料來自貢獻單位與公開揭露，組成會隨貢獻者增減而改變；Microsoft 的資料來自自家應變人員與客戶。作者提醒，這些結果可合理推論，但不代表所有組織。

在 Mandiant 的案件中，攻擊者使用 AI 的環節主要出現在攻擊生命週期的前段：偵察、社交工程與惡意程式開發。Mandiant 也描述了一個竊密程式，利用本機的 AI 命令列工具搜尋設定檔，並嘗試蒐集 GitHub 與 npm 權杖。作者認為，這更說明 AI 工具成為組織內部的新攻擊面，而不僅是攻擊者的工具。

Verizon 分析了 Anthropic 曾採取執法措施的 793 個攻擊者，發現在 AI 輔助的初始入侵手法中，釣魚占 44%、漏洞利用占 32%。有趣的是，儘管釣魚活動使用了 AI，釣魚在 Verizon 自身資料集中的占比與往年相比並無明顯變化。

一、漏洞利用再度居首，且持續上升

三者衡量的對象略有不同，數字不能直接比較，但方向一致。Mandiant 的案例中，以對外網路的企業應用程式零時差攻擊為大宗，包括 SAP NetWeaver（CVE-2025-31324）、Oracle E-Business Suite（CVE-2025-61882）與 Microsoft SharePoint（CVE-2025-53770）；其中 SAP 與 SharePoint 在修補程式發佈後，仍被當成 n-day 漏洞持續利用。

修補速度也趕不上：Verizon 發現，2025 年 CISA 已知遭利用漏洞（KEV）清單中的重大漏洞，只有 26% 完全修補，低於前一年的 38%，完全解決的時間中位數拉長到 43 天。

二、權杖與身分

• Verizon：若以整個攻擊過程中任一時點計算，39% 的資料外洩涉及憑證濫用；作為初始入侵管道則降到 13%，Verizon 認為部分原因是調查方法調整，將假託（pretexting）獨立計算。
• Palo Alto Networks Unit 42：在逾 750 件事件應變案件中，近九成的案件裡身分弱點扮演了關鍵角色。
• Mandiant 的供應鏈案例：攻擊者從原始碼管理帳號或開發人員工作站切入，利用個人存取權杖（PAT）在儲存庫中找到寫死的整合權杖，把單一儲存庫的入侵擴大成影響所有客戶的事件，報告以 UNC6395 與 Salesloft Drift 事件為例。權限過大的整合金鑰與萬用 API 金鑰十分常見，OAuth 與更新權杖（refresh token）也能繞過多因素驗證（MFA）。

這些都是老手法，不需要 AI 也能成立。AI 很可能加速了這些攻擊，但光從事件調查資料很難證實。

三、「平均漏洞利用時間」已變成負值

變化與 AI 的普及時間點「可疑地吻合」，但單從這些資料難以斷定有多少要歸因於 AI。報告對確切數字有出入，方向則一致：Microsoft 另指出，漏洞出現在實際環境到被武器化的時間中位數已遠低於 24 小時。這意味著修補速度成為防守方的關鍵能力，但攻擊先於修補程式到來時，防禦也不能只靠快速修補。

各報告對釣魚影響的結論並不一致，但作者指出，報告作者們多半認同 AI 技術已經或即將提升釣魚的成效。

各來源計算釣魚的方式不同，數字不能直接比較。Microsoft 認為 AI 讓誘餌更個人化、更有效，但這是作者的推論，並非資料能直接證明；Microsoft 同時指出，在多數活動中，目標選擇、決策與最複雜的入侵仍由人工主導。Mandiant 的作者則表示，攻擊者正用大型語言模型（LLM）從大量電子郵件，轉向個人化、建立信任關係的社交工程；M-Trends 並未量化 AI 在其中的影響。作者的看法是：寫得通順、個人化的誘餌，或是深偽（deepfake）語音電話，確實讓老手法更有說服力，但它終究還是釣魚。

Microsoft 預期人工的限制會逐漸消失。7 月 Sysdig 記錄了被稱為首個代理式勒索軟體行動的 JADEPUFFER：一場由 LLM 全程驅動的勒索行動，入侵途徑是 Langflow 一個早已揭露、且已有修補程式的漏洞。它依然是透過已知漏洞達成的勒索軟體，但需要的人力減少，營運規模化的優勢就倒向攻擊者。

作者強調，這不是說 AI 沒有影響。AI 不僅加快攻擊的實作速度，也在組織內部擴大了攻擊面：開發工具鏈對攻擊者愈來愈重要，AI 代理程式在其中既是目標，也是工具。攻擊者一旦攻陷開發環境，會同時發現代理程式、命令列工具與權杖都放在一起。

M-Trends 的攻擊活動時間軸也呼應這個方向，列出了 Shai-Hulud npm 蠕蟲與 CVE-2025-55182（React2Shell），包括與 XMRig、TruffleHog 酬載有關的 React2Shell 活動。不過 M-Trends 對這些並無深入分析，作者僅將它們視為開發工具鏈受到攻擊的佐證，並預告下一篇文章會提供具體案例。

總結來說，AI 提高了熟悉攻擊的速度、規模與品質（包括釣魚、惡意程式、勒索軟體與憑證竊取），並讓存取權與憑證出現在新的位置，但它不是基本功無法應對的新攻擊類別。

如果漏洞利用可以早於修補、釣魚誘餌愈來愈個人化、權杖又能繞過 MFA，有用的工作其實並不吸睛，也不算全新，只是優先順序可能改變。目標是把基本功做得更快、更一致。作者把建議分成兩層。

通用層面

• 掌握自己有哪些對外服務的系統，並預先備妥在沒有修補程式時的補償性控制，例如防火牆規則、停用功能或隔離主機，為廠商爭取時間。
• 優先提升抗釣魚能力：改用抗釣魚的 MFA，並假設「文筆笨拙」這類舊有破綻正在消失。別只防電子郵件，語音與通訊軟體的誘餌也在增加，應讓服務台有不依賴聲音的來電者驗證方式。
• OAuth 與更新權杖可能在密碼重設後仍然有效，事件應變時必須一併撤銷工作階段。
• 規劃入侵後的速度：若移交給第二組攻擊者只需數秒，偵測與圍堵就不能卡在工單佇列裡。

應用程式安全（AppSec）層面：針對可被利用的程式碼、外洩的機密與權限過大的整合

1. 掌握軟體組成：維護最新的軟體物料清單（SBOM），並用軟體組成分析（SCA）判斷應用程式中哪些有漏洞的元件實際可達，才能在修補程式出現前採取行動。下一個像 React2Shell 的框架漏洞出現時，「我們有沒有受影響」應該在幾分鐘內回答得出來。
2. 依可利用性而非僅依嚴重程度排序：位於無用程式碼中的嚴重等級弱點，重要性低於位於對外執行路徑上的中等弱點。應整合程式碼、相依套件與基礎設施的發現，依可達性與曝險程度排序，這是應用程式安全態勢管理（ASPM）工具的工作。
3. 在源頭預防常見弱點：攻擊者持續鎖定同幾類程式弱點，AI 程式碼助理又讓審查者要檢查的程式碼量增加。在 IDE 與 CI/CD 管線中提供靜態分析回饋，成本遠低於上線後才發現。
4. 盤點機密並輪替：使用短效權杖與最小可行範圍，掃描儲存庫、建置管線設定與基礎設施即程式碼中寫死的權杖。整合權杖與 PAT 要視同正式環境憑證，包括放在個人與副專案儲存庫裡的。
5. 把開發工具鏈視為攻擊面：盤點開發環境中的 AI 程式碼助理、命令列工具、MCP 伺服器與代理程式，並以最小權限標準管理；套件在進入建置前先審查，因為 Shai-Hulud 這類蠕蟲正是透過遭入侵或惡意的套件擴散。
6. 讓政策可強制執行：沒有關卡的政策只是建議。當建置遇到已知被利用的元件或寫死的機密時失敗、或擋下合併，才能讓政策成為控制，前提是發現必須夠準確，團隊才不會想辦法繞過。
7. 補上修補的最後一哩路，且不只衡量時間，也衡量待辦數量：利用 AI 輔助的分流與修補建議，並由人工核准每次合併。平均修補時間（MTTR）可能改善，同時未解決的重大發現卻持續增加，兩者都應追蹤。

原文在上述 AppSec 建議中，標示了 Checkmarx 產品可支援的項目（作者也強調，重點在做法而非工具，多數工作可用其他產品或小規模人工完成）：

以上為原文所述，各產品實際功能與授權範圍請以原廠最新說明為準。

下次看到 AI 攻擊的新聞標題時，先問它的依據是什麼：示範、預測，還是經過調查的真實入侵？Mandiant、Verizon 與 Microsoft 的事件應變與資料外洩資料指出，入侵仍然是從可被利用的程式碼，以及權限過大的憑證進來。AI 讓攻擊者更快、更有效率，但並未改變他們鎖定的目標。這些問題很老，也都是可以解決的。

作者建議的行動：自己讀 M-Trends 2026 與 Verizon DBIR（並留意樣本偏誤），檢視安全預算有多少是投在炒作上；檢討安全計畫，找出加快分流與修補的機會，並把偵測往軟體開發生命週期（SDLC）更早期移動；盤點 AI 代理程式、模型與工具，並據此更新威脅模型。

高田觀點

從鑑識調查的角度看，這份整理與我們的實務經驗一致：事件還原時，起點通常是一個未修補的對外系統、一把外洩的權杖，或一個權限過大的帳號。AI 是否參與攻擊，往往很難從證據中判定，更值得投入的是留存足夠的日誌與權杖使用紀錄，讓調查人員能夠重建入侵路徑與時間軸。