“Khunt”攻击内幕：黑客如何将Oracle数据库变成后渗透利用平台

攻击者随后从数据库层“跳板”至底层的Windows操作系统，成功获得SYSTEM级远程代码执行（RCE）权限，提取了包含密码哈希的注册表配置单元并离线外泄 。Huntress已将攻击者基础设施追溯至IP 178.162.151[.]229 。

攻击如何运作：通过自动补全搜索进行的SQL注入

初始访问向量是一个运行在Apache Tomcat上的面向公众Java应用程序中的SQL注入漏洞 。该应用的自动补全搜索功能未能正确验证用户输入，使得攻击者能够通过与Oracle数据库的JDBC连接注入SQL命令 。Huntress研究员指出，这并非新型漏洞——SQL注入攻击存在了数十年，通常是处理传递给SQL服务器的用户输入时处理不当的结果 。仅仅是一个未对简单搜索框进行输入清洗的缺陷，就足以引发整个攻击链条。

Khunt工具包：作为Java对象“住”在数据库中

攻击者没有在受感染服务器上部署传统的恶意软件文件，而是使用Oracle内置的Java虚拟机（JVM）和CREATE JAVA SOURCE语句，将整个后渗透工具包编译并存储为Oracle数据库中的Java模式对象 。这种方法让工具包对标准的操作系统级防御系统“隐形”，因为EDR和防病毒软件关注的是操作系统上的进程、二进制文件和文件——它们通常不会检查存储在Oracle内部的Java类和PL/SQL包装器 。

Khunt工具包包含以下组件，每个都以数据库对象的形式存储：

获取完全系统控制权：从数据库到Windows操作系统

攻击者并未止步于数据库层面的访问。他们使用Khunt工具包通过多步过程从数据库层跳板至底层Windows操作系统：

1. 通过KhuntCmd执行操作系统命令：攻击者使用KhuntCmd模块运行cmd.exe /c whoami，确认自己正以Windows服务器上的SYSTEM级权限运行，从而建立了从数据库到操作系统的远程代码执行（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包装器，使得工具包对标准的操作系统级防御系统“隐形” 。
• 经典漏洞，新颖的交付方式：初始的SQL注入是一个众所周知的漏洞类型。攻击者不需要使用零日漏洞。仅凭自动补全搜索功能就足以抵达PL/SQL，进而渗透到操作系统——这表明，当数据库引擎具备操作系统级能力时，基本的输入验证失败可能导致严重的系统入侵 。
• 过度授权的数据库账户：即使SQL注入成功，如果数据库用户账户没有创建Java源文件或执行存储过程的权限，其造成的损害也有限。然而，企业往往赋予数据库账户过高的权限，为攻击者部署Khunt提供了额外的权限 。

Huntress建议的缓解措施

基于此次攻击，Huntress提出了以下缓解措施 ：

• 对所有Web输入进行适当的输入清洗和查询参数化
• 限制数据库用户权限，确保即使被注入的查询也无法创建Java源文件或执行任意存储过程
• 扩大监控范围，将数据库对象（Java类、PL/SQL包装器）纳入监控，而不仅仅是关注操作系统级别的工件

这次攻击是一个鲜明的警示：当数据库引擎内置编程环境（如Oracle的JVM）时，即使只有一个未经验证的输入字段，也可能使其成为隐蔽的攻击平台。安全团队必须将监控范围从操作系统扩展到数据库对象层面。