Wiz 剖析一宗真實 AI 驅動雲端攻擊的運作方式

過去幾星期，Wiz Customer Incident Response Team (CIRT) 在調查中看到一個明顯趨勢：AI 驅動攻擊日益增加。最近數宗入侵事件中，AI 代理系統不只是協助幕後操作的攻擊者，而是負責執行整場攻擊。它找出入侵入口、收集憑證、在不同平台間橫向移動，並即時除錯自己的指令碼，從頭到尾主導整個攻擊行動。

這些入侵事件與傳統攻擊行動截然不同。它們動靜大、以機器速度推進，並觸及雲端堆疊的每一層。防禦者面對的挑戰，不是這些攻擊難以察覺，而是攻擊痕跡分散在身分識別提供者、雲端控制平面、CI/CD 系統和工作負載記錄中，沒有任何單一警示能呈現全貌。

這篇網誌文章首先探討 AI 驅動攻擊有哪些特徵，使其有別於傳統的人手操作入侵。接着會介紹 Wiz CIRT 調查中的真實案例。最後會説明安全團隊要偵測並回應以機器速度行動的攻擊者，需要具備哪些條件。

AI 驅動攻擊的特徵

AI 驅動攻擊的行為，有別於人手操作的入侵和傳統的指令碼自動化攻擊。指令碼會盲目執行預先編寫的步驟，而人手操作人員的行動較慢，並按順序逐步進行；AI 代理則結合機器速度與情境推理。在多宗調查中，Wiz CIRT 觀察到一系列反覆出現的特徵，足以區分這類攻擊。

1. 行動節奏 - 活動量每小時可達數百甚至數千次操作，而且會持續很長時間，不會像人手操作人員般出現停頓或遵循常見的工作時間模式。

2. 同時在多個平台上活動 - 代理會同時在多個環境中操作。一項工作列舉雲端資源時，其他工作則會部署 Kubernetes 工作負載、建立 CI/CD 管道或查詢資料庫；這些工作均來自同一來源，並在同一時間範圍內進行。人手操作人員通常一次只會處理一個環境，而傳統指令碼極少會同時跨越多個環境。

3. 跨平台操作能力 - AI 代理會使用其接觸到的每個平台原生的 API 和工具，包括雲端供應商、容器協調系統、CI/CD 系統、資料庫、身分識別提供者和訊息佇列。人手操作人員極少能同時深入掌握以上所有平台的實際操作。

4. 跨環境憑證串連 - 由於代理能熟練運用如此多種技術的原生功能，每組憑證都會成為通往下一個平台的跳板。例如，Kubernetes 服務帳戶權杖可通往雲端服務帳戶，再通往 CI/CD 系統，最終取得完整管理員權限。 

5. 快速反覆嘗試 - 攻擊者多年來一直依賴指令碼，但指令碼出錯時，修正需要時間。由代理執行整個操作時，整個回饋循環便會即時完成。如果嘗試失敗，代理會立即讀取錯誤訊息、即時改寫指令碼，並在幾分鐘內再次嘗試；每次新嘗試都會直接修正導致上一次失敗的問題。

6. 安全測試命名慣例 - 行為者建立的資源、檔案及載荷，均一致地使用 pentest、probe、recon、redteam 及 exfil 等字詞作為標記。這種包裝方式可能有助於行為者將活動呈現為經授權的安全測試，從而實際繞過 AI 模型的安全防護機制。

7. 數字任務識別碼 - 攻擊期間建立的許多資源、用戶及檔案都包含數字識別碼，而同一數字往往會出現在多個相關項目中。失敗的嘗試會使用同一數字加上字母後綴重試（例如 -b、-c、-d）。這些識別碼似乎是 AI 代理用來追蹤自身工作的內部任務 ID。

8. 生成程式碼的模式 - 人類攻擊者很少會在短期使用的漏洞利用腳本中加入註解。從這些攻擊中還原的程式碼，通常包含描述性標頭及帶有編號的逐步註解，而且相同的輔助函式會在數十個載荷中重複使用。這兩種特徵都是模型生成程式碼的直接結果。

調查實錄：AI 驅動攻擊的實際情況

AI 驅動的攻擊不會沿着清晰、線性的路徑進行。代理會同時在多個平台上活動，並在開啟新的存取途徑時折返，因此傳統時間線無法呈現攻擊的發展過程。本節會按階段講述 Wiz CIRT 調查的一宗 AI 驅動攻擊，並指出上述特徵在攻擊過程中的出現位置。

