JadePuffer/Storm-3168：代理式行為者在 7 分鐘的破壞性爆發中刪除 Azure 租用戶的儲存體

Microsoft Security Research 於2026 年 9 月 25 日報導，一個使用兩個遭入侵服務主體的攻擊者於 2026 年 6 月初在一個未具名的 Azure 租用戶內活動，先進行超過 15 小時的偵察，接著在約七分鐘內嘗試刪除超過 100 個儲存體帳戶，並成功刪除其中大多數，還刪除了一個 Azure Key Vault、一個 Function App 和一個 App Service 方案。Microsoft 將此入侵歸因於其追蹤代號為 Storm-3168的攻擊者，安全公司 Sysdig 稱其為 JADEPUFFER，並於 2026 年 7 月記錄其為首個由大型語言模型端到端執行的勒索軟體行動。Microsoft 表示未發現勒索信，也未確認有任何資料被外洩。該檔案庫將此行動記錄為高嚴重性事件，已確認涉及 AI 且造成實際損害，而 Orca AI Incident Archive 中的完整條目載有其來源、嚴重性等級與信心評估。

受害者身分未公開。微軟的報告描述單一 Azure 租用戶、兩個隸屬於該租用戶且遭入侵的服務主體，以及兩者之間的分工：其中一個服務主體負責偵察約 15 小時 30 分鐘，並進行了 300 多次成功的讀取操作，列舉虛擬機器、訂閱、資源群組與資源；另一個則執行探索、破壞性操作及憑證收集。微軟未說明有多少組織受到影響，也無法查明這些服務主體最初是如何遭入侵的。

遙測顯示的內容，依序如下

根據 Microsoft 的說法，第二個主體在第一個主體開始後約 90 分鐘才開始，並在大約五秒內列舉了兩個訂閱中的虛擬機與資源群組。這兩個身分都使用了 Microsoft 與 Storm-3168 掛鉤的基礎設施，共享相同的網路指紋，並呈現相同的使用者代理，python-requests/2.34.2。Microsoft 表示，時間安排與分工「強烈顯示這是自動化或腳本化執行」。

大約 16 小時後，第二個主體檢查了 Azure App Service 組態存放區是否有外洩的認證，並搜尋 Azure OpenSearch，但未成功。70 秒後，它對一個不存在的儲存體帳戶嘗試 ListKey 作業。該失敗呼叫後不到一秒，破壞行動就開始了。在接下來的 35 分鐘內，Microsoft 統計到超過 150 次破壞性或認證收集作業；核心破壞階段持續約七分鐘。

那七分鐘，以及守住的管控措施

微軟表示，該行為者鎖定的大部分儲存體帳戶都已成功刪除。該行為者也刪除了位於同一資源群組中的 Azure Key Vault、函式應用程式（Function App）和 App Service 方案，這些資源似乎是用來支援該函式應用程式。其攻擊目標並不限於儲存體：微軟記錄到多次嘗試刪除 Azure Site Recovery 鎖定和 Azure Backup 保護鎖定的行為，並回報這些嘗試均告失敗。

Microsoft 表示，並非每一次刪除都成功，而箇中原因各有不同，這點對防禦人員而言很重要。少數儲存體帳戶得以留存，是因為 Azure 資源鎖和儲存體帳戶層級的刪除保護阻止了該作業。同時嘗試刪除 Azure SQL 資料庫則因不同原因失敗：每一個都使用了不受支援的 API 版本。Cloud Security Alliance 將此描述為操作失誤，而非遭封鎖的動作。Microsoft 將資源刪除、試圖干擾復原，以及收集憑證的組合總結為「符合可支援勒索軟體與勒索作業的策略」。

Microsoft 的說明描述的是普通的 Azure 角色指派，而非 Azure 本身遭到利用。該公司發現，透過群組授予的Storage Account Contributor角色允許了儲存體破壞，直接指派的Contributor角色允許刪除三個應用程式資源及另一次金鑰擷取，而直接指派的SQL DB Contributor角色則導致失敗的 SQL 嘗試。Microsoft 觀察到為第二個服務主體簽發的五個唯一權杖：其中四個支援刪除，第五個負責儲存體清查與金鑰擷取。其中兩個刪除權杖在同一段 70 秒期間內處於作用中狀態。報告也指出，名稱帶有terraform與backup主題的儲存體帳戶也在目標之列，可能是為了妨礙復原。

