@计算器，赶紧接受这个比特币“勒索病毒”的应对指令吧！

风险从来都不是虚构的和肤浅的。 就在你意想不到的时候，风险可能会突然降临到我们身上。

发现比特币勒索软件

企业账户无法连接到数据库

2018年7月18日上午10点左右，某公司的数据库使用企业账号无法连接数据库。 尝试使用PL/SQL连接时，要么无响应卡住，要么十多分钟连接不上。

只需直接登录服务器并使用此企业帐户进行连接即可。 登录后，使用SYS用户很快就可以连接了，但是这个企业账号一直卡住，连接不上，如下图：

检查操作系统后，发现CPU和内存占用率都很高。 也是11点34分，午休时间，匆忙关闭数据库，重启操作系统，再重启数据库。 于是就去午休了，心想大事解决了，可以午休了。

吃完饭12点45分左右，回来后用“CONN企业账号/密码”登录。 等了十多分钟，还是登陆不上，排除数据库监控没有问题（因为期间上次是用PL/SQL登陆的），我开始怀疑是不是网络的原因，于是开始查网络，用Ping命令开始Ping主机名，localhost，127.0.0.1没有问题。

使用tnsping的时候没发现问题。 参考网上说是因为域名不对，于是去查看域名cat /etc/resolv.conf，没有发现异常。 其他服务器也是如此。

已经1点30了，还没找到原因，更麻烦的是，业务人员告诉业务系统打不开，网页直接报500错误，坏掉了，并立即登录业务服务器查看日志。

果然不出所料，数据源已经断开，日志中出现大量无法连接数据源的错误。 当时没有仔细查看报错时间，就立即停止了业务应用。

冷静分析后，想到查看Alert日志。 看日志的时候惊呆了。 顿时傻眼了。 看到这条消息：

感觉秒了，比特币攻击？ 这怎么可能？ 内网环境，云服务器，这怎么能被攻击呢？

2018 年 7 月 18 日星期三 11:24:46

文件/u01/app/oracle/admin/YXXXX3/udump/xxxxxx3_ora_2674.trc 中的错误：

ORA-00604: 在递归 SQL 级别 1 发生错误

ORA-20315：您的数据库已被 SQL RUSH 团队锁定 将 5 个比特币发送到此地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE（大小写一致），然后将您的 Oracle SID 邮寄至 sqlrush@mail.com 我们将让您知道如何解锁您的数据库数据库被SQL RUSH Team hack，发送5个比特币到地址166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE（区分大小写），然后将你的Oracle SID发送到邮件地址sqlrush@mail.com，我们会告诉你如何解锁数据。

ORA-06512：在“FXXXX.DBMS_CORE_INTERNAL”，第 27 行 ORA-06512：在第 2 行

2018 年 7 月 18 日星期三 11:25:22

线程 1 前进到日志序列 7963

当前日志# 2 seq# 7963 mem# 0: /data/XXXXX3/redo02.logWed Jul 18 11:25:54 2018

线程 1 无法分配新日志，序列 7964

检查点未完成

当前日志# 2 seq# 7963 mem# 0: /data/XXXXX3/redo02.log

线程 1 前进到日志序列 7964

当前日志#1 seq#7964 mem#0:/data/XXXXX3/redo01.log

2018 年 7 月 18 日星期三 11:26:28

文件 /u01/app/oracle/admin/XXXXX3/udump/xxxxx3_ora_2710.trc 中的错误：

ORA-00604: 在递归 SQL 级别 1 发生错误

ORA-20315：您的数据库已被 SQL RUSH 团队锁定 将 5 个比特币发送到此地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE（大小写一致），然后将您的 Oracle SID 邮寄至 sqlrush@mail.com 我们将让您知道如何解锁您的数据库数据库被SQL RUSH Team hack，发送5个比特币到地址166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE（区分大小写），然后将你的Oracle SID发送到邮件地址sqlrush@mail.com，我们会告诉你如何解锁数据。

ORA-06512: 在“FMXXXXX9.DBMS_CORE_INTERNAL”，第 27 行

ORA-06512: 在第 2 行

2018 年 7 月 18 日星期三 11:26:29

线程 1 前进到日志序列 7965

当前日志# 3 seq# 7965 mem# 0: /data1/XXXX3/redo03.log

2018 年 7 月 18 日星期三 11:27:04

但是看到这个告警日志比特币程序，不得不相信这是SQL RUSH Team干的又一件好事，这和2016年11月爆发的比特币攻击案明显如出一辙。

参考CSDN上的一篇文章，看到有类似的触发器和存储过程。

- 扳机

