一名攻擊者、約 72 小時、橫跨應用程式、AWS、原始碼、CI/CD、執行環境與資料庫。真正改變攻防規則的，不是某個神奇的 AI 漏洞，而是 AI 把原本需要數週完成的既有攻擊手法，壓縮成企業來不及反應的機器速度。
資安事件應變公司 Sygnia 公布了一起值得所有雲端團隊重新檢視的案例：一名具財務動機的攻擊者，疑似透過代理式 AI 工作流程，在約 72 小時內擴大對大型 AWS 環境的控制，最後以中斷服務與破壞能力進行勒索。
我的看法很明確：這不是「AI 發明了全新的駭客技術」，而是企業長期累積的身分、權限、憑證與監控問題，第一次被機器速度完整串接起來。
如果我們只把焦點放在「攻擊者用了哪一個模型」，就會錯過真正需要處理的問題：防禦端仍以人工速度工作，但攻擊端已能平行列舉、產生腳本、驗證權限、重複利用憑證，並根據環境即時調整下一步。
這起事件真正特殊的地方：不是新技術，而是新節奏
根據 Sygnia 的事件分析，攻擊並未使用零日漏洞或新型惡意程式。初始入口是一個對外服務的應用程式弱點，攻擊者從中取得 AWS 存取金鑰，之後沿著四條工作流反覆擴張：
- 搜尋並竊取更多機密與憑證。
- 建立 IAM 使用者、額外金鑰、反向連線或應用層後門。
- 存取 RDS 等資料來源並外洩具有商業價值的資料。
- 操作 S3、ECS、ACL 與 SQS，展示其癱瘓服務的能力。
每取得一組新憑證，攻擊者便重新執行列舉、機密蒐集、持久化、資料存取與衝擊測試。攻擊因此不再是一條線性的路徑，而是多個同時展開、彼此增殖的「攻擊波」。
flowchart LR
A[對外應用程式弱點] --> B[AWS 存取金鑰外洩]
B --> C[權限與資產列舉]
B --> D[Secrets 與環境變數蒐集]
B --> E[原始碼與 CI/CD 濫用]
B --> F[資料存取與外洩]
C --> G[取得新身分或新金鑰]
D --> G
E --> G
G --> C
G --> H[建立持久化]
G --> I[服務中斷與勒索施壓]
這種模式最麻煩的地方，在於攻擊者不需要等待人工逐步判讀。AI 可以協助保存各憑證的權限範圍、已完成任務與下一個候選路徑，再同時產生 AWS CLI、SQL 或部署修改腳本。Sygnia 甚至觀察到同一秒內，來自相同來源與相同 User-Agent 的四組金鑰同時操作四個不同帳戶；這比較接近集中協調的自動化流程，而非單人手動切換終端機。
不過，這裡也需要保持技術上的謹慎：研究人員是根據腳本特徵、結構化報告、平行活動與極度壓縮的時間線，判斷行為與 AI 輔助或代理式工作流程一致；這些跡象很強，但不等於能直接證明某一套 AI 自主完成了整場攻擊。
這個差異很重要。資安決策不能建立在聳動標籤上，而應建立在可觀測行為與可控制風險上。
我認為企業真正輸掉的是「時間差」
傳統 SOC 的流程通常是：SIEM 產生告警、分析人員排隊檢視、跨團隊確認、申請停權或變更，最後才執行遏制。這套流程以小時計算，遇到權責不清時甚至以天計算。
但 AI 輔助攻擊可以在幾秒內完成多帳戶列舉，在幾分鐘內產生環境專用腳本，再把新取得的憑證投入下一輪攻擊。此時，即使每一條告警都成功觸發，只要必須等待人工逐筆判斷，防禦仍然會失敗。
我會用下面這個概念式來看雲端風險：
實際曝險 ≈ 可觸及的身分數 × 權限深度 × 憑證有效時間 × 遏制延遲
AI 主要放大的就是最後一項所造成的差距，同時也更有效率地探索前三項。企業若仍保留長效 Access Key、過度寬鬆的 IAM 權限、散落在環境變數與 CI/CD 內的 Secrets，再加上需要層層簽核的事件處置流程，就等於替攻擊自動化準備好燃料。
防禦不應只喊「用 AI 對抗 AI」
AI 可以協助告警關聯、日誌摘要與攻擊路徑分析，但我不認為把另一個聊天機器人接到 SIEM 就叫做 AI 防禦。真正有效的防禦，必須先把可觀測性、權限邊界與遏制動作做成可靠的工程系統。
1. 把身分當成第一道、也是最後一道邊界
- 應用程式與 CI/CD 優先使用 IAM Role、OIDC 與短效工作階段，減少長效 Access Key。
- 將人員、工作負載、部署管線與第三方整合身分分開，避免共用憑證。
- 以最小權限、Permission Boundary 與 AWS Organizations SCP 限制橫向擴張。
- 讓 Secrets Manager、Parameter Store、S3、環境變數與原始碼憑證掃描納入同一套治理範圍。
- 對新建 IAM 使用者、新增 Access Key、信任政策變更與跨帳戶 AssumeRole 設定高優先級偵測。
2. 建立跨層、可關聯的遙測資料
只看 CloudTrail 不夠，因為攻擊鏈同時穿越應用程式、Git、CI/CD、容器、資料庫與 AWS 控制平面。至少應集中保存並關聯：
- AWS Organizations 層級的 CloudTrail 與 GuardDuty 訊號。
- VPC Flow Logs、WAF、負載平衡器與應用程式存取紀錄。
- GitHub／Bitbucket 稽核紀錄與 CI Runner 執行紀錄。
- ECS、EKS、EC2 與容器執行期事件。
- Secrets 存取、RDS 查詢異常與大量資料匯出行為。
日誌還必須進入受保護、不可由一般工作負載管理者任意刪除的集中帳戶。否則攻擊者取得管理權限後，防守方連事件範圍都無法確認。
3. 偵測「攻擊波」，不要只偵測單一 API
單次 ListBuckets、DescribeInstances 或 GetSecretValue 不一定惡意；但若同一來源在短時間內使用多組新憑證，跨帳戶大量列舉權限、Secrets、資料庫與部署資源，就已經不是一般維運行為。
我會優先建立以下關聯規則：
- 新出現的 Access Key，立即進行高密度資產與權限列舉。
- 相同 IP、ASN 或 User-Agent 在極短時間內操作多個帳戶與身分。
- 讀取 Secrets 後緊接著建立 IAM 身分、修改 CI/CD 或開啟反向連線。
- ECS desired count／maximum capacity 被設為零、S3 Bucket Policy 突然拒絕存取、ACL 封鎖網路或 SQS Queue 被清空。
- 非預期地大量查詢 RDS schema、跨多個資料庫執行不同 SQL，接著產生大量輸出流量。
偵測的單位應從「一個 API 是否可疑」，提升為「一組身分是否正在以機器速度完成完整攻擊意圖」。
4. SOAR 的重點是可靠遏制，不是自動化數量
高風險事件一旦達到足夠信心，系統應能在分鐘內執行預先核准的遏制動作，例如：
- 停用疑似外洩的 Access Key，並強制輪替相關 Secrets。
- 對高風險角色套用臨時 Deny Policy 或隔離用 SCP。
- 暫停受影響的部署管線與 Runner，避免後門持續進入正式環境。
- 封鎖已確認的惡意來源，限制敏感資料的讀取與匯出路徑。
- 保留快照、CloudTrail 與必要鑑識資料，再進行復原與根除。
但自動化必須有防誤殺設計：低風險動作可以全自動，高爆炸半徑動作則採雙人核准、短時效隔離與可回復變更。好的 SOAR 不是「按一個按鈕做很多事」，而是讓正確的遏制動作在最短時間內安全發生。
給技術主管的四個驗證問題
與其再買一套標示 AI 的資安產品，我更建議先做一次跨團隊演練，確認以下問題能不能在 15 分鐘內回答：
- 任一 AWS Access Key 外洩時，我們能立即知道它可以碰到哪些帳戶、資料與部署流程嗎？
- 同一組 Secrets 是否同時存在於應用程式、容器、S3、CI/CD 與開發人員電腦？
- SOC 是否有權在不等待長時間簽核的情況下，先隔離身分與部署管線？
- 如果攻擊者同時操作四個帳戶，我們看到的是四張孤立告警，還是一場正在擴散的事件？
只要其中一題答不出來，問題就不只是工具不足，而是身分治理、責任邊界與事件流程尚未準備好面對機器速度。
結語：AI 沒有讓基本功失效，反而讓基本功變得更殘酷
這起事件給我的最大提醒，不是「未來的攻擊很可怕」，而是未來已經發生：熟悉的雲端弱點、熟悉的憑證外洩、熟悉的過度權限與熟悉的監控斷點，被 AI 以更快、更廣、更平行的方式組合起來。
因此，企業現在最需要的不是追逐「AI 資安」標籤，而是縮短憑證壽命、降低權限深度、打通跨層遙測、預先定義遏制程序，並把 MTTD 與 MTTR 從報表指標變成工程目標。
攻擊者已經把時間當成武器；防禦端也必須把時間當成架構需求。