儲存金鑰的回傳值

破壞行動結束約 30 分鐘後，同一個主體又回來了。它盤點了儲存體帳戶，並發出超過 30 次成功的 ListKeys 要求，包括針對與 Site Recovery 相關的儲存體。同一資源群組中名稱類似的儲存體帳戶在刪除階段並未受到波及，之後也成功被列出金鑰。Microsoft 未發現勒索訊息，也未確認資料外洩是否成功，但表示所收集到的金鑰可能助長未來的資料外洩。

Corsica Technologies 資訊安全長 Ross Filipek 在接受 CSO Online 談論此事件時表示，這一連串過程改變了復原的意義。他說，重建遭刪除的資產並不足夠，因為後續對儲存金鑰的請求可能開闢另一條通往資料的路徑；應變人員必須確認哪些身分與金鑰遭到觸及，並在信任復原後的服務之前審查其使用情況。Filipek 告訴 CSO Online：「一旦攻擊者握有應用程式身分，他們的活動看起來就可能像一般的雲端管理。」

憑證是如何曝光的

微軟無法確認最初的存取途徑。它確實發現的是一項暴露：其中一個服務主體的用戶端 ID、用戶端密碼和租用戶 ID 曾以明文形式出現在一則公開的 GitHub 問題中，該問題由受影響組織的一名員工發布。該問題後來經過編輯，但微軟表示，該密碼仍可透過該問題的公開編輯記錄存取。報告明確指出，微軟無法確認所用的密碼是否就是這一個。

該發現項目附帶的警告才是實務上的重點。Microsoft 表示，曾公開外洩的認證資訊應視為已遭入侵，須立即撤銷或輪替，並調查先前是否曾被使用；移除或遮蔽外洩的機密並不會使其失效，公開外洩的認證資訊在撤銷或輪替之前仍可被使用。

Microsoft 也描述了自 2026 年初以來，與 Storm-3168 相關的基礎設施針對 Azure App Services 上的 WordPress 管理介面、PHP-CGI、Langflow 端點/api/v1/validate/code，以及類似 webshell 的路徑所進行的更廣泛探測。這些目標並未與受害者的訂閱重疊，且 Microsoft 未發現從 App Service 取得 Azure Resource Manager 認證的路徑。報告列出三個指標：45.131.66[.]106 用於探測與惡意 ARM 請求，以及 34.153.223[.]102 和 64.20.53[.]230 用於 App Service 探測。

同一個行為者，不同的操作

Sysdig 於 2026 年 7 月 1 日發布的報告，正是「agentic」一詞會被套用到這個行為者身上的原因。Sysdig 將 JADEPUFFER 描述為首個有紀錄的 agentic 勒索軟體案例——「一場由大型語言模型端到端驅動的完整勒索行動」——並表示其能力來自 AI 代理，而非人類操作的工具組。在該次入侵中，該行為者利用了 CVE-2025-3248（存在於一個對外公開的 Langflow 執行個體中），使用 MySQL 內建的 AES_ENCRYPT() 函式加密了 1,342 個 Nacos 設定項目，刪除了原始資料表，並留下一個 README_RANSOM 資料表，內含比特幣地址與 Proton Mail 聯絡方式。Sysdig 通報了超過 600 個不同的酬載、會自我敘述的程式碼，以及一個在 Nacos 登入失敗後 31 秒內出現的矯正性多步驟酬載。Sysdig 也表示，其無法檢視系統提示或該代理的設定。

Azure 行動是同一行為者所發動的獨立行動，並非七月入侵事件的重演：其重點在於刪除與金鑰收集，而非加密，且 Microsoft 未發現勒索信。兩者之間的關聯部分建立在基礎設施上。Cloud Security Alliance 在 9 月 28 日的研究報告中指出，Microsoft 所列的兩個 IP 位址 45.131.66[.]106 與 34.153.223[.]102 曾出現在 Sysdig 七月的報告中。同一份報告也警告，僅憑 IP 重複使用無法排除共用第三方主機代管的情況。