目標是一個擁有大型多雲環境的機構。AI 代理透過多個由攻擊者控制的 IP 位址運作，活動範圍幾乎涵蓋環境的每一層：雲端服務供應商、Kubernetes 叢集、CI/CD 和 GitOps 管道、身分識別提供者、秘密管理系統、數據倉庫，以及內部應用程式。攻擊期間，代理收集憑證和秘密、存取敏感資料，並透過多種渠道將資料移出環境。

初始存取：逐一嘗試每個入口

在攻擊期間，威脅行為者使用不同技術探測多個面向互聯網的服務。它傳送針對已知漏洞的利用載荷、嘗試匿名存取雲端儲存空間，並透過一個暴露在外的內部開發者工具 API 進行操作。它嘗試建立管理員帳戶、觸發密碼重設、透過路徑遍歷讀取本機檔案，並上載一個名稱以 pentest 為前綴的測試檔案。

其中一個已確認的初始存取途徑，是一個暴露在外的 Kafka UI 執行個體存在 Java 遠端程式碼執行漏洞。應用程式的 Java 程序啟動了 shell 指令，隨後部署惡意軟件並建立 C2 通道。 

即使已取得可用的立足點，代理仍持續掃描：它同時繼續探測其他入口，以建立通往網絡的備援路徑。值得注意的是，在同一時段，有人觀察到相同來源 IP 位址掃描了另外超過 600 個 Wiz 客戶環境，這與大規模、機會主義式自動化的情況一致。

在工作負載中建立立足點

代理在一個暴露的端點取得程式碼執行權限後，幾乎立即着手達成三個目標：

1. 維持存取權限 - 在多個叢集中的多個 Pod 部署後門及 C2 代理程式。

2. 收集憑證 - 擷取已掛載的 Kubernetes 服務帳戶權杖，在環境變數中搜尋 token、secret、key 和 pass 等字串，並查詢 Instance Metadata Service (IMDS)，從節點附加的雲端服務帳戶收集憑證。

3. 繪製內部網絡可達範圍 - 掃描內部訊息代理程式、架構登錄庫和資料庫，確認哪些服務可從 Pod 的網絡命名空間內存取。

這些收集到的憑證成為橫向移動至雲端控制平面的主要切入點。

在雲端控制平面運作

該代理程式同時在組織的兩個雲端環境 GCP 和 AWS 中運作，速度之快，人類操作者無法匹敵。代理型攻擊者利用攻擊較早階段取得的存取金鑰和服務帳戶憑證，以及身分冒充手段，首先進行大範圍偵察。

在 GCP 中，它利用一個獲授建立權杖權限的服務帳戶，將其變成自動化憑證生成引擎，迅速為數十個身分生成憑證。同時，該代理程式持續循環抓取容器映像檔登錄庫，嘗試外傳高價值資料庫記錄，並部署以 pentest- 為前綴、可公開存取的 Cloud Run 服務。

與此同時，在 AWS 中，該代理程式利用 AWS Systems Manager (SSM) 在環境中的多個執行個體上執行命令。它透過 SSM 嘗試使用收集到的憑證連接資料庫，透過 SSH 橫向移動、收集更多機密資料，並將資料安排外傳至名為 pentest-<task_id> 的儲存貯體。為在不同帳戶間建立持續存取，它建立了一個以 probe 為前綴的 IAM 用戶，並用它擔任 OrganizationAccountAccessRole，從而取得 AWS Organization 內各成員帳戶的管理員存取權。

身分識別提供者：成為內部人員

該代理程式不只依賴被盜憑證，還建立了自己的身分。它使用組織身分識別提供者（IdP）的已遭入侵管理員 API 金鑰，以程式方式作出變更：建立一個以 pentest 為前綴的用戶、設定其密碼、啟用帳戶，並將其加入管理員羣組。

IdP 在過程中回傳錯誤時，該代理程式即時排查，逐一處理每項故障。建立可用的身分後，它透過羣組成員資格擴大攻擊影響範圍。它先將該用戶加入直接對應 AWS IAM Identity Center 角色的雲端角色羣組，接着加入可透過繼承權限存取各種企業應用程式的廣泛組織羣組。在最後一次羣組變更後數分鐘內，新建立的身分便透過單一登入（SSO）登入 AWS，並持續維持驗證工作階段，直至帳戶遭暫停。

將 CI/CD 和 GitOps 武器化

CI/CD 和 GitOps 平台成為該代理程式主要的執行引擎。五個不同的工作流同時運作，每個工作流的輸出都會供其他工作流使用：

1. 收集機密資料 - 從所有可存取的來源收集機密資料：CI/CD 平台本身的機密資料儲存庫、Kubernetes Secrets 和 ConfigMaps、Runner 環境變數、雲端中繼資料端點、Vault sidecar、Docker 映像層，以及其他工作流已開啟的資料庫。