“DBMS_CORE_INTERNAL”；

“DBMS_SYSTEM_INTERNAL”；

“DBMS_SUPPORT_INTERNAL”；

--存储过程

“DBMS_CORE_INTERNAL”；

“DBMS_SYSTEM_INTERNAL”；

“DBMS_SUPPORT_INTERNAL”；

-- 查看存储过程

从 user_source WHERE NAME = 'DBMS_SYSTEM_INTERNAL' 中选择文本

按行排序；

-- 查看触发器

从 all_triggers 中选择 trigger_name

其中 table_name='DBMS_SYSTEM_INTERNAL'；

经查，发现客户的企业用户XXX下至少创造了45万个工作岗位。 由于内容太多，我尝试简单的拼了一条SQL删除了有问题的JOB。

选择“执行 dbms_ijob”。 删除（'||工作||'）;'

来自 dba_jobs

其中 schema_user='FXXX' 和'%truncate%';

这样的语句检查了10多分钟，将近20分钟，没有执行。 有多达450,000个工作岗位。 我别无选择，只能等待。 期间查看了Alert日志，发现从10点23分开始，日志一直在频繁切换日志。

2018 年 7 月 18 日星期三 06:00:16

线程 1 前进到日志序列 7953

当前日志# 3 seq# 7953 mem# 0: /data/XXXXX3/redo03.log

2018 年 7 月 18 日星期三 10:23:52

线程 1 前进到日志序列 7954

当前日志# 2 seq# 7954 mem# 0: /data/XXXXX3/redo02.log

2018 年 7 月 18 日星期三 10:25:54

线程 1 前进到日志序列 7955

当前日志#1 seq#7955 mem#0:/data/XXXXX3/redo01.log

2018 年 7 月 18 日星期三 10:30:39

线程 1 前进到日志序列 7956

当前日志# 3 seq# 7956 mem# 0: /data/XXXXX3/redo03.log

由此可以判断一定有DDL操作，所以使用如下语句查看今天的DDL操作：

从 DBA_OBJECTS A 中选择 *

WHERE TO_CHAR(A.last_ddl_time,'YYYY-MM-DD')='2018-07-18'

AND OBJECT_TYPE='表'

按 A.last_ddl_time DESC 排序；

发现使用业务账号的TRUNCATE语句很多，当时的查看结果没有保存。 不完全统计有70多张表被TRUNCATE删除。

这个业务账号的业务量不大，日常操作也很少，所以大部分业务表几乎都删掉了。

数据库基本瘫痪了。 此时已经是下午3点05分，SYS用户无法登录，只能重启操作系统，重启数据库，再用SYS用户正常连接。

然后执行命令alter system set job_queue_process=0 scope=both; 并重启数据库（为什么要重启？因为此时数据库肯定产生了大量的library cache锁，无法操作）。

重启后可以使用SYS连接，于是再次关闭数据库，做物理冷备份。

冷备完成后，启动数据库连接后检测到45万多个JOB，复制到Excel，然后在命令行执行65535 exce dbms_ijob.remove(806141)； 但是这个时间比较长，65535行执行了大约一个多小时。

期间无意中进行了RMAN全量备份，导致后续恢复出现问题。 这个我以后再说。 这65535条删除完成后，我想进行下一次的删除操作，但是我想按照这个时间，我至少要删除10多个小时，还是想其他的办法。

数据库恢复

所以，还是使用RMAN进行恢复，大概先了解一下这个数据库的备份策略：登录服务器通过定时任务查看RMAN的执行情况：

顺便看了一下备份脚本，可以看到每周日全量备份，每天增量备份。 查看日志备份没有问题，还是可以恢复的。 备份脚本如下，供参考：

但是，备份和恢复仍然需要对日志进行归档。 查看归档日志，发现是在同一天的6:00和10:23归档的。 无法判断10:23的存档是否可用。

所以决定做不完全恢复，恢复到6:00，咨询业务人员说6点以后就没有业务了，可以这样恢复。

于是就忙着恢复，本来打算在测试库里恢复一次看看效果，但是测试库的工作半天都没有做完。 遇到瓶颈的时候，测试库和官方库几乎是同步的，名字也一样。 很难恢复，尝试各种方法，已经是晚上8点多了。 没办法，直接在官方库里恢复。

归档日志操作

为什么这么说呢，归档日志是连续的，所以10点23分的归档改名了，这样归档就不连续了，后面的归档就不能用了，那为什么要这样呢，因为前面一个是根据时间点恢复的比特币程序，语句如下：

跑步 {

启动强制安装；

分配通道c1类型磁盘；

分配通道c2类型磁盘；