對於許多 Junior 工程師來說，SQL 注入（SQL Injection）通常被認為是「竊取資料」或「刪除資料表」的漏洞。然而，在這次由安全公司 Huntress 揭露的案例中，攻擊者將 SQL 注入視為一個進入點，將 Oracle 資料庫從一個「被查詢的對象」轉化為「攻擊的跳板（Beachhead）」，最終直接控制了底層的 Windows 作業系統並獲取最高權限（SYSTEM）。
這起攻擊最值得關注的技術點在於：攻擊者完全沒有將任何可執行文件（Executable）寫入硬碟，而是直接在資料庫內部「編譯」惡意工具。
攻擊路徑：從 Web 表單到系統核心
這次攻擊的完整鏈條可以拆解為以下四個階段：
第一階段：入口點 (Entry Point) 攻擊者發現了一個面向公眾的 Web 應用程式，其「自動完成（Autocomplete）」搜尋欄位存在嚴重的漏洞。該欄位將使用者輸入的內容直接傳遞給後端資料庫，而沒有經過適當的驗證或參數化處理。
第二階段：建立 JDBC 連線 Web 應用程式透過 Java 資料庫連接（JDBC, Java Database Connectivity）與 Oracle 資料庫通訊。關鍵在於，該應用程式使用的資料庫帳號擁有過高的權限，足以在資料庫中建立 Java 物件。
第三階段：內部編譯 (In-Database Compilation) 這是本次攻擊的核心。Oracle 資料庫內建了一個 Java 虛擬機（JVM）。攻擊者利用 CREATE JAVA SOURCE 語法，將 Java 原始碼直接傳送到資料庫中。Oracle 會將這些代碼編譯成「儲存架構物件（Stored Schema Objects）」。
這意味著惡意代碼是以資料庫物件的形式存在，而不是以 .exe 或 .dll 檔案存在於檔案系統中。
第四階段：權限提升與執行 (Execution & Escalation) 一旦 Java 物件建立完成，攻擊者透過 PL/SQL 封裝器（Wrappers）來呼叫這些 Java 方法。利用 Java 的 Runtime.exec 函數，攻擊者可以直接在底層作業系統執行指令。由於資料庫服務在 Windows 上通常以高權限運行，執行結果直接回傳了 SYSTEM 權限。
---
核心工具集：khunt 的組成與功能
Huntress 將這次使用的後滲透工具集命名為 khunt。它並非單一程式，而是一組由 6 個 Java 物件與多個 PL/SQL 封裝器組成的工具鏈。
其功能模組化分工如下：
模組名稱 核心功能 實作細節 :--- :--- :--- KhuntCmd 遠端指令執行 載入 cmd.exe 並執行由 SQL 傳入的任意 OS 指令。 KhuntHash 憑證竊取 讀取 Oracle 內部使用者表中的用戶名與密碼雜湊（Hashes）並寫入檔案。 KhuntFS / KhuntFS2 檔案系統操作 執行檔案列表（List）、讀取（Read）、搜尋（Search）及查看檔案大小。 KhuntT 連通性測試 確認工具集是否已成功部署且可被觸及。 KhuntUnzip 資源解壓縮 將壓縮檔解壓至伺服器，以便部署更多工具。
---
技術深度分析：為什麼 EDR 沒發現？
在現代企業環境中，端點偵測與回應（EDR, Endpoint Detection and Response）產品隨處可見，但這次攻擊成功繞過了它們，原因在於偵測盲區：
無檔案特性 (Fileless)：惡意代碼存在於 Oracle 的系統表（System Tables）中，而非檔案系統。EDR 通常監控的是檔案建立、修改或可疑進程的啟動，而不會去掃描資料庫內部的 Java 物件。 合法進程掩護：所有的指令執行都是由 oracle.exe（合法的資料庫進程）觸發的。對於 EDR 來說，這看起來像是資料庫在執行其正常的內部操作。 內部編譯：編譯過程發生在 Oracle 內建的 JVM 中，不涉及外部編譯器（如 javac）的呼叫。
---
攻擊者的後續行動
在獲取 SYSTEM 權限後，攻擊者採取了典型的憑證竊取行動： 使用 PowerShell 與 reg.exe 將 Windows 登錄檔中的 SECURITY 與 SYSTEM 蜂巢（Hives）複製到 F:\Oracle 暫存區。 使用 esentutl.exe 複製 SAM（Security Accounts Manager）蜂巢，旨在離線破解系統密碼。 執行 tasklist /svc 記錄系統服務狀態。
雖然 Huntress 觀察到檔案被暫存（Staged）在本地，但尚未確認這些敏感資料是否已被外傳（Exfiltrated）。
---
工程判斷與防禦實務
這項技術其實並不新（類似的 raptor_oraexec.sql 在 2006 年就已出現），但其在野外（In the wild）被使用的記錄極少。這提醒我們，資料庫安全不能只靠防火牆，更要靠權限管控。
適用情境與風險 這種攻擊模式適用於： 運行在 Windows 上的 Oracle 資料庫。 Web 應用程式與資料庫之間缺乏輸入驗證。 資料庫帳號被授予了不必要的系統權限（如 CREATE PROCEDURE）。
實務建議 (Action Plan)
對於開發者與 DBA（資料庫管理員），應採取以下防禦措施：
應用層：參數化查詢 (Parameterized Queries) 絕對不要使用字串拼接來構建 SQL 語句。使用 PreparedStatement (Java) 或同類型的參數化機制，從根源杜絕 SQL 注入。 最小權限原則 (Least Privilege) * 面向公眾的 Web 應用程式所使用的資料庫帳號，絕對不應該擁有 CREATE PROCEDURE 或建立 Java 原始碼的權限。 * 限制該帳號僅能執行必要的 SELECT、INSERT、UPDATE 或特定的儲存過程。 監控與獵捕 (Hunting) 由於 EDR 無法偵測，必須在資料庫層級進行監控： * 檢查物件名稱：搜尋 Oracle 安裝中以 Khunt 開頭的物件。 * 審計日誌：在 SQL 日誌中搜尋關鍵字 KHUNT%。 * 權限審查：定期檢查哪些帳號擁有 Java 相關的系統權限。
總結
這次事件是一個典型的「權限崩潰」案例：一個簡單的 Web 漏洞 $\rightarrow$ 過高的資料庫權限 $\rightarrow$ 內建 JVM 的功能 $\rightarrow$ 作業系統最高權限。
作為工程師，我們必須意識到，任何一個內建的功能（如 Oracle 的 Java 支援）在攻擊者手中都可能變成武器。「功能強大」往往意味著「風險更高」，因此在配置系統時，請務必採取最嚴格的權限限制。