Security
Google 抓到疑似 AI 生成零時差攻擊：資安攻防的加速點在「邏輯漏洞」
Threads 提到 Google Threat Intelligence 發現疑似由 AI 輔助生成的零時差 2FA bypass exploit。真正重要的不是「AI 也會寫惡意程式」這句話，而是 LLM 開始協助攻擊者找出傳統掃描器不容易抓的高層語意/邏輯漏洞，並加速 CVE 分析、payload 生成與自動化攻擊鏈。
2026年5月12日2 分鐘閱讀👁 5
AI security / vulnerability discovery
Google 抓到疑似 AI 生成零時差攻擊：重點是「邏輯漏洞」開始被模型加速發現
Threads 貼文提到 Google 發現第一個疑似由 AI 協助生成的 zero-day 2FA bypass exploit。這件事真正值得記錄的，不是「AI 會寫惡意程式」這種泛泛結論，而是 LLM 可能特別擅長協助攻擊者找出傳統掃描器難以捕捉的高層語意與邏輯漏洞。
先校正一點：Google / The Hacker News 報導沒有說一定是 Gemini 寫出這支 exploit，也沒有公開受影響工具名稱。Google Threat Intelligence 的判斷是：該 Python exploit 具有高度 LLM-generated code 特徵，並很可能被 AI 系統用於漏洞發現與武器化。
這次案例是什麼
Google Threat Intelligence Group 分析到一個 zero-day exploit，以 Python 寫成，可在一個熱門開源 web-based system administration tool 中繞過 2FA。該漏洞需要有效帳密才能利用，但可繞過第二因素驗證。
為什麼 Google 懷疑是 AI 生成
報導提到 exploit code 有大量教育式 docstrings、完整 type hints、結構化且 textbook Pythonic 的格式，甚至包含 hallucinated CVSS score。這些不是定罪證據，但組合起來很像 LLM 生成程式碼。
真正可怕的是 logic flaw
這不是傳統「掃描器看到危險函式」的漏洞，而是 hard-coded trust assumption 造成的高層語意邏輯錯誤。LLM 讀程式時可能更容易從「開發者意圖」與例外條件矛盾中看出問題。
攻擊鏈被全面壓縮
Google 與報導列出更多濫用跡象：APT45 用大量 prompts 分析 CVE 與驗證 PoC；中國相關組織要求 Gemini 扮演資安專家研究 TP-Link firmware / OFTP；APT27 用 Gemini 加速 ORB 管理工具開發；也有攻擊者把真實漏洞案例包成 Claude Code skill plugin。
| 舊資安自動化 | AI 加速後的差異 |
|---|---|
| 掃描已知 pattern / dangerous API | 推理高層語意、權限流程與例外條件是否矛盾 |
| 人工讀 CVE、改 PoC | 批量 prompt 做 CVE 分析、PoC 驗證與 payload 變體 |
| 腳本品質常露出攻擊者手工痕跡 | 惡意程式也可能有乾淨 docstrings、type hints、help menus |
| 防禦靠規則與 signature | 防禦需要語意級 review、威脅建模、行為觀測與 AI code provenance 判斷 |
防禦上的直接啟示
- 2FA / auth flow 不只要測 happy path，也要測 exception path、fallback path、trust boundary。
- 傳統 SAST/DAST 不足以抓語意漏洞；需要 threat modeling + property-based tests + auth-state machine tests。
- 不要用「code 很乾淨」判斷安全；LLM 生成的惡意程式也可能很像教科書範例。
- 企業要準備面對更短的漏洞武器化週期：patch、WAF rule、log detection、credential reset playbook 都要提速。
- AI coding / security plugins 如果內建真實漏洞資料庫，必須管控來源、授權、濫用風險與審計記錄。
數字 caveat：Threads 提到 Claude Code 插件含 85,000 筆漏洞資料；The Hacker News 轉述 Google 的說法是名為 wooyun-legacy 的 Claude Code skill plugin，包含 WooYun 2010–2016 年間 5,000+ real-world vulnerability cases。本文採較可核對的 5,000+，不沿用 85,000。