Google Threat Intelligence Group 在 2026 年 5 月 11 日發布了新的 AI Threat Tracker。報告裡最值得注意的不是「攻擊者開始用 AI」這件事本身，而是使用方式正在從輔助寫作、翻譯、偵察，進入漏洞研究、PoC 驗證、惡意程式碼混淆和自動化攻擊編排。
這裡有兩個容易被混在一起的點，需要先拆開。
第一，Google 表示他們首次發現了一個高度疑似由 AI 輔助開發的零日漏洞利用。這個案例來自未具名的網路犯罪團伙，目標是一個流行的開源 Web 系統管理工具，漏洞可在已有帳號憑證的前提下繞過 2FA。Google 表示已與受影響廠商協作披露，並可能阻止了一次大規模利用。
第二，APT45 不是這起零日案例的歸因對象。GTIG 另行提到，與北韓相關的 APT45 被觀察到向 AI 模型發送大量重複提示，用於遞迴分析不同 CVE，並驗證 PoC exploit。這說明 APT45 正在把 AI 當成漏洞研究和武器庫整理工具，而不只是用 AI 寫釣魚郵件。
AI 零日案例說明了什麼
這起零日並不是傳統上最常見的記憶體破壞、輸入過濾缺陷或簡單設定錯誤。GTIG 把它描述為一個高層語義邏輯問題：開發者在認證流程裡硬編碼了某種信任假設，導致 2FA enforcement 邏輯和例外條件之間出現矛盾。
這類漏洞對傳統掃描器不友好。靜態分析和 fuzzing 更擅長找崩潰、危險函式、輸入輸出路徑和已知模式。它們不一定能理解「開發者本來想保證什麼，卻在哪個例外裡破壞了這個保證」。
大模型的風險就在這裡。它不一定比專業安全研究員更強，但它擅長讀上下文、解釋意圖、比較相似程式碼路徑，並指出「這裡的業務邏輯前後不一致」。當這種能力被攻擊者接入自動化流程後，原本需要資深研究員長時間閱讀的邏輯漏洞，可能更容易被批量篩出來。
GTIG 還提到，這段 exploit 程式碼裡有不少 AI 生成痕跡，例如教育式 docstring、虛構的 CVSS 分數，以及接近教材風格的 Python 結構。Google 同時說明，他們不認為 Gemini 被用於該 exploit，但對攻擊者使用某個 AI 模型輔助發現和武器化漏洞有較高信心。
APT45 的變化更值得長期關注
APT45 長期被視為北韓相關威脅組織，活動目標涵蓋間諜、金融收益和戰略情報。GTIG 這次強調的是它使用 AI 的方式：大量、重複、遞迴地分析 CVE，驗證 PoC exploit，並把結果沉澱成更可靠的攻擊能力。
這和「讓 AI 寫一段腳本」不是一個量級。
如果一個組織能把 AI 接入漏洞篩選、PoC 驗證、payload 調整和測試環境，那麼它的人力瓶頸會改變。過去，一個團隊能同時研究多少漏洞，取決於研究員數量、經驗和時間。現在，AI 可以承擔一部分重複閱讀、歸納、變體測試和初步判斷，讓人的精力更多放在挑選目標、驗證可用性和實戰投遞上。
對防守方來說，這意味著已知漏洞的窗口期會更短。
一個 CVE 披露後，攻擊者不需要從零讀公告、找補丁 diff、搭環境、改 PoC。AI 可以幫助它更快理解影響範圍、生成測試思路、排查失敗原因，並把不同目標版本裡的細節差異整理出來。即使 AI 生成的結果需要人工修正，它也足以提高整體吞吐量。
這不是「AI 自動黑掉一切」
也沒必要把這件事理解成 AI 已經可以獨立完成完整入侵。
GTIG 的報告更像是在說：攻擊鏈裡的多個環節正在被 AI 加速。漏洞研究、惡意程式碼混淆、偵察、社交工程、資訊操作、行動端 UI 自動化、供應鏈投毒，都已經出現了 AI 參與的跡象。
但 AI 仍然會犯錯。它可能幻覺漏洞、誤判可利用性、生成不可執行程式碼，也可能在複雜企業權限邏輯裡迷路。真正危險的地方不是 AI 完美無缺，而是攻擊者可以低成本試錯。只要大規模嘗試足夠便宜，一部分錯誤輸出就會被過濾掉，剩下的可用結果會進入攻擊流程。
這也是 APT45 這類案例值得關注的原因：國家級或準國家級組織不缺目標和耐心。如果 AI 能把重複勞動壓縮掉，它們就能把更多資源投向真正高價值的目標。
防守重點要從「有沒有零日」擴展到「窗口期多短」
很多企業過去會把風險分成兩類：已知漏洞靠補丁管理，零日漏洞靠縱深防禦。但 AI 進入漏洞研究後，這條邊界會變得更模糊。
更現實的問題是：
- 新 CVE 披露後，外部攻擊者多久能形成可用 exploit？
- 企業資產清單能否在同一天告訴你哪些系統受影響？
- WAF、EDR、日誌和身份系統能否發現異常嘗試？
- 高風險系統是否預設啟用 MFA、最小權限和網路隔離？
- 開源元件、AI agent 外掛、第三方連接器是否進入供應鏈審查範圍？
AI 零日不會讓基礎安全失效。相反，它會懲罰那些基礎安全長期欠帳的環境。
如果補丁週期很慢，資產清單不清楚，網際網路暴露面沒人負責，日誌不可檢索，帳號權限長期過大，那麼攻擊者是否使用 AI 只是效率差異。問題遲早會被撞上。
AI 供應鏈也成了攻擊面
GTIG 報告還提到，攻擊者開始關注 AI 軟體生態本身，包括 agent 技能包、第三方資料連接器、開源包裝庫和自動化框架。風險不一定來自模型被「攻破」，而是來自模型周圍的工具鏈被投毒。
這點對使用 AI 編程、AI Agent、自動化外掛的人很重要。
一個惡意 skill、一個帶後門的依賴、一個過度授權的連接器，都可能讓 AI 系統從「幫你做事」變成「替攻擊者做事」。當 agent 擁有檔案系統、瀏覽器、終端、雲帳號或企業資料權限時，供應鏈審查就不能停留在傳統應用層。
至少應該做到：
- 不隨便安裝來源不明的 agent skill 和外掛。
- 對能執行命令、讀取檔案、存取密鑰的工具做權限隔離。
- 生產環境不要直接執行未經審查的 AI 生成腳本。
- 對 AI 專案的依賴、GitHub Actions、PyPI / npm 包做掃描。
- 對模型 API Key、雲密鑰、GitHub Token 做最小權限和外洩監控。
對安全團隊的實際建議
第一，把漏洞回應節奏前移。高危 CVE 不能只等月度補丁窗口，尤其是 VPN、閘道、系統管理面板、身份系統、CI/CD、遠端管理工具這類邊界資產。
第二，建立可查詢的資產清單。AI 加速攻擊的前提是攻擊者能快速定位目標；防守方也必須能快速回答「我有沒有這類系統、哪個版本、暴露在哪裡」。
第三，用行為偵測補足簽名偵測。AI 生成 exploit 或惡意程式碼可能會改寫表面特徵，但認證繞過、異常登入、批量探測、失敗請求模式、權限提升路徑仍然會留下行為痕跡。
第四，把 AI 工具納入安全治理。內部使用的 coding agent、瀏覽器 agent、文件 agent、自動化腳本和外掛市場，都應該有准入、審查、日誌和回滾流程。
第五，不要把 AI 防守只理解成「買一個安全大模型」。真正有用的是把 AI 放進漏洞優先級排序、日誌分析、補丁影響評估、程式碼審查和配置基線檢查裡，讓防守效率也跟上攻擊效率。
小結
GTIG 這次報告的信號很清楚：AI 正在把攻防節奏推快。
AI 輔助零日說明，邏輯漏洞和認證繞過這類問題可能更容易被模型發現。APT45 的案例說明，成熟威脅組織已經在用 AI 批量分析 CVE 和驗證 PoC。PROMPTSPY、AI 生成混淆程式碼、agent 供應鏈攻擊則說明，AI 不只是攻擊者的聊天工具，而是正在進入攻擊工具鏈。
這不是末日，但也不是普通新聞。
對企業來說，最實際的應對不是恐慌，而是把補丁、資產、日誌、身份、供應鏈和 AI 工具權限這些基礎工作做得更快、更清楚、更可驗證。AI 會提高攻擊者的試錯速度，防守方也必須提高發現、判斷和修復速度。