AI Agent 拉低試錯成本，SSO 信任鏈成防線焦點
一宗針對台灣政府相關系統的網絡攻擊，被視為 AI Agent 參與攻防的一次重要警號。iThome 報道引述 Dream Security 的調查指，攻擊行動歷時約四日、分為 12 波，曾同時部署最多 8 個 Agent，最終取得 85 組政府人員帳密及至少 2,564 筆人員資料，並把偵察範圍延伸至資訊供應商、核能安全機構及能源業者。
不過，事件歸因仍未完全證實。Dream Security 只按系統內部報告所用的簡體中文，以及目標分析採用繁體中文，推斷攻擊者為中文使用者；iThome 指出，台灣數位發展部翌日證實政府監控單位在 7 月發現境外攻擊，但這不等於攻擊者身分已有定論。
重點不在「AI 找到新漏洞」
iThome 報道所描述的入侵關鍵，多是資安團隊耳熟能詳的問題：未受驗證保護的 API、遺留在正式環境的除錯端點、JWT 驗證設定失當、弱密碼，以及系統對上游 SSO 驗證結果的過度信任。當中亦有攻擊路徑未能得逞，顯示多層防護仍可截斷攻擊。
改變在於，Agent 可把偵察、文件分析、弱點驗證與優先排序拆分並行處理；某條路徑失敗後，系統可把資源轉往其他假設，並將有效結果回饋下一輪行動。Dream Security 將之定義為「近自主式」攻擊，並非完全毋須人手介入的攻擊系統。
這帶來的防禦問題很實際：過去因為攻擊者人手有限而長期未被發現的「小問題」，在低成本、大量試錯下更容易被串連成完整入侵路徑。換言之，企業不應只以單一漏洞的嚴重程度排優次，還要看它能否接上既有的身分、權限與供應鏈信任關係。
SSO 是加速器，也可能放大橫向移動
iThome 指出，攻擊者取得帳密後，85 組憑證中有 84 組可登入另一套內部系統。調查認為，原因是相關系統直接信任上層 SSO 的驗證結果，未再要求額外身分驗證或多因素驗證。
這不是說 SSO 本身不安全；集中身分管理通常有助統一政策與審計。但它同時令一個帳戶失守的影響面取決於下游系統的信任設計。對使用 SSO、雲端 API 和第三方整合的機構而言，以下檢查可優先處理：
- 盤點每個 SSO 應用程式可存取的系統與敏感操作，為高風險情境加入再驗證或多因素驗證。
- 清查正式環境是否遺留開發、測試或除錯 API，並確保管理、帳戶與資料介面均有合適的身分驗證及授權。
- 檢視 JWT 驗證規則，確認只接受預期的簽章演算法、簽發者與受眾，拒絕不符合政策的 token。
- 為登入設置針對密碼噴灑的偵測與限制，例如按帳戶、來源及異常模式建立風險控制；不要把 CAPTCHA 視為唯一防線。
- 定期檢視供應商、外包系統及管理介面的外露情況，因為一條信任鏈往往跨越多個團隊與組織。
CAPTCHA 不是身分防護的替代品
iThome 報道稱，該攻擊系統利用 OCR 辨識驗證碼，紀錄顯示成功率達 100%。個案不能直接代表所有 CAPTCHA 的效果，但足以提醒團隊：圖像驗證最多只是摩擦力，難以單獨承擔帳戶防護職責。密碼政策、多因素驗證、風險式登入控制、異常告警及回應流程，仍要一同運作。
下一步值得觀察的是，防守方能否把資產盤點、身分風險分析與修補驗證也自動化。當攻擊者可平行測試大量已知弱點時，遺留系統、跨系統 SSO 與第三方整合，會是最先需要重新量度風險的範圍。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — AI網攻兵臨城下：從臺灣受駭事件看AI自主攻擊掀起的典範轉移 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
