佢哋使用 Microsoft Graph API 進行大規模目錄掃描。Graph API 係 Microsoft 365 同 Azure 嘅核心介面,可以程式化查詢用戶、群組、應用程式同角色資料。
微軟觀察到攻擊者用 自製 Python 腳本自動發送 Graph API 查詢,批量列出:
之後再透過名稱模式同角色屬性去搜尋可能擁有高權限嘅帳戶。
呢一步令攻擊者可以完整「畫出」整個雲端身份架構,為之後嘅權限提升鋪路。
其中一個關鍵技巧係濫用 Self‑Service Password Reset(SSPR)。
SSPR 本來係用嚟幫用戶自己重設密碼嘅功能,但如果攻擊者已經取得帳戶或恢復機制,就可以利用呢個流程建立更穩定嘅存取權。
由於 SSPR 係正常功能,相關操作通常會被記錄為一般身份驗證活動,令惡意行為更難被即時發現。
完成偵察之後,攻擊者開始透過雲端控制平面提升權限,而唔係傳統系統漏洞。
兩個關鍵機制包括:
透過識別高權限角色同帳戶,攻擊者可以逐步取得更高管理權限,令存取範圍擴展到更多雲端服務。
成功提升權限後,Storm‑2949 攻擊者存取多種 Azure 資源,包括:
呢啲服務通常儲存:
因此一旦被入侵,影響範圍可以非常大。
Storm‑2949 能夠長時間保持低調,主要原因係攻擊者完全使用合法管理工具。
微軟發現佢哋使用咗多種 Azure 管理功能,例如:
因為呢啲工具本來就係系統管理員日常會用,所以喺日誌入面睇落往往同正常操作差唔多。
呢種策略令攻擊者可以橫向移動同操作資源,同時降低被安全系統偵測到嘅機會。
調查顯示,攻擊最後階段涉及 持續幾日嘅資料外洩活動。
呢代表攻擊者成功保持長時間存取權,並逐步抽取受害組織嘅敏感資料,而冇即時觸發防禦系統。
Storm‑2949 事件反映雲端安全一個重要變化:身份系統已經成為主要攻擊面。
原因包括:
當攻擊完全發生喺可信雲端服務入面,傳統端點安全工具往往幾乎偵測唔到異常。
為減少類似攻擊風險,Microsoft 建議企業加強雲端身份安全同監控。
加強身份保護
確保單一帳戶被攻陷時,不會導致整個租戶環境被接管。
審視 SSPR 設定
特別係高權限帳戶,避免帳戶恢復流程被濫用。
強制多重身份驗證(MFA)同 Conditional Access
令被盜憑證難以直接使用。
監控 Microsoft Graph API 活動
留意異常嘅目錄枚舉或自動化查詢。
審核 Azure RBAC 權限
定期檢查角色分配並實施最小權限原則。
監控管理工具使用情況
例如 VMAccess、Run Command 或 PowerShell 出現異常操作時應觸發警報。
加強對關鍵 Azure 資源嘅監控
包括 Key Vault、資料庫同生產 VM。
Storm‑2949 最重要嘅教訓係:雲端攻擊已經由漏洞轉向身份控制。
當攻擊者控制咗一個帳戶,就可以利用 API、權限系統同官方管理工具慢慢擴大影響範圍,而完全唔需要部署惡意程式。
對企業安全團隊而言,防禦重點已經唔只係端點防毒,而係要全面監控:
否則,一個帳戶就足以打開整個雲端環境嘅大門。