Huntress揭露攻擊者先以SQL injection 入侵 Oracle database，再利用 OJVM 與 CREATE JAVA SOURCE 將 khunt 以資料庫物件形式駐留，進而在 Windows 執行 cmd.exe、複製 Registry Hive 並取得 SYSTEM 權限，凸顯資料庫層攻擊已能繞過傳統 EDR 偵測。
資安業者 Huntress 近日揭露一起針對 Oracle database 的入侵事件。攻擊者先透過 SQL injection 入口滲透系統，再把名為 khunt 的 post-exploitation toolkit 寫入 Oracle database 內部，最後把資料庫當成跳板，在 Windows 主機上執行惡意指令並嘗試竊取憑證。[1][4]
這起手法之所以受到關注，在於攻擊者並未把工具包以一般 executable 或檔案形式落地，而是利用 Oracle 內建 Java VM 與 CREATE JAVA SOURCE，將 Java source code 直接存成 database object，讓工具以資料庫物件方式長駐。Huntress 指出，這是相對少見、但在研究脈絡中已被討論過的 oraexec 類型手法。[1][4]
整體攻擊鏈可分為初始入侵、資料庫內駐留與系統層擴張。首先，攻擊者利用未妥善處理輸入的 web application 觸發 SQL injection，取得對 Oracle database 的控制能力。[4]
接著，攻擊者濫用 OJVM 與 CREATE JAVA SOURCE，把 khunt 的 Java code 編譯成可由 SQL 呼叫的內部物件。這種設計讓惡意程式不必依賴磁碟檔案或單純 memory resident 方式存在，而是直接存放在 database 內部，增加一般端點防護工具的可見性盲區。[1][4][16]
khunt 內含多個模組，其中 KhuntCmd 可透過 Java 呼叫 Windows 的 cmd.exe，讓攻擊者把特定 SQL statement 轉成 OS command execution；KhuntHash 則可讀取 Oracle internal user table，匯出帳號與 password hash；KhuntT 用於確認工具是否部署成功；KhuntUnzip 則用來解壓縮檔案。[4][16]
在這起事件中，攻擊者實際操作 KhuntCmd 開啟 Windows command shell，藉由 cmd.exe 達成 remote code execution，並取得 SYSTEM 權限。[2][16] 之後又使用 reg.exe、esentutl.exe 與 PowerShell 操作 Windows Registry，複製包含 SECURITY、SYSTEM 與 SAM 的 Registry Hive，以利後續擷取與解碼本機帳號的 password hash。[2][6][16]
這類攻擊的關鍵，不只是 SQL injection 造成資料外洩，而是資料庫被轉化為執行平台。當惡意物件已存在於 database 內部，攻擊者即可透過 SQL 與 PL/SQL wrapper 持續觸發 Java method，形成一條由 web app、database 到 Windows OS 的完整攻擊鏈。[1][4][6]
這次事件的直接風險，是 Oracle database 所承載的應用服務與 Windows host 同時暴露在高權限風險下。若攻擊者成功取得 SYSTEM 層級控制，不僅可執行任意 OS command，還可能進一步存取 Registry Hive、帳號雜湊與系統設定，導致憑證外洩與橫向移動風險上升。[2][16]
更值得注意的是，傳統 EDR 與防毒產品多半聚焦在 process、function call 與 file behavior，對 Oracle database 內部的 Java class 與 PL/SQL wrapper 可視度有限，因此即使主機層已部署防護，攻擊者仍可能在 database 層悄悄駐留並反覆執行指令。[1][16]
從防守角度看，受影響的不只是單一資料庫，而是所有將 Oracle database 暴露給 web application、且缺乏 input validation 與 parameterized query 的環境。若資料庫帳號被賦予過大權限，攻擊者便可能從一般使用者查詢一路升級到可建立 Java source、呼叫儲存程序，形成高衝擊的權限濫用。[1][4]
第一，必須在 application layer 落實 input sanitization 與 query parameterization，避免使用者輸入直接進入 SQL statement。這是阻斷 SQL injection 的根本措施，也是整起攻擊鏈最前端、最重要的控制點。[1][4]
第二，應嚴格檢視 Oracle database account 的權限配置，特別是是否允許建立 Java source、呼叫高風險儲存程序、或存取不必要的 system capability。資料庫權限若過大，攻擊者即使只拿到一般帳號，也可能擴大為可執行 OS command 的高權限存取。[1][4]
第三，企業不能只依賴 EDR 或 antivirus。由於這類惡意工具以 database object 形式存在，應同步加強 SQL audit、異常物件建立告警，以及對 CREATE JAVA SOURCE、PL/SQL wrapper 與可疑 stored procedure 的稽核。[1][16]
第四，應針對對外服務的 Java/Tomcat application 與 Oracle database 建立最小暴露面，避免不必要的外部連線與管理介面對網際網路開放。當入口面越大，攻擊者越容易以低門檻方式找到可利用的 SQL injection 點。[4][19]
第五，若已發現可疑的 Java object、異常的 SQL statement、或 Windows 上出現 reg.exe、esentutl.exe、PowerShell 連動操作，應立即進行 incident response，包含隔離主機、檢查 Registry Hive 是否外洩、比對 database object 變更紀錄，並重建受影響帳號與憑證。[2][16]
5步驟修補清單