事故摘要

ConnectWise ScreenConnect CVE-2024-1709 事件突顯 RMM 平台事件會沿著維運供應鏈向多客戶擴散。

本案例的演示焦點：RMM 平台 auth bypass → 維運通道接管 → 客戶環境同時受影響的 fan-out 模式。跟 Kaseya 類似但 entrypoint 是 web admin 認證繞過、屬 entrypoint-side supply-chain 變體。

攻擊路徑

1. 利用 RMM 平台漏洞取得管理能力。
2. 接觸維運節點與客戶端連線能力。
3. 透過既有信任路徑擴大影響範圍。

失效控制面

• RMM 節點權限集中且邊界分離不足。
• 客戶環境缺少獨立限制與跳板治理。
• 事件時的連線停用與重授權流程準備度不足。

如果 workflow 少一步會發生什麼

若少了「RMM 事件後連線總開關」步驟，攻擊者可沿既有管理通道持續操作下游資產。

可落地的 workflow 檢查點

• 共同基線：以 runbook 與 incident timeline 固定記錄觸發條件與處置節奏。
• 發布前：將 RMM 權限與客戶域做嚴格分域（管理介面強制 MFA + 來源限制、客戶側端點不直連管理平面），mechanism 是讓平台漏洞不直接通到客戶資產。
• 日常：建立遠端管理連線基線與稽核節奏（哪個 operator 在哪個時段對哪個客戶進行哪類操作的 audit trail）。
• 事故中：先關閉高風險連線、再分批重啟授權（前提是事先有「總開關」設計、不臨時找)。

從本案例到實作的 chain

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

• 控制面：7.3 入口與伺服端保護 + 7.6 供應鏈完整性與 artifact 信任 —— mitigation 的 mechanism / 前提 / context-dependence 在這裡定義。
• 演練 / 控制落地：Supply chain artifact drill + Vulnerability response pattern + Control owner pattern —— 把樣式轉成漏洞處理、跨組織 owner 分工。
• 跨章交接：backend/08-incident-response 的跨團隊升級路由、backend/05-deployment-platform 的維運平台治理。

供應鏈類事故不對應紅隊 problem-cards，主要 chain 直接從控制面起步。

來源