2. 繪製可達範圍 - 將偵察指令碼部署至 Runner 和 Pod，確認各自可存取哪些資源，以及各自使用哪個身分。

3. 憑證噴灑－結合前兩個工作流程的輸出，使用收集到的憑證，嘗試存取 Agent 找到的可連接目標：資料庫、雲端 API、內部 OAuth 服務、Kubernetes 叢集及付款端點。

4. 服務利用－研究可存取的服務，瞭解其運作方式和預期的驗證流程，並嘗試使用這些服務。

5. 運算資源擴展－部署新的 Runner 和 Pod，透過 SSH 金鑰及原生遠端執行工具橫向移動，並將每個新據點的資訊回饋至其他工作流程。

每當出現新憑證，就會立即用它測試所有已知目標，直至確認取得存取權；每當有新目標變得可連接，就會用所有已知憑證測試該目標。

這些 Agent 並非盲目噴灑憑證，而是利用先前工作流程取得的背景資訊，為每項操作挑選合適的 Runner。一旦得知某個 Runner 可以連接某個目標，之後對該目標進行的所有操作都會經由該 Runner 執行。當來自完全不同來源的新憑證出現時，系統會自動透過已知可連接相關環境的 Runner 嘗試使用該憑證。

流水線和資訊清單的名稱包括 pentest_exfil、recon、foothold、dump-remaining 和 harvest 等，並附有數字任務識別碼。失敗的嘗試會沿用相同識別碼，並加上字母後綴重新執行；每個載荷內的程式碼都以逐步註解整理，並重用輔助函式。
兩個平台雖然採用不同的基礎架構和執行模型，但兩者上執行的都是相同的工作流程。

在 CI/CD 平台上，這些 Agent 利用遭入侵的服務帳戶建立流水線，並利用現有 Runner 可連接不同叢集、雲端帳戶及 VPC 的能力。Runner 的輸出日誌則用作外洩機密和資料的通道。在橫向移動方面，Agent 利用機密收集工作流程找到的 SSH 金鑰和雲端存取金鑰，透過 SSM 和其他原生遠端執行工具存取 Runner 以外的主機。

在 GitOps 平台上，這些 Agent 利用遭入侵的部署服務帳戶推送惡意 Kubernetes 資訊清單，GitOps 控制器會將其直接同步至正式環境叢集，並部署為執行中的 Pod。第一份資訊清單將權限提升至 cluster-admin；取得這個位置後，相同的工作流程便在叢集內執行。

寄生於 Kubernetes

Kubernetes（K8s）在這次攻擊中扮演重要角色，這並非巧合。GitOps 控制器按設計會在 K8s 叢集內執行，CI/CD Runner 也經常以 K8s Pod 形式運作，而儲存在 CI/CD 機密管理工具中的大量機密，本身就是 K8s 權杖。該 Agent 透過三個獨立入口存取 K8s API：CI/CD Runner、GitOps 部署，以及它在身分識別提供者中建立的後門身分。

該 Agent 從多個叢集傾印機密，提取資料庫連接字串、OAuth 用戶端憑證、TLS 憑證及雲端服務帳戶金鑰。當角色型存取控制（RBAC）阻止其存取機密時，它便轉而查閲 K8s ConfigMaps，找到硬編碼的預設密碼、明文憑證及加密金鑰。它在執行中的 Pod 內執行遠端命令以讀取環境變數，並查詢執行個體中繼資料服務，將 Pod 身分轉換為雲端憑證。

在提升至 cluster-admin 權限，並為自己授予整個叢集的無限制存取權後，該 Agent 簽發服務帳戶權杖，冒充合法應用程式，並嘗試以這些應用程式的身份向組織的機密資料保險庫進行身份驗證。它亦嘗試存取 vault-agent sidecar；這些輔助容器會從保險庫擷取機密資料，並以明文檔案形式儲存在 Pod 內。Agent 試圖直接從檔案系統讀取已解密的憑證。

叢集亦成為持久化層。Agent 將指令及控制植入程式部署為具備自我修復功能的 Kubernetes 工作負載，確保即使 Pod 被終止，後門仍會持續存在。之後，它直接與 GitOps 控制器通訊，修改正在執行的工作負載，未在 Git 歷史記錄中留下痕跡。

資料存取與外洩

整個攻擊期間，資料收集及外洩持續進行，並因應各環境中獲準使用的通道調整方式。它將結果發佈至 request-catcher 服務 webhook[.]site，將傾印出的資料提交至組織自家的原始碼控制平台中的儲存庫，並將輸出內容暫存於它為此建立的 Kubernetes ConfigMap。它亦嘗試建立以任務命名的儲存貯體，例如 pentest-<task-id>-<objective>，作為資料目的地，但這些嘗試均被拒絕。當其中一個途徑失敗或遇上大小限制時，它便改用下一個途徑。

