事故摘要

ESXiArgs 事件顯示 CVE-2021-21974 與 CVE-2021-21972 這類虛擬化平台漏洞可轉為大規模勒索與服務中斷，回復節奏成為關鍵控制面。

本案例的演示焦點：虛擬化平台舊漏洞（patch-available 但未套用）→ ESXi host 加密 → 大量 VM 同時不可用的 mass-ransom 事件。重點在「回復節奏 vs 業務優先級」設計、exfiltration 本身是次要面向。

攻擊路徑

1. 利用已知 ESXi 漏洞取得主機控制能力。
2. 執行加密或破壞作業影響虛擬機。
3. 造成資料可用性與業務連續性衝擊。

失效控制面

• 虛擬化平台修補節奏與資產可見性不足。
• 快照、備份與復原演練覆蓋不足。
• 事故中回復優先級路由不夠明確。

如果 workflow 少一步會發生什麼

若少了「回復優先級排序」步驟，團隊會在高壓情境下延長核心服務停擺時間。

可落地的 workflow 檢查點

• 發布前：定義核心服務的 RTO 與 RPO（依業務重要性分層、不平均對待），mechanism 是讓事件期間的回復排序有預先決定的依據。
• 日常：演練備份還原並記錄 MTTR（含「整個 hypervisor fleet 同時離線」的壓力測試）。
• 事故中：先恢復核心服務、再分批回補次要工作負載（前提是備份跟受影響 hypervisor 是 air-gap、不會同步加密）。

從本案例到實作的 chain

本案例是事故敘事 layer，沿三步 chain 進入 implementation：

• 控制面：7.10 資料 residency / 刪除與證據鏈 + 7.13 安全事件路由 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
• 演練 / 控制落地：Recovery readiness pattern + Vulnerability response pattern + Evidence chain pattern —— 把樣式轉成回復演練、漏洞處理與證據鏈欄位。
• 跨章交接：backend/06-reliability 的備援與回復策略、backend/08-incident-response 的回復決策流程。

本案例屬於 mass-ransom 事件、不對應紅隊 problem-cards，主要 chain 直接從控制面起步。

來源