攻击者在 Oracle 内部编译 khunt，将 SQL 注入转化为 Windows SYSTEM 权限访问

导语：Huntress 披露了名为 khunt 的 Oracle 数据库后渗透工具包：攻击者利用面向公众 Web 应用中的 SQL 注入漏洞向 Oracle 提交 Java 源代码，由数据库自身将其编译并在引擎内部执行，最终在底层 Windows 主机上获得 SYSTEM 级权限，且全程未向磁盘写入任何可执行文件。

攻击者通过面向公众的 Web 应用中的 SQL 注入漏洞入侵了某组织的 Oracle 数据库，并在未向磁盘写入任何可执行文件的情况下安装了后渗透工具包。他们将 Java 源代码送入数据库，由 Oracle 将其编译为存储的模式对象，并在数据库引擎内部运行命令。

Huntress 将该工具包追踪命名为 khunt。该公司于 2026 年 7 月 27 日收到凭据窃取告警后展开调查，并将整条攻击链追溯到底层 Windows 服务器上的 SYSTEM 级代码执行。

漏洞存在于应用层：一个自动完成搜索字段通过 Java 数据库连接（JDBC）将未经验证的输入传递给数据库。该连接所使用的账户拥有足够的权限来创建 Java 对象。Oracle 没有任何补丁可以同时关闭该应用层缺陷或修复账户权限过高的配置问题。要发现该工具包只能靠主动排查：在 Oracle 安装目录中搜索以 Khunt 开头的对象名，并在 SQL 日志中检索 KHUNT%。

被编译进数据库模式对象的 Java 类既不是进程，也不是二进制文件或文件系统上的文件，且端点检测与响应（EDR）产品通常不会检查 Oracle 的内部结构。正如 Huntress 所描述的，数据库不再只是攻击者查询的对象，而成为他们据以发起进一步攻击的滩头阵地。

Oracle 自带嵌入式 Java 虚拟机，CREATE JAVA SOURCE 语句允许用户向其提交 Java 代码，数据库随后将这些代码编译并存储为模式对象。根据 Oracle 官方文档，在用户自己的模式中执行此操作仅需一项系统权限——CREATE PROCEDURE。要从代码中派生操作系统进程，需要使用 Runtime.exec，这本身需要额外的文件执行权限，而 Oracle 明确表示这些权限只能由特权管理员授予。Huntress 并未说明被入侵账户持有哪些授权，也不清楚攻击者是否需要额外添加授权。由于整条链路最终成功，可以确认该账户同时具备这两项操作所需的权限。

该技术至少有二十年的历史。Marco Ivaldi 于 2006 年发布的 raptor_oraexec.sql 通过创建一个包含命令执行和文件读取方法的 Oracle 源对象，然后通过 PL/SQL 包装器将其发布到 SQL。khunt 的对象采用了相同的总体架构。Huntress 表示：“该技术在野利用的公开记录非常少见。”

整个工具包由六个 Java 对象和若干 khunt_* PL/SQL 包装器组成。通过 KhuntCmd 运行 cmd.exe /c whoami 返回了 SYSTEM。攻击者随后使用 PowerShell 和 reg.exe 将 SECURITY 和 SYSTEM 注册表 hive 复制到 F:\Oracle，使用 tasklist /svc 将结果写入 khunttasks.txt，并使用 esentutl.exe 复制了 SAM 和 SECURITY 注册表 hive。

Huntress 观察到这些文件被暂存在本地，但未能确认它们是否被外传。该公司未指认任何威胁组织，并将恶意请求追溯到 IP 地址 178.162.151[.]229。这些威胁指标针对的是该特定工具包，因此任何针对 Khunt 或 KHUNT% 的搜索都无法发现其背后的通用技术。修复方案是在应用层使用参数化查询并进行输入校验，同时贯彻最小权限原则：服务于面向公众应用的账户不应具备编写 Java 源或运行无关存储过程的权限。

来源信息

来源：The Hacker News

原文链接：https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle.html

作者：info@thehackernews.com (The Hacker News)