文章总结： 本文剖析金融企业因使用篡改版PL/SQL工具遭受RushQL勒索攻击的案例。攻击者通过供应链投毒植入恶意脚本，利用数据库运行特征潜伏并触发勒索。文章还原了攻击路径，解析了病毒利用Oraclewrap加密及触发器的技术细节。建议建立软件白名单、强化权限审计与安全意识，及时清理恶意对象，以防范供应链风险。 综合评分： 90 文章分类： 恶意软件,供应链安全,应急响应,实战经验,数据安全

金融防线何以失守？一起运维工具“投毒”引发的勒索风暴

让数据更安全 让数据更安全

德斯克安全小课堂

2026年2月2日 10:49 江苏

**摘要：

勒索病毒攻击早已是屡见不鲜的事情了，笔者之前从业的机构就曾中招过勒索病毒。从2017年Wannacry勒索病毒席卷全球开始，其热度一直居高不下，一旦企业中招勒索病毒，这将成为其挥之不去的噩梦。一些黑灰产组织甚至已经将勒索病毒做成了saas化服务，并通过订阅和佣金机制进行大规模推广，这使得勒索病毒趋于产业化发展。本篇文章以运维工具供应链攻击为例（真实事件），阐述金融企业是如何难逃勒索攻击的，旨在引起行业共鸣（安全真心不好做）。

一、事件背景

某银行DBA运维人员在巡检内部Oracle数据库时发现异常连接信息，通过查看数据库的alert日志，发现存在数据库勒索提示信息（详见如图），进一步排查发现，数据库中被创建有未知的触发器DBMS_CORE_INTERNAL，怀疑中招数据库勒索病毒，于是报告安全团队。根据日志记录的告警信息显示，该勒索病毒是由“SQL RUSH Team”组织发起，并且给出比特币勒索钱包的地址。查询网上已有的威胁情报信息发现，该病毒名为RushQL，最早于2016年11月出现，虽不是什么新兴的病毒，但是其攻击造成的影响堪比“核弹”。

二、事件溯源

这是一起典型的PLSQL供应链工具投毒攻击事件，攻击者主要在互联网上各个热门软件下载站进行广撒网，其攻击对象非常明确，就是企业数据库运维人员或者开发人员。攻击的目标企业也非常明确，从其代码设计看，主要是针对运行持久稳定的成熟企业进行勒索攻击。本次事件的具体的攻击传播路径见下图：

整个攻击事件的分析溯源过程还原如下：

根据数据库的报错信息出现的时间点，检查该时间点相关的oracle登录日志。发现员工张某曾经通过其个人云桌面的PLSQL工具远程连接了数据库服务器，并在登录后十几秒后创建了恶意触发器，见下图：

利用系统管理员权限强行登录员工张某的虚拟云桌面，发现其使用的PL/SQL数据库连接工具所在目录为：D:\技术\oracle\PLSQL Developer，其中，PLSQL Developer文件夹为同目录下压缩文件“PLSQL+Developer+11.06最新中文绿色注册版”解压而来，详见下图：

通过将张某云桌面中的PLSQL Developer与合法可靠的目录文件进行逐一比对，发现有个AfterConnect.sql文件明显存在异常。正常情况下，该文件大小应该为0KB，本次事件涉及的样本大小显示为35KB（见下图），提取该文件进行详细分析（具体分析见第3节），发现确实含有RushQL勒索病毒代码。

通过对当事人张某进行询问，发现其因工作需要，自行通过某互联网下载渠道下载了PLSQL Developer压缩包，并拷贝至云桌面中进行了解压操作，考虑到云桌面中的杀毒软件并未报毒，因此未曾留心。

进一步在隔离终端上验证发现，直接复制拷贝AfterConnect.sql文件压缩包，杀毒软件不会识别查杀，但是在解压释放这个恶意文件时，杀毒软件是能够直接隔离恶意文件的，见下图。

通过提取杀毒软件的运行日志发现，在较长时间内，其核心杀毒引擎一直处于失效的状态，经过原厂技术分析后，判定是由于某次软件升级过程中出现了偶发性bug，导致个别终端的杀毒引擎升级后未能正常运行，你看这事给闹的。

三、技术深度解析

通过分析提取出来的AfterConnect.sql恶意文件，发现代码采用了Oracle数据库专用代码加密工具wrap进行了加密，见下图：

我们直接使用解密工具DfUnWraper进行解密，发现解密后的样本代码与网上曝光的RushQL勒索病毒代码完全一致，见下图。

