Khunt 攻擊深度解析：Oracle 資料庫淪為駭客的隱形攻擊跳板

從資料庫層成功入駐後，攻擊者隨即利用 Khunt 工具組，轉向攻擊底層的 Windows 作業系統，最終取得完整的 SYSTEM 等級權限，達成遠端程式碼執行 (RCE)，並成功提取包含密碼雜湊的登錄檔配置單元，再將其離線外洩。Huntress 將攻擊者基礎設施的 IP 位址追溯至 178.162.151[.]229 。

攻擊鏈：從自動完成搜尋到資料庫淪陷

攻擊的初始切入點是一個存在 SQL 注入漏洞的公開 Java 應用程式，該程式運行於 Apache Tomcat 之上 。應用程式中的「自動完成搜尋」功能未能確實驗證使用者輸入，使攻擊者得以透過連接到 Oracle 資料庫的 JDBC 連線注入惡意 SQL 指令 。Huntress 研究人員指出，這並非新穎的漏洞類別——SQL 注入攻擊已存在數十年，其根本原因通常是應用程式不當處理傳送至 SQL 伺服器的使用者輸入所致 。這次，一個簡單的搜尋欄位驗證疏失，就足以讓攻擊者發動一連串的滲透行為。

##「Khunt」工具組：化身資料庫 Java 物件的隱形武器

有別於一般攻擊手法，這起事件的駭客並未在遭入侵的伺服器上部署傳統惡意軟體。相反地，他們利用 Oracle 內建的 Java 虛擬機器與 CREATE JAVA SOURCE 指令，將整個後滲透工具組編譯並儲存為資料庫內的 Java 結構化物件 。此策略讓工具組能完美隱身於標準作業系統層級的防禦雷達下，因為 EDR 與防毒軟體專注於監控 OS 上的處理程序、二進位檔與檔案，通常不會去檢查儲存在 Oracle 資料庫內部的 Java 類別與 PL/SQL 包裝器 。

以下是「khunt」工具組的各個元件及其功能，它們皆以資料庫物件的形式存在：

全面掌控：從資料庫到 Windows 系統的權限提升之路

攻擊者並未滿足於僅取得資料庫層級的存取權限。他們利用 khunt 工具組，透過一個多步驟的流程，成功從資料庫層轉向控制底層的 Windows 作業系統：

1. 透過 KhuntCmd 執行 OS 指令：他們利用 KhuntCmd 模組執行 cmd.exe /c whoami 指令，結果顯示他們已在 Windows 伺服器上取得 SYSTEM 等級的權限，這也確立了攻擊者已從資料庫成功達成對 OS 的遠端程式碼執行 (RCE) 。
2. 竊取憑證：他們利用 PowerShell 呼叫 reg.exe 程式，複製了 SECURITY 與 SYSTEM 這兩個登錄檔配置單元，並將其分別儲存為 F:\Oracle\ 目錄下的 khuntSECURITY.hiv 與 khuntSYSTEM.hiv 檔案 。
3. 列舉服務：他們執行 tasklist /svc 指令，並將輸出結果儲存為 khunttasks.txt 。
4. 提取額外配置單元：他們使用 esentutl.exe 工具複製了 SAM 配置單元以及另一份 SECURITY 配置單元，分別儲存為 khuntSAM.hiv 與 khunt_SECURITY.hiv 。

攻擊者得以將這些外洩的登錄檔配置單元帶離線環境，從中提取並解碼系統上所有本機帳戶的密碼雜湊 。

防禦盲點：Huntress 揭露的關鍵警訊

Huntress 的調查結果點出了幾個讓此攻擊得以成功、並避開偵測的關鍵防禦盲點 ：

• 資料庫角色轉變：資料庫從被動的資料儲存庫，搖身一變成為主動的攻擊平台。惡意工具組是「寄生」在資料庫內部，而非存在於磁碟或記憶體中。
• 繞過 EDR/AV 偵測：傳統的端點偵測與回應 (EDR) 及防毒軟體，通常不會檢查儲存在 Oracle 內部的 Java 類別與 PL/SQL 包裝器，這使得惡意工具組得以在標準 OS 層級的防禦系統下遁形。
• 經典漏洞，新穎遞送手法：初始入侵的 SQL 注入是已知已久的漏洞類型，攻擊者無需仰賴零時差漏洞。一個自動完成搜尋功能的輸入驗證失誤，就足以讓攻擊者觸及 PL/SQL 層，進而攻入 OS。這顯示，當資料庫引擎本身具備強大的 OS 層級能力時，基本的輸入驗證失敗就可能導致系統遭到嚴重入侵。
• 過度授權的資料庫帳戶：即使 SQL 注入成功，若資料庫使用者帳戶缺乏建立 Java 原始碼或執行預存程序的權限，其造成的損害仍屬有限。然而，許多組織時常給予資料庫帳戶過多的權限，這正好為攻擊者提供了部署 khunt 工具組所需的額外權限。

Huntress 建議的緩解措施

基於此次攻擊，Huntress 建議採取以下緩解措施 ：

• 對所有網頁輸入進行嚴格的輸入淨化與查詢參數化。
• 限制資料庫使用者的權限，確保即使成功注入 SQL 查詢，也無法建立 Java 原始碼或執行任意的預存程序。
• 將監控範圍擴展至資料庫物件（如 Java 類別、PL/SQL 包裝器），而非僅限於作業系統層級的項目。

此次攻擊是一個強烈的警示：當資料庫引擎內建如 Oracle JVM 這類的程式開發環境時，再結合任何一個未經驗證的輸入欄位，就能搖身一變成為一個難以察覺的攻擊平台。資安團隊必須將防護視野從作業系統延伸至資料庫物件層級，才能有效防堵此類新興威脅。