Oracle 数据库被黑成跳板，SQL 注入这个老坑 2026 年还在伤人

数据库被黑成跳板，这事比想象中严重

这两天安全圈有个事挺值得说道：安全公司 Huntress 发现，有黑客入侵了一家公司部署的 Oracle 数据库，然后拿它当跳板，直接打穿了 Windows 系统，连用户密码都偷走了。乍一听好像是"又一起数据库泄露"，但仔细看攻击链路，你会发现这伙人玩得是真花。

整件事的起点其实特别朴素——这家公司有个对外提供服务的应用，没对用户输入做有效检查，被黑客用 SQL 注入拿到了系统控制权。说实话，SQL 注入这种漏洞都 2026 年了还能打穿企业系统，多少有点"老古董复辟"的意思。但后面的操作才是重点：黑客没有把恶意工具存成文件，也没驻留在内存里，而是利用 Oracle 数据库自带的 Java 虚拟机（OJVM），通过 CREATE JAVA SOURCE 语句，把一套叫 khunt 的后渗透工具包直接写进了数据库内部。

khunt 工具包到底干了什么

安全公司把这套工具包拆开看了一遍，里面模块还挺齐全：KhuntCmd 模块能调用 Windows 的 cmd.exe，让黑客通过 SQL 语句直接执行操作系统命令；KhuntHash 模块负责读取 Oracle 内部用户表，把账号信息和密码哈希导出来存文件；还有 KhuntT 用来确认工具装没装成功，KhuntUnzip 用来解压文件。外围还包了一层 PL/SQL 包装程序，用来调用底层的 Java 方法。

实际攻击里，黑客用 KhuntCmd 启动了 Windows 命令行，拿到 SYSTEM 级权限，然后调用系统自带工具操作注册表，把包含敏感信息的注册表 Hive 文件复制出来，破解本地账户。一套流程下来，数据库、操作系统、账号密码全被拿捏了。

为什么杀毒软件拦不住

这次攻击最阴的地方在于藏匿方式。传统 EDR 和杀毒软件盯的是进程、函数调用、文件行为，可黑客把恶意代码做成了数据库对象——Java Class 和 PL/SQL Wrapper 躺在数据库里，对安全软件来说就像数据库正常运行的一部分，压根不会触发告警。等于说，数据库这个"数据仓库"被改造成了"武器库"，而安全团队还盯着门口看。

这也给所有 DBA 和运维提了个醒：数据库权限管理真的不能懒。攻击者能写 Java 源码、能执行存储过程，前提是数据库用户权限给得太宽。很多公司图省事，一个高权限账号从开发用到生产，出了事连排查方向都没有。

这几点防护建议，建议直接抄作业

Huntress 给的防范建议其实都是老生常谈，但每一条都踩在点子上：第一，输入校验和查询参数化必须做扎实，别让 SQL 注入有缝可钻；第二，数据库用户权限遵循最小化原则，别给应用账号开 DBA 级别的权限；第三，定期审计数据库里的 Java 对象和存储过程，看看有没有来历不明的"数据库对象"；第四，数据库和操作系统层面都做好日志留存，攻击链再隐蔽，日志里总会留下痕迹。

说句实在话，安全这东西，攻防双方永远在赛跑。黑客永远在找新的藏匿方式，防守方只能把基本功练扎实——参数化查询、最小权限、日志审计，这三板斧看着不起眼，但真能拦住绝大多数攻击。这次 Oracle 的案例算是给行业提了个醒：数据库不只是存数据的地方，它也可能成为攻击者的"跳板"，该上的防护一个都不能少。