该恶意代码的主要功能是创建3个触发器和4个存储过程。

触发器 DBMS_SUPPORT_INTERNAL

触发器 DBMS_SYSTEM_INTERNAL

触发器 DBMS_CORE_INTERNAL

存储过程 DBMS_SUPPORT_INTERNAL

存储过程 DBMS_STANDARD_FUN9

存储过程 DBMS_SYSTEM_INTERNA

存储过程 DBMS_CORE_INTERNAL

RushQL勒索病毒的恶意之处在于它具有较长的潜伏期，因为感染RushQL后并不会立即加密数据造成业务影响，而是判断数据库的创建时间是否大于1200天，创建时间短的数据库根本不是作者的菜。当然，如果中招用户在规定时间内未及时缴纳勒索赎金的话，勒索程序将会默认删除所有的表。

备注：DfUnWraper是一个用于解密 Oracle 数据库中加密 PL/SQL 代码的第三方工具，操作比较简便，直接将加密的文本粘贴进软件窗口后，点击unwrap即可一键解密。如果对wrap加解密感兴趣的，请自行访问oracle官网或者通过CSDN学习了解。

• 触发条件1-DBMS_SUPPORT_INTERNSL（数据库重启）

在数据库重启后会触发DBMS_SUPPORT_INTERNSL触发器，该触发器及存储过程关键操作有两个：

1. 备份sys.tab$表，并删除非sys（owner#=38）用户的表信息，导致业务对象无法访问；
2. 清除控制文件中的备份信息（包含归档、备份集、备份片、备份数据文件），让DBA误认为备份信息不可用。

• 触发条件2-DBMS_SYSTEM_INTERNAL（数据库登录）

1. 非’SYSTEM’，’SYSAUX’，’EXAMPLE’表空间如果存在大于1200天没有更新统计信息对象，会提示用户中病毒；
2. 非C89239.EXE客户端进程登录数据库会提示用户中病毒。

• 触发条件3-DBMS_CORE_INTERNAL（数据库登陆）

该触发器逻辑可能会导致业务数据丢失，在登陆数据库后触发DBMS_CORE_INTERNAL存储过程：

1. 如果’SYSTEM’，’SYSAUX’，’EXAMPLE’表空间存在大于1200天没有更新统计信息对象，则会自动生成JOB，truncate非ORACHK和$关键字表；否则提示“数据库已被SQL RUSH Team锁死。

四、应急响应建议

1. 如果感染RushQL病毒，但尚未触发勒索加密条件的情形：删除以下触发器和存储过程，并清理带毒的PLSQL工具。

• 存储过程 DBMS_SUPPORT_INTERNAL
• 存储过程 DBMS_STANDARD_FUN9
• 存储过程 DBMS_SYSTEM_INTERNA
• 存储过程 DBMS_CORE_INTERNAL
• 触发器 DBMS_SUPPORT_INTERNAL
• 触发器 DBMS_ SYSTEM_INTERNAL
• 触发器 DBMS_ CORE_INTERNAL

1. 如果感染RushQL病毒，并且数据库已遭加密，那只能做乖乖做数据恢复了，肯定不能给钱助长别人的嚣张气焰。

五、安全事件反思

本次事件深刻暴露出，传统边界防御与员工自觉管理之间的矛盾与冲突。攻击者精准利用了运维人员对运维工具的高频使用需求，通过软件供应链“投毒”成功实现初始渗透，并利用企业内部的管理缺陷或者防护短板进行横向扩散，最终导致数据库遭受勒索。

基于本次事件的整体还原给出以下安全建议：

1. 严格推行软件白名单制度。尤其针对数据库管理客户端、ssh远程运维工具等运维类工具，必须建立企业级的软件超市，实现统一的软件分发，彻底阻断非授权工具的安装和运行。
2. 强化权限与行为管控。在开发运维过程中，遵循最小权限原则，严格限制运维账户的高危操作（如触发器创建、批量删除、drop删库操作）。有条件的情况下，可以部署数据库审计平台，实现事前拦截、事中告警、事后审计。
3. 深化安全意识与问责体系。在日常安全管理中，将第三方工具的使用纳入安全培训与考核，明确违规下载、私自安装外部软件属严重违纪行为，并辅以真实案例警示，遇到员工违规，不管是否造成事件影响，该处罚就得处罚，务必做到零容忍。**

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：德斯克安全小课堂 让数据更安全 让数据更安全《金融防线何以失守？一起运维工具“投毒”引发的勒索风暴》