JadePuffer 以代理式攻擊在七分鐘內破壞 Azure 資源

事件概述

2026 年 6 月，微軟安全團隊在官方部落格（Microsoft Security Blog）公開說明了兩起利用被入侵服務主體的 Azure 攻擊案例，攻擊者代號 JadePuffer，內部追蹤代號 Storm‑3168。這兩起事件分別發生於不同的租戶環境，攻擊者首先成功取得目標租戶中服務主體的憑證，接著以該服務主體的身份作為代理，對雲端資源執行大量的讀寫與破壞指令。微軟在報告中強調，攻擊者的行動是透過自動化腳本驅動，且在取得憑證後的短時間內即展開大規模操作，顯示出高度的組織化與技術熟練度。

攻擊手法與時間線

在第一起事件中，受害服務主體在約 15 小時 30 分鐘的時間內持續進行偵察活動，完成超過 300 次的讀取操作，這些操作包括列舉資源、檢索設定與查詢金鑰資訊，為後續的破壞行動奠定基礎。相較之下，第二起事件的破壞階段更為集中與迅速，攻擊者在 35 分鐘內發起超過 150 次的破壞或憑證收集行動，其中核心的破壞序列僅持續約七分鐘，期間嘗試刪除超過 100 個儲存帳戶，顯示出攻擊者在取得足夠資訊後，會立即啟動高頻率的刪除指令，以期在最短時間內造成最大影響。

在這七分鐘的破壞階段，攻擊者首先利用取得的服務主體權限列舉目標資源清單，隨後呼叫 Azure Delete API 企圖移除儲存帳戶與其他服務。雖然部分資源已啟用資源鎖定（resource lock）或刪除保護（delete protection），成功阻擋了大量的刪除請求，但仍有相當數量的嘗試被送出，顯示攻擊者的自動化腳本具備極高的呼叫頻率與並行處理能力。這種高頻率的 API 呼叫在短時間內產生大量日誌，對於即時偵測提出了挑戰，同時也說明了防禦機制在面對自動化大規模攻擊時的壓力。

• 100+ 儲存帳戶刪除嘗試
• 150+ 破壞或憑證收集操作
• 300+ 讀取偵察請求（第一起事件）
• 30+ ListKeys 呼叫（約 30 分鐘後）

證據與來源

微軟將此類攻擊歸類為 Storm‑3168，並指出攻擊者利用取得的服務主體憑證執行代理式操作，藉由合法的 API 呼叫隱蔽其惡意行為。iThome 報導同時提到，部分服務主體憑證曾在公開的 GitHub issue 中出現，雖然這提供了憑證外洩的可能線索，但微軟在報告中明確說明尚未確認該憑證即為本次入侵的直接來源，因而保持了對憑證來源的謹慎態度。

在調查過程中，微軟未觀測到任何勒索信件的發送，也未發現明確的資料外洩跡象，顯示攻擊者的主要目標似乎聚焦於資源破壞與金鑰竊取。唯一的後續行為是在約 30 分鐘後，攻擊者成功發出超過 30 次 ListKeys 請求，這些請求顯示出攻擊者仍在嘗試取得更多金鑰資訊，以便未來可能的橫向移動或進一步的資源濫用。

影響與防禦成效

資源鎖定（resource lock）與刪除保護（delete protection）在本次攻擊中發揮了關鍵的防禦作用，成功阻止了多數儲存帳戶的實際刪除，減少了直接的資料損失。另一方面，針對 Azure SQL 的刪除嘗試因使用的 API 版本不支援而失敗，這一技術限制同樣降低了潛在的破壞範圍，說明即使攻擊者掌握了服務主體憑證，仍可能因 API 相容性問題而受阻。

儘管防禦機制阻擋了部分破壞，但攻擊者仍成功列舉資源並取得金鑰，說明僅靠資源鎖定不足以完全防止代理式入侵。微軟建議受影響租戶立即檢查所有服務主體的憑證使用情形，特別是檢視是否有過期或未受控的憑證，同時啟用條件式存取（Conditional Access）與最小權限原則（least‑privilege），以限制服務主體的權限範圍，降低被濫用的可能性。

未來的安全變化包括微軟將在 Azure 監控服務中加入對服務主體異常行為的即時警示，透過行為分析模型偵測異常的 API 呼叫模式，並加強 API 版本相容性檢查，以降低類似利用過時 API 失敗的攻擊面。企業也被提醒定期輪換服務主體密鑰，將敏感資源納入更嚴格的刪除保護政策，並在資源層級設定更細緻的存取控制，以提升整體防禦深度。