Oracle遭SQL注入，攻击者直达Windows SYSTEM权限

FreeBuf

2026年8月7日 18:00
上海

在小说阅读器读本章

去阅读

Part01

从SQL注入到Windows SYSTEM

攻击者借助面向公众的Web应用中的SQL注入漏洞，闯入了某组织的Oracle数据库，随后在不向磁盘写入可执行文件的情况下安装了一个后渗透工具包。他们将Java源码提供给数据库，让Oracle将其编译为存储的Schema（模式）对象，并从数据库引擎内部运行命令。

安全公司Huntress将这款工具包标识为khunt。在2026年7月27日触发凭据窃取检测告警后，Huntress展开调查，并将整个攻击链溯源到底层Windows服务器上的SYSTEM级代码执行。

漏洞出在应用程序中：一个自动补全搜索字段通过Java数据库连接（JDBC）将未经校验的输入传递到了数据库。该连接背后的账户拥有足够的权限来创建Java对象。

Part02

技术机制：在Oracle内编译Java

Oracle没有发布任何补丁来修复该应用漏洞，也没有解决其背后的账户权限问题。要发现该工具包，就需要主动搜寻：在Oracle安装中搜索以Khunt开头的对象名称，并在SQL日志中搜索KHUNT%。

被编译为数据库Schema（模式）对象的Java类，不是进程、二进制文件，也不是文件系统上的文件；终端检测与响应（EDR）产品通常不会检查Oracle内部结构。用Huntress的话说，数据库不再是攻击者查询的对象，而成为他们发起攻击的滩头阵地。

Oracle自带一个内嵌的Java虚拟机，CREATE JAVA SOURCE语句允许用户向其提交Java代码，数据库会编译这些代码并将其存储为一个Schema（模式）对象。根据Oracle文档，在用户自己的Schema（模式）中，只需一个系统权限CREATE PROCEDURE即可做到这一点。利用这些代码生成操作系统进程，需要经过Runtime.exec，而Runtime.exec需要单独的文件执行权限。Oracle表示，这些权限只能由特权管理员授予。

Huntress没有说明被入侵账户实际持有哪些授权，也没有说明攻击者是否必须额外添加授权。攻击链最终成功，说明该账户具备这两方面所需的足够权限。

这项技术至少有二十年历史。Marco Ivaldi在2006年编写的raptor\_oraexec.sql创建了一个Oracle源对象，其中包含命令执行和文件读取方法，然后通过PL/SQL包装器将这些方法发布到SQL中。khunt对象使用了相同的基本架构。Huntress表示：“该技术在野利用的情况鲜有记录。”

Part03

khunt模块与后续攻击动作

该工具包由6个Java对象和多个khunt\_\* PL/SQL包装器组成：

KhuntCmd加载cmd.exe，并执行通过SQL传入的任意操作系统命令。
KhuntHash从Oracle的内部用户表读取用户名和密码哈希，并将其写入文件。
KhuntFS和KhuntFS2可列出、读取、搜索文件并获取文件大小。
KhuntT用于确认工具包可被访问，KhuntUnzip用于解压压缩包。

通过KhuntCmd运行cmd.exe /c whoami，返回SYSTEM权限。随后，攻击者使用PowerShell和reg.exe将SECURITY和SYSTEM注册表配置单元复制到F:\Oracle，运行tasklist /svc并将结果写入khunttasks.txt，还使用esentutl.exe复制了SAM和SECURITY配置单元。

Huntress观察到这些文件被暂存在本地，但未能确认它们已被外泄。该公司没有指明任何威胁行为者，只将恶意请求追溯到178.162.151[.]229。

Part04

检测与修复建议

这些失陷指标仅与该工具包相关，因此，仅搜索Khunt或KHUNT%并不能发现其背后的技术。修复方式是：在应用层使用参数化查询和输入校验，并在底层遵循最小权限原则：一个为面向公众应用提供服务的账户，不应能够创建Java源对象，也不应能运行与其无关的存储过程。

参考来源：

Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access

https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html