以下是外洩階段所用的一段指令碼，當中展示了 Agent 對任務的描述性註解：

指令碼查詢了資料庫結構，搜尋包含敏感字詞的欄位名稱，並將結果連同 Pod 自身的服務帳戶權杖上載至 webhook[.]site，註明「以供日後重用作為立足點」。 

給防禦者的建議

由 AI 驅動的攻擊會產生大量雜訊，但只有在防禦者能全面掌握、串連並迅速採取行動時，這些雜訊才有幫助。以下建議旨在堵塞這類攻擊所利用的漏洞。

1. 統一各平台的記錄：

   • 這次攻擊的每個階段都出現在不同的記錄來源中，單一來源都無法呈現完整情況。雲端稽核記錄、Kubernetes 稽核記錄、執行階段事件、身份識別提供者記錄、CI/CD 稽核記錄，以及 SaaS 應用程式記錄，都需要集中收集並存放於同一位置，供人搜尋，並採用一致的保留期限。統一記錄後，防禦者便能串連跨平台活動，在數分鐘而非數天內瞭解事故的完整影響範圍。

   • Wiz Defend 可即時擷取多種記錄來源，包括版本控制記錄、雲端記錄、身份識別提供者記錄等，亦內置威脅偵測規則，用以識別環境中的活躍威脅。

2. 運用 AI 進行調查和分流：

   • 當攻擊者在不同平台上產生數以千計的事件時，逐一調查警示已不可行。保安團隊應使用 AI 輔助調查，將相關警示分組、摘要不同來源的活動、解碼酬載，並標示最關鍵的路徑，讓分析人員專注於作出決策，而非手動串連資料。對於真陽性事件，迅速採取行動十分重要。

   • Wiz Defend 正利用情境感知分組，根據偵測情境和時間，將來自不同記錄來源的多項偵測結果互相關聯，整合成一個連貫的事件脈絡。

   • Wiz 的 Blue Agent 可協助快速調查和分流。它是一個由 AI 驅動的 SOC 調查 Agent，專為自主調查威脅而設。

3. 假設遭入侵資源上的所有機密均已暴露：

   • 若發生規模如此之大、速度如此之快的真陽性事件，應優先更換遭入侵資源上的所有憑證，而不是嘗試追查究竟哪些憑證曾被讀取。記錄可從這些資源存取的所有機密，將每項機密對應至其身分，並搜尋這些身分及資源在入侵發生後有否出現任何異常使用情況。

   • Wiz 的機密掃描器可對應特定資源上的機密及其身分，並驗證它們是否仍然有效。

4. 維持端點及工作負載的可視性：

   • AI 代理程式往往會直接利用端點，而不只使用雲端 API 金鑰。它們會存取內部服務、連接資料庫、部署指令及控制代理程式、探測 API，並從執行器 Pod、虛擬機器和容器內橫向移動。這些活動不會出現在雲端控制平面記錄中。若無法查看端點本身的執行階段狀況，包括程序執行、網絡連線和檔案存取，這些活動便無從察覺，也無法補救。

   • Wiz 的 Sensor 可偵測特定資源上的作用中程序、網絡連線和執行階段行為，將它們對應至工作負載和身分，並就可疑活動發出警示。

   • Wiz 的 Agentless Workload Detection 可讓用戶查看無法部署傳統代理程式的關鍵資產，例如虛擬設備、由供應商管理的系統，或對效能有嚴格要求的工作負載。

5. 限制不同系統之間的信任關係：

   • AI 代理程式會將所有不同環境視為同一個環境。資安團隊必須在各環境之間落實嚴格的隔離界線。例如，預備環境的工作負載不應能夠存取正式環境的憑證；CI/CD 管道不應持續保有所有環境的存取權限；單一服務帳戶亦不應能夠為任何其他身分建立權杖。

   • Wiz 的 Security Graph 有助偵測可用於在不同環境間進行此類橫向移動的攻擊路徑及權限過大的身分。

6. 持續掃描外部攻擊面：

   • AI 代理程式會廣泛且快速地掃描，尋找任何暴露的攻擊路徑。因此，找出並評估面向互聯網的資產至關重要，包括開發人員工具、管理主控台及內部應用程式，並在攻擊者發現暴露問題前修正或移除這些問題。

   • Wiz Red Agent 可偵測環境中的攻擊路徑。Red Agent 是一款 AI 驅動的資安代理程式，會扮演具智能的攻擊者，找出並驗證網絡應用程式及 API 中可被利用的風險。