Khunt攻擊解密：黑客將Oracle數據庫變身滲透後平台

Khunt 工具包：藏身數據庫的 Java 物件

黑客並未在受感染伺服器放置傳統惡意檔案，而是借助 Oracle 內建的 Java 虛擬機器（JVM），透過 CREATE JAVA SOURCE 語句將整套滲透後工具包編譯成 Java Schema 物件，直接儲存在數據庫內部。如此一來，工具包對傳統系統級防護完全隱形——EDR 與防毒軟件針對的是作業系統進程、二進制檔案及文件，一般不會檢查 Oracle 內部的 Java 類別及 PL/SQL 包裝程序。

khunt 工具包包含以下組件，全部以數據庫物件形式存在：

從數據庫奪取系統：獲取 Windows 完整權限

黑客不滿足於數據庫層面的存取，透過 khunt 工具包逐步跳至 Windows 作業系統：

1. 執行系統指令：使用 KhuntCmd 模組執行 cmd.exe /c whoami，確認他們正以 SYSTEM 權限執行，從數據庫直接實現了向作業系統的遠端程式碼執行（RCE）。
2. 偷取憑證：透過 PowerShell 呼叫 reg.exe 複製 SECURITY 與 SYSTEM 登錄區，另存為 khuntSECURITY.hiv 及 khuntSYSTEM.hiv 至 F:\Oracle\。
3. 枚舉服務：執行 tasklist /svc，將輸出儲存為 khunttasks.txt。
4. 額外提取登錄區：使用 esentutl.exe 複製 SAM 及另一份 SECURITY 登錄區，另存為 khuntSAM.hiv 及 khunt_SECURITY.hiv。

被竊取的登錄區可離線用於提取及解碼系統上所有本機帳戶的密碼哈希值。

防禦盲點：Huntress 的關鍵發現

Huntress 調查揭露多個令攻擊得手的關鍵盲點：

• 數據庫淪為攻擊平台：數據庫從被動資料儲存庫，變成主動攻擊平台，惡意工具包藏身數據庫內部而非磁碟或記憶體。
• EDR/AV 完全無視：傳統 EDR 與防毒軟件一般不會檢查 Oracle 內部的 Java 類別及 PL/SQL 包裝程序，令工具包對標準系統級防護來說完全隱形。
• 經典漏洞，新穎傳遞方式：初始 SQL 注入是為人所知的漏洞類型，無需零日漏洞。一條 autocomplete 搜尋欄足以通往 PL/SQL 再進入作業系統，反映當數據庫引擎具備作業系統級能力時，基本的輸入驗證錯誤足以引發深入入侵。
• 過度授權的數據庫帳戶：即使 SQL 注入成功，若數據庫用戶帳戶欠缺建立 Java 來源或執行儲存程序的權限，損害有限。企業經常過度授權數據庫帳戶，令攻擊者取得部署 khunt 所需的額外權限。

Huntress 建議的緩解措施

Huntress 根據是次攻擊提出以下建議：

• 所有網絡輸入必須妥善進行輸入消毒及查詢參數化
• 限制數據庫用戶權限，即使注入查詢成功也無法建立 Java 來源或執行任意儲存程序
• 將監控範圍擴展至數據庫物件（Java 類別、PL/SQL 包裝程序），而非只限作業系統層面的痕跡

這次攻擊是一記警號：當數據庫引擎具備內建程式環境（如 Oracle 的 JVM），只要配合一條未經驗證的輸入欄，就可以變成隱秘的攻擊平台。安全團隊必須將監控延伸至數據庫物件層面，不然下次看到攻擊時，可能已太遲。