已建立、已評估，但仍開放

Azure 入侵事件的運作機制已有詳盡記錄。其自主性則未以同等標準記錄，而這項差異是這份紀錄最重要的限定條件。

由 Microsoft 的遙測資料確認：單一租用戶中有兩個遭入侵的服務主體；在約 15.5 小時內有超過 300 次成功的讀取作業；超過 100 次儲存體帳戶刪除嘗試，其中大多數成功；一個 Key Vault、一個 Function App 和一個 App Service 方案遭到刪除；SQL 資料庫刪除全都因不支援的 API 版本而失敗；儲存體帳戶因資源鎖定和刪除保護而得救；在破壞後有超過 30 次成功的 ListKeys 要求；公開 GitHub 問題及其編輯歷程中有純文字的服務主體認證；未觀察到勒索訊息；且沒有確認的資料外洩。

Microsoft 評估：該活動屬於 Storm-3168；刪除、干擾復原與收集金鑰的組合，與勒索軟體及勒索行為一致；執行可能是自動化或腳本化；且收集到的金鑰可能助長未來的資料外洩。Microsoft 的公開報告並未描述自主代理程式如何對 Azure 特定步驟進行推理。

待釐清：服務主體最初是如何被入侵；受害者身分與受影響組織的數量；是否有任何資料離開租戶；以及究竟是 AI 代理而非腳本，直接指揮了 Azure 操作本身。

雲端安全聯盟（Cloud Security Alliance）在9月28日的說明中精確指出了這項證據缺口：它寫道，目前所謂「代理式」（agentic）的定性，依據的是「各身分之間的精确度、節奏與分工」，而非所擷取的代理推理軌跡。Sysdig 在7月使用的證據——自我敘述的酬載，以及快速診斷與修正循環——並未出現在 Azure 行動的公開紀錄中。安全公司 Swimlane 的 Nick Tausek 向 CSO Online 表示，Azure 的證據顯示的是「協調式自動化，而非證明 AI 指揮了每一步」。

對該披露內容的報導採用了更強烈的表述框架。BleepingComputer 的標題形容這是針對 Azure 的「代理式 AI 攻擊」，Dark Reading 的標題則形容有「AI 行為者」入侵 Azure 租用戶；然而微軟自家的報告指出，時機與分工「強烈顯示為自動化或腳本化執行」，並未將各個 Azure 步驟歸因於某個代理。

該檔案將此紀錄評為信心 A，且未標記為有爭議。此紀錄的「已確認」AI 參與標籤，取決於將其歸因於 JADEPUFFER——亦即 Sysdig 所記錄、由 LLM 驅動的行為者；這並非主張 Microsoft 在 Azure 刪除事件期間擷取到某個代理的推理過程。損害已確立，自動化已確立，而自主性則屬推斷。

Microsoft 表示應該改變的事項

Microsoft 的建議具可操作性，且直接源自這次入侵的運作方式。它要求防禦人員啟用適用於 Resource Manager、Storage、Key Vault、App Service 和 Databases 的相關 Microsoft Defender for Cloud 方案；將服務主體認證、儲存體金鑰、連接字串和其他祕密排除於原始碼、組態、存放庫和問題之外；使用 Microsoft Entra 工作負載 ID 而非長效祕密；套用最低權限，並檢閱工作負載身分識別的 Azure RBAC 指派；以及限制並監視備份與復原資源，包括試圖變更其保護控制項的行為。

微軟的公開報告並未說明該租用戶是否還原了資料、受害者是否收到通知，或事後是否使用了任何蒐集到的金鑰。這些結果都不在紀錄中。紀錄所呈現的是一項可量化的對比：資源鎖與刪除保護阻止了一些刪除作業，即使是對權限廣泛的身分亦然；而 SQL 資料庫則是因為 API 版本錯誤而倖免，而非出於防禦者的決定。微軟的敘述並未說明該租用戶接下來做了什麼。它確實指出，行為者在花七分鐘刪除之前，花了超過 15 小時閱讀。