近年企業把資料分析、備份、監控工作交給第三方 SaaS 的情況越來越普遍，攻擊者也開始從這些「受信任的廠商」下手。這個月又出現一起：資安公司 Wiz 與 Sentra、Mandiant 合作，揭露有人拿到與大數據平臺 Qubole 關聯的 AWS 帳號憑證，再用它進入多家客戶的 AWS 環境。
客戶自己的帳號沒有被盜，是客戶當初為了讓 Qubole 能運作而建立的角色，反過來成了入口。我們來看看事件經過、攻擊者怎麼進去，以及相關企業現在該查什麼。
事件經過
以下時間與數字取自 Wiz 的研究報告，報告所列的活動期間是 2026 年 10 月 14 日到 10 月 26 日。
| 日期（2026） | Wiz 報告記載的內容 |
|---|---|
| 10 月 8 日～11 日 | 另一組活動：有人在一小時內測試客戶為 Qubole 整合所建立的 AWS 存取金鑰，少數案例中受害者的雲端環境被入侵。Wiz 表示尚未證實與下面的活動有關 |
| 10 月 14 日 | 首次觀察到攻擊者對客戶帳號中的整合角色呼叫 AssumeRole |
| 10 月 16 日～19 日 | 攻擊者使用 TruffleHog 工具驗證取得的憑證 |
| 10 月 18 日 | 攻擊者開始使用第二個 IAM 使用者 |
| 10 月 26 日 | 最後一次觀察到的活動 |
| 11 月 9 日 | Wiz 發表報告 |
| 11 月 11 日 | Wiz 更新：Risky Business 報導有人自稱 "n0n" 並宣稱是自己所為；Wiz 引述該報導，報告中沒有表示已證實 |
受害家數與攻擊者身分
Wiz 報告只寫「多個受害者的 AWS 環境」，沒有給出確切家數。
部分中文報導的標題提到「數十家」，截至撰稿時，Wiz 的報告中沒有這個數字的出處，所以本文不採用。
攻擊者身分方面，Wiz 表示沒有發現與其他已公開活動的關聯，並認為目標選擇與資料竊取帶有機會主義色彩。至於自稱 "n0n" 的說法，Wiz 只引述報導，報告中沒有表示已證實。
攻擊者怎麼進到 AWS
用廠商帳號的身分「扮演」客戶的角色
使用 Qubole 這類服務時，客戶通常會在自己的 AWS 帳號建立一個 IAM 角色，並在信任政策（trust policy）寫明「允許 Qubole 的 AWS 帳號來扮演這個角色」。廠商的系統因此能代替客戶存取資料。
Wiz 觀察到，攻擊者拿到與 Qubole 關聯的 AWS 帳號中的 IAM 使用者憑證，再對客戶帳號呼叫 sts:AssumeRole。每次呼叫都帶了 External ID，而且全部成功。
沒在用的角色，信任關係還在
Wiz 指出，被扮演的角色大多數平常沒有在使用，但信任政策依然保留，所以攻擊者的請求才會成功。
External ID 常被當成一道額外的驗證，但 Wiz 提醒它不是機密：External ID 會以明文記錄在 CloudTrail，廠商與基礎設施即程式碼（infrastructure as code）的設定檔裡也常有留存。Wiz 報告沒有說明攻擊者怎麼拿到 External ID。
進去之後做了什麼
依 Wiz 的記載，攻擊者先列舉儲存、運算、資料庫與身分服務，接著蒐集機密：
- 讀取 Lambda 函式設定中的環境變數
- 從 Secrets Manager 與 SSM Parameter Store 取出機密值
- 讀取 S3 資料，部分連線階段下載了整個儲存貯體（bucket）
- 用 TruffleHog 驗證取得的 AWS 金鑰、Entra ID 用戶端密碼與 Okta 用戶端憑證是否有效
最後一項值得留意：攻擊者驗證的是「受害企業自己的」憑證，目的是看能不能再往其他服務延伸。Entra ID 用戶端密碼被拿去利用的情境，可以參考 Entra ID 服務主體是什麼？從 MSP 遭入侵事件看委外 IT 的自查清單。
官方沒說清楚的部分
下列項目，Wiz 報告列為未揭露，或報告中沒有說明：
| 項目 | 狀態 |
|---|---|
| Qubole 關聯帳號的憑證怎麼被取得 | 官方未說明 |
| External ID 怎麼被取得 | 未說明 |
| 受害家數、被竊資料量與類型 | 未說明 |
| Qubole、AWS 的聲明 | Wiz 報告中沒有 |
截至撰稿時，尚未找到 Qubole 或其母公司的官方聲明。有需要的話，可以自行前往 Qubole 官方網站 查詢最新說明。
有用 Qubole 的企業現在該做什麼
Wiz 的處置建議條目很多，這裡只整理方向，完整清單請直接看 Wiz 原文。
先確認有沒有被用過
Wiz 建議在每個建立過整合角色的帳號，檢視 2026 年 10 月 1 日之後的 CloudTrail 紀錄，並搜尋 AssumeRole 事件中，來源為 Qubole 關聯帳號但 IP 不屬於 AWS 的紀錄。報告也列出了攻擊者使用的 IP 與 IAM 主體識別碼，查詢時直接對照原文的 IOC 表格。
要注意一點：CloudTrail 預設的管理事件不會記錄 S3 物件的讀取，要看資料有沒有被下載，需要事先開啟 S3 資料事件。沒開的話，只能確認「角色被扮演過」，無法確認「哪些物件被讀走」。
找到被扮演過的角色之後
Wiz 的建議大方向是：
- 檢查該角色連線階段之後的所有操作
- 輪替這個角色讀得到的所有機密、參數與 Lambda 環境變數
- 撤銷仍有效的連線階段，因為單純更換憑證不會讓已簽發的階段失效
就算沒有被用過，也該清一次
Wiz 建議盤點帳號裡所有「信任外部 AWS 帳號」的 IAM 角色。
- 已經沒在用的整合，直接刪角色，或把廠商帳號從信任政策移除。
- 還在用的，把信任對象縮到廠商的特定 IAM 主體，並加上來源 IP 限制。Wiz 提到，光是來源 IP 這一條，就能擋下這次觀察到的所有
AssumeRole。 - 角色權限收到最小，沒必要的話就不要讓整合角色讀 Secrets Manager 與 Lambda 設定。
不只 Qubole
這次事件的結構適用所有雲端 SaaS：你把自己帳號的鑰匙交給廠商，廠商那邊出事，你就會受影響。
建議每半年檢查一次，列出目前有哪些廠商能進你的雲端帳號、各自能做什麼、還有沒有在用。這類整合通常是導入時設定一次，之後就沒人再看。
參考資料與延伸閱讀
- Wiz：Trusted by Default: Qubole Cross-Account Access Abused in the Wild（第一手研究報告，含時間軸、IOC 與處置建議）
- iThome：【資安日報】11月11日，駭客利用大數據平臺Qubole被竊憑證，入侵數十家企業AWS環境竊取資料（原新聞，標題的「數十家」未在 Wiz 報告中找到對應數字）
- Risky Business（經 Wiz 報告引用）：攻擊者自稱 "n0n" 的相關報導
- 站內延伸：Entra ID 服務主體是什麼？從 MSP 遭入侵事件看委外 IT 的自查清單
發佈留言