每分鐘 2,900 次登入嘗試：ConnectWise 攻擊對第三方應用程式信任的啟示
2,900 sign-in attempts a minute: what the ConnectWise campaign teaches about third-party application trust
Microsoft 將針對 ConnectWise 客戶 Microsoft 365 環境的供應鏈攻擊歸因於 Storm-0940，事件涉及高權限第三方應用程式及後續目錄操作。
文章將 ConnectWise 事件中的密碼噴灑、應用程式憑證持久化與目錄權限風險，轉化為檢查第三方高權限應用程式的具體控制項。
每分鐘 2,900 次登入嘗試：ConnectWise 攻擊行動帶來的第三方應用程式信任啟示
Microsoft 將針對 ConnectWise 客戶 Microsoft 365 環境的供應鏈攻擊，歸因於一個與中國國家立場一致、並由其追蹤為 Storm-0940 的組織。歸因是新聞焦點；攻擊手法則改變了防守者應如何看待其租戶內每一個高權限第三方應用程式。
攻擊流程
Microsoft Security Research 報告指出，早在 2026 年 9 月，Storm-0940 已使用名為 ARTEX 的代理式 AI 滲透測試框架，自動化攻擊數百個組織，涵蓋航空航天與國防、汽車、化工、能源、金融服務、政府、法律、製造、媒體、軍事、半導體、軟件、科技、智庫及非牟利機構等多個行業。
在 ConnectWise 遭入侵前，該組織發動了一場最終失敗的密碼噴灑攻擊。截至 10 月 14 日的四天期間，攻擊者針對八個組織的 327 個 Microsoft 365 和 Exchange Online 帳戶，產生超過 151,000 次登入失敗紀錄，最高約達每分鐘 2,900 次。
翌日，該組織轉而攻擊 ConnectWise，利用 AI 代理程式及同一套惡意基礎設施，入侵多家 ConnectWise Cloud Backup 客戶所屬的 Microsoft 365 環境。
為何失敗的密碼噴灑攻擊仍值得關注
151,000 次登入失敗是發動攻擊的證據，而非遭入侵的證據。這亦反映防守者的反應時間。以每分鐘接近 2,900 次嘗試的速度，若某項控制措施要等到失敗次數達數百次後才偵測並封鎖密碼噴灑攻擊，那麼在有人作出回應之前，攻擊行動早已完成。時間線顯示，該組織改變的是目標，而非手法。
這正是自動化攻擊工具所產生的節奏。Microsoft 表示，ARTEX 是一套由 LLM 驅動的代理系統，能以極少的人手介入，自主執行從偵察到資料外洩的滲透測試；該系統可配合任何 AI 模型使用，來自不同地區的多個威脅行為者亦正在使用它。
代理程式觸及的範圍
Microsoft 報告指出，在部分受害者環境中，AI 代理程式不止完成驗證，還進一步執行 Microsoft Graph 和目錄操作。列出的活動包括偵察、修改應用程式認證以建立持續性，以及涉及身分、羣組和特權角色的變更。
這份清單描述了一種轉移：第三方應用程式是入侵入口，而目錄則是其背後的目標。Microsoft 在多個客戶環境中觀察到後續活動的證據，並指出，遭入侵且持有高權限的第三方應用程式，可能提供超出其原定用途的存取權限。
Microsoft 沒有説明有多少客戶遭到入侵，並補充指出，成功驗證並不一定代表該組織曾存取或竊取資料。這兩項限定説明都很重要。目錄變更是有實際證據支持的真實事件，而成功登入則只是一項先決條件。
這次攻擊行動利用的控制措施
任何檢視過 OAuth 授權的人都會認出這種模式。應用程式通常只需取得一次同意（通常是為了合法整合），之後便會以自身身分而非用戶身分進行驗證。為人類登入而設計的多重因素驗證（MFA）無法限制它。以用戶為範圍設定的條件式存取政策可能無法涵蓋它。審查應用程式取得的授權，與審查應用程式供應商本身的安全狀況，是兩回事；ConnectWise 個案提醒我們，備份產品也可能擁有整個租用戶範圍的存取權。
根據報道所述活動可進行的具體檢查：
- 列出每個租用戶中所有擁有目錄層級權限的應用程式，然後確認哪些確實需要對身分、羣組或角色擁有寫入權限。
- 檢視現有應用程式新增憑證的情況。報道所述的技術會修改應用程式憑證以建立持續存取；以用戶為中心的審核很容易漏掉舊應用程式新增的密碼。
- 以已知基準比較羣組及角色成員名單，讓涉及特權角色的變更以差異形式浮現，而不是等到事後才發現。
- 檢查登入風險政策是否適用於服務主體和工作負載身分，而不只是互動式用戶。
復原進度
ConnectWise 在襲擊後的星期六暫時關閉服務，並表示於隨後的星期三開始分階段恢復服務。公司建議客戶繼續停用連線，並表示復原需時數日。微軟執行副總裁將這次行動形容為自 10 月初以來一波由 AI 驅動的網絡攻擊中的眾多事件之一。
對受影響客戶而言，實際處理次序應與供應商的服務恢復時間表分開考慮。連線保持停用期間，輪替租用戶可觸及的憑證，檢視事件期間發生的目錄變更，然後重新核對權限範圍，再逐一重新啟用整合功能。
尚未解決的問題
報道沒有説明入侵 ConnectWise 自身環境的最初途徑，沒有量化有多少下游租用戶確認發生資料存取，而非僅有目錄修改，也沒有公佈惡意基礎設施的指標。微軟的説法亦沒有交代針對八個機構的密碼噴灑攻擊與其後的 ConnectWise 行動是否使用相同基礎設施，只指出後者涉及相同基礎設施。這些資訊缺口意味著，你仍需依靠自己的遙測數據進行偵測：應用程式憑證變更、新增的授權同意，以及變更時段以外的角色指派。
參考資料
- CyberScoop，《微軟將 ConnectWise 供應鏈攻擊歸因於與中國政府立場一致的威脅組織》，2026年10月21日： https://cyberscoop.com/microsoft-attributes-connectwise-supply-chain-attack-china-storm-0940/
- CyberScoop，較早前有關 ConnectWise Cloud Backup 供應鏈攻擊的報道： https://cyberscoop.com/connectwise-cloud-backup-supply-chain-attack/
- Microsoft Security Blog，《Storm-0940 在 ConnectWise 供應鏈入侵事件中使用 ARTEX 代理式 AI》，2026年10月21日： https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
- ConnectWise 信任公告： https://www.connectwise.com/company/trust/advisories
來源：DEV Community · dev.to