如果把攻击工具藏在哪里，能让杀毒软件和终端检测都抓不到？2026年7月底，一起针对企业网络的入侵给出了一个相当狡猾的答案——直接把后渗透工具包塞进Oracle数据库，以Java对象的形式驻留在数据库内部，连一个可执行文件都不落在服务器磁盘上。
这起攻击由安全公司Huntress发现，时间线锁定在2026年7月27日。当天，其安全平台在一台运行Oracle数据库的服务器上捕捉到凭据窃取行为。进一步排查后，Apache访问日志揭示了一个隐藏在公开Java应用背后的入口：攻击者利用了一个没做输入校验的自动补全搜索功能，通过SQL注入绕过了应用层，直接把恶意SQL命令发送到了后端的Oracle数据库。
Huntress随即追踪到攻击来源IP为178.162.151[.]229，并确认这次入侵并非简单的数据窃取。攻击者在获得数据库控制权后，并没有像常规手法那样上传一堆后门可执行文件，而是充分利用了Oracle数据库自带的Java虚拟机能力，将一整套名为khunt的后渗透工具包编译并存储为数据库内建的Java对象。
这种手法之所以值得关注，在于它直接利用了Oracle数据库的原生功能来规避安全检测。Oracle数据库内置了一个Java虚拟机，并提供了“CREATE JAVA SOURCE”这样的SQL语句，允许开发人员将Java源代码作为模式对象保存在数据库中，并在需要时通过SQL命令来执行。这本是为了在数据库内部运行Java存储过程而提供的便利，但在攻击者手里，却变成了一种高度隐蔽的后渗透执行环境。
Huntress在报告中指出：“这种技术在野外的使用记录非常罕见。”通常，后渗透工具会以独立的可执行文件、脚本或Webshell的形式留在服务器上，安全产品可以通过文件系统扫描、行为监控等方式捕获它们。但把工具包直接编译进数据库内部，不仅躲开了常见的文件层面的检测，还因为工具包与数据库进程融为一体，使得后续的命令执行、文件操作、凭据窃取都像是在进行正常的数据库管理操作，极大地增加了识别难度。
从Huntress的分析来看，攻击者植入的khunt工具包由多个Java组件和PL/SQL包装器构成，功能覆盖了攻击链条的多个关键环节。这个工具包的主要能力集中在三个方面：执行操作系统命令、窃取Windows凭据、管理文件系统。为了把这些能力暴露给攻击者，khunt提供了KhuntCmd、KhuntCopia、KhuntTaskList、KhuntSam等组件，各自分工明确。
其中，KhuntCmd无疑是攻击过程中最核心的模块，它允许攻击者通过SQL调用直接在底层操作系统上执行任意命令。Huntress的调查记录显示，攻击者在完成工具包部署后，做的第一件事就是使用KhuntCmd执行了“cmd.exe /c whoami”命令。执行结果让攻击者获得了一个非常有利的局面——通过Oracle数据库进程执行的命令，竟然拥有Windows服务器上的SYSTEM级别权限。这意味着，攻击者无需再费心进行本地提权，就已经获得了操作系统的最高控制权。
获得SYSTEM权限之后，攻击者立刻开始了凭据收集工作。他们利用PowerShell和Windows内置工具，将SAM、SECURITY和SYSTEM这三个注册表单元文件复制出来。在Windows安全机制中，SAM文件保存着本地账户的密码哈希，SECURITY文件包含一些额外的安全信息，而SYSTEM单元则存储了解密这些信息所需的系统级密钥。拿到这三个文件，攻击者就可以在离线环境中转储本地账户的密码哈希，进而尝试破解或利用哈希传递攻击在内网横向移动。
随后，攻击者还执行了“tasklist /svc”命令来枚举当前所有运行的服务，并将输出结果保存到一个名为“khunttasks.txt”的文件中。这一步的目的很可能是为了摸清服务器的服务架构，识别正在运行的关键业务、数据库实例或者安全软件，以便规划下一步的攻击路径。Huntress分析认为，这些收集到的注册表文件很有可能已经被渗出，但报告并未最终证实文件是否被成功传输至攻击者控制的服务器。不过，从整个攻击行为的连贯性来看，凭据文件被窃取的可能性极高。
从整个攻击链的角度复盘，这次入侵可以分为五个清晰的阶段。第一个阶段是侦察与初始突破，攻击者盯上了面向公网的一个Java应用，该应用运行在Apache Tomcat上，并提供了一个自动补全搜索接口。这个接口接收用户输入后未做严格的参数化处理，直接将输入拼接到SQL查询中，为攻击者打开了一条通往后端Oracle数据库的通道。
第二个阶段是权限提升与持久化植入。攻击者一旦获得了SQL执行权限，就开始利用Oracle数据库的Java虚拟机功能。他们先是将包含khunt工具包的Java源代码通过“CREATE JAVA SOURCE”语句写入数据库，然后通过数据库内部编译机制将其转换成可执行的Java类。接下来，他们又创建了一系列PL/SQL包装器，这些包装器的作用是把底层的Java方法封装成数据库存储过程，使得攻击者后续只需执行简单的SQL调用，就能触发操作系统级别的命令或文件操作。这种将攻击工具直接存放在数据库模式中的做法，相当于在受害者环境中安装了一个完全依赖数据库运行的后渗透框架，即使服务器上的防病毒软件更新了特征库，也几乎不可能扫描到数据库内部存储的Java对象。
第三个阶段是命令与控制测试。攻击者没有急于大规模行动，而是先用“whoami”命令确认了权限等级。这一操作非常典型，通常后渗透的指挥者需要先了解自己手上的权限有多高，再决定下一步是横向移动、收集信息还是深入挖掘高价值目标。系统返回SYSTEM权限后，攻击者立即转入凭据窃取。
第四阶段是凭据与信息收集，这也是这次攻击中最有威胁性的行为之一。通过复制SAM、SECURITY和SYSTEM注册表单元，攻击者可以离线转储所有本地账户的NTLM哈希。在Windows域环境中，一旦本地管理员账户的哈希被破解或用于Pass-the-Hash攻击，攻击者就有可能获得域内其他系统的控制权。配合服务枚举获得的任务列表，攻击者可以绘制出整个服务器的运行状态，为下一步横向移动做好准备。
第五阶段则是数据渗出与持久化驻留。虽然Huntress没有最终确认数据是否被成功窃取，但攻击者已经完成了渗透最耗时的步骤——建立隐蔽的持久化通道。利用khunt工具包，攻击者无需在服务器上留下Webshell文件，也无需添加计划任务或注册表启动项，只需在数据库里保留一个Java对象，并确保数据库服务运行，就能随时通过SQL命令激活后渗透功能。这种持久化方式，使得传统的应急响应手段，比如扫描文件系统中的可疑文件、检查异常进程或网络连接，都可能完全失效。
从安全防御的角度来看，这起事件暴露出一类长期被忽视的风险：面向公网的应用数据库账户往往被授予过高的权限。Oracle数据库提供的Java虚拟机功能虽然强大，但对于绝大多数Web应用来说，根本不需要在数据库账户层面拥有创建Java源代码的权限。Huntress在报告中明确指出，面向公网的应用所使用的数据库账户，应严格限制其权限，不允许拥有创建Java源、执行不必要的存储过程或进行其他管理类操作的能力。
事实上，许多组织在部署Java Web应用时，为了配置方便，往往会给应用配置一个具有DBA级别权限的数据库连接账户，或者至少赋予其过多的系统权限。这种过度授权一旦遭遇SQL注入漏洞，攻击者就可以直接调用数据库里的高危功能，而不是仅仅局限于增删改查数据。本起攻击中，攻击者能够成功将khunt工具包编译为Java对象，正是利用了应用账户拥有的“CREATE JAVA SOURCE”权限和相关的JVM功能，这无疑是一记针对权限管控不当的响亮警钟。
除了权限控制，输入校验的缺失同样是本次入侵的根源。攻击者利用的那个自动补全搜索接口，没有对用户输入做任何参数化查询处理，让攻击者能够注入任意的SQL命令。在软件开发实践中，对所有用户输入进行严格的输入验证，并使用预编译的SQL语句来彻底杜绝SQL注入，是最基础的安全要求。然而，直到2026年，面向公网的应用依然因为这种古老的漏洞被攻破，并且是以一种极为隐蔽的后渗透手法完成攻击，这反映出安全基线的落地仍然存在巨大的现实差距。
也正因为这类攻击的隐蔽性极高，安全运营人员需要特别关注数据库层面的异常行为。例如，突然出现的Java源对象、新增的PL/SQL包、不寻常的对sam文件或注册表单元的访问尝试，以及数据库进程调用cmd.exe或powershell等系统命令，都应当作为高优先级告警进行排查。同时，Huntress的报告也间接揭示了一个残酷的现实：攻击者往往不是在漏洞被公开后才采取行动，而是在漏洞存在的每一刻都在尝试利用。
综合来看，这起将后渗透工具包直接植入Oracle数据库内部的事件，刷新了很多人对数据库攻击面的认知。攻击者不再满足于只是导出数据或者在服务器上放木马，而是将目光对准了数据库本身的原生扩展能力，把一套完整的后渗透框架悄无声息地嵌入了业务系统的核心。对于防守方而言，要想发现这类威胁，单纯依赖端点检测和响应或者基于文件的扫描已经远远不够，必须深入到数据库内部的对象变化、权限使用以及异常命令执行当中，才能真正压缩攻击者的隐蔽空间。
热门跟贴