JadePuffer 攻向 Azure：雲端破壞可壓縮至數分鐘

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-30

iThome 報道，微軟近日披露兩宗發生於 6 月、針對 Azure 環境的 JadePuffer 攻擊個案，並以 Storm-3168 追蹤相關活動。攻擊者利用已失陷的 Service Principal 進入受害者租戶，先盤點資源及取得儲存帳戶金鑰，再對多類核心服務發出刪除操作。對使用 Azure 承載業務資料、應用程式或備份的企業而言，這類事件的風險不只在於資料外洩，也在於營運資源可在很短時間內被集中破壞。

最重要的限制是，微軟暫未能確認兩宗事件的初始入侵途徑；因此，不能直接斷言 GitHub、某一種設定錯誤或某個漏洞就是入侵源頭。微軟只發現，攻擊中使用的其中一組 Service Principal 憑證曾出現在 GitHub 公開 Issue。另一方面，iThome 指出，部分儲存帳戶因資源鎖及保護措施而未受影響，而刪除 SQL 資料庫和復原保護鎖的嘗試亦告失敗；這些細節說明防線並非全數失效，但覆蓋範圍與執行速度會決定事故的損害上限。

七分鐘揭示的雲端破壞節奏

iThome 報道指，攻擊者在兩宗個案中針對逾 100 個儲存帳戶，以及 SQL 資料庫、Key Vault、Function Apps、虛擬機器、App Services 和復原保護鎖進行刪除操作，整段破壞行動約持續 7 分鐘。若資源清單、權限關係及可用金鑰已被整理，攻擊者便毋須逐項人工尋找目標，能把大量控制平面的刪除請求集中送出。這會令傳統依賴人手察看告警、再逐層確認影響的應變流程面對明顯時間壓力。

這宗事件的分析重點，在於 Service Principal 已不只是部署自動化的便利帳號。一旦其憑證失陷，且權限橫跨多個資源群組或訂閱範圍，它可成為攻擊者持續呼叫 Azure 管理介面的入口。從 iThome 所述的受害資源範圍推論，團隊應把「某帳號能否登入」以外的問題提前回答：它能讀取哪些金鑰、可否刪除哪些資源、是否可觸及復原相關設定，以及是否有足夠監察在大量刪除開始時提出警報。

AI 代理加速流程，並非已證實獨立決策

iThome 引述 Sysdig 在今年 7 月的披露，指 JadePuffer 曾利用 AI 代理自動處理偵察、竊取憑證、橫向移動及資料加密等攻擊步驟，之後把範圍延伸至 AI 資產、訓練資料集及向量資料庫。微軟披露的 Azure 個案則顯示，雲端資源盤點、取得儲存帳戶金鑰與批量刪除，能構成一條高度連貫的破壞鏈。

不過，現有資料不足以證明 AI 代理在這兩宗 Azure 事件中獨立選擇目標或自行作出最終攻擊決定。較穩妥的理解是，攻擊者可利用自動化及代理能力縮短資料蒐集、指令編排和重複執行所需時間。這個分別影響防守策略：企業不應把風險簡化成「AI 變得有自主意志」，而要假設已失陷身分憑證可配合自動化，在人手反應前迅速放大權限所造成的後果。

防護要由 GitHub secret 一直延伸到復原控制

對 Azure 與 GitHub 並用的開發團隊，首要工作是盤點每個 Service Principal 的用途、擁有者、有效憑證、存取範圍及可執行的刪除權限。部署、測試、備份和日常維運不應共用一組權限過大的身分；對不再使用或無法確認責任人的 Service Principal，應優先停用、撤銷或更換憑證。這不是單純帳號清潔工作，而是減少單一外洩憑證可控制的資源面積。

GitHub 一端則要把公開 Issue、程式碼庫、文件和自動化設定納入 secret 管理範圍。既然微軟發現其中一組攻擊所用憑證曾出現在公開 Issue，團隊應定期搜尋 Azure 憑證、金鑰和連線資料是否被誤貼，並在發現後立即撤銷及重發，而非只刪除可見文字。審核也應延伸至過往討論紀錄及外部協作流程，因為已被複製的 secret 無法靠原頁面刪除而自動失效。

資源保護方面，可把 Storage、Key Vault 與 SQL 資源按業務重要程度設定資源鎖，並定期核對鎖定是否涵蓋真正需要保留的生產資料與備份依賴項。iThome 所述部分儲存帳戶因鎖定及保護而避過刪除，正好顯示這類控制可爭取復原時間；但鎖本身亦需配合最小權限，避免同一失陷身分同時具備刪除資源和移除保護的能力。

復原設定同樣不可只在事故後才驗證。團隊應檢視備份、保留資料、復原權限及 Recovery Protection Lock 的配置，並測試在主要 Storage、Key Vault 或 SQL 資源遭誤刪或惡意刪除時，能否按既定復原程序取回所需資料。由於 iThome 報道中刪除復原保護鎖的嘗試未成功，復原控制應被視作獨立的一層防線，而不是附屬於日常管理帳號的選項。

偵測重點是關聯異常，而非單一刪除事件

監察規則可把異常身分登入、短時間的大量資源枚舉、讀取儲存帳戶金鑰，以及跨服務的大量刪除請求串連檢視。單一資源刪除未必代表攻擊，但當一個 Service Principal 在短時間觸及 Storage、SQL、Key Vault 和應用服務，風險判斷便應升級，並準備迅速停用相關身分及保全紀錄。這類關聯監察較貼近事件中「先偵察、後破壞」的節奏。

香港企業、初創與開發團隊若以 Azure 和 GitHub 支援客戶服務、內部系統或產品交付，應優先核實上述控制是否落在實際生產環境，而非只存在於政策文件。現時未見來源提及香港受害個案，亦未能確認 JadePuffer 的初始入侵方法；下一步值得觀察的是微軟會否披露更多取證結果，以及其他組織能否從失陷身分、公開 secret 和資源保護設定中，找出相近的暴露面。