今天凌晨4:50节点公司400转过来的求助电话，来自广西某个医院的客户;电话中说数据库被攻击了，业务完全停止，言谈之中表现的时分地迫切和着急。

首先我们来看看数据库的日志是什么？

大家不难看出，很明显跟2016年11月份爆发的比特币攻击案例如出一辙。这又是sql rush Team干的好事。很显然，我们去年大力宣传的比特币攻击事件，仍然被很多企业客户所忽视，最终出现了今天的悲剧。言归正转，如何处理这个问题呢？

这里通过日志，直接查询最近有过ddl操作的对象，发现果然跟alert log完全一样。如下所说：

我们不难看出，上述6个对象，可能是问题的关键。那么我们就来看看上面6个对象的内容是什么。首先我们来看下trigger：

很明显，这是hacker创建的恶意trigger。遗憾的看上去名字是这样，具体查不到内容？既然如此，我们先来看看存储过程，发现3个存储过程都是加密的。通过解密之后，发现代码如下：

我们可以看出，SQL rush Team还是很熟悉Oracle的，对于dbms包的利用，比我们都熟悉呀！

通过看上述解密之后的代码，才恍然大悟，Hacker居然是在Trigger和存储过程名称后面加了9个空格；注意是9个空格，一个都不能少。

我们再仔细阅读前面2段代码，可以看出这是比较坑爹一个Heacker。通过轮寻会不断产生truncate table 的Job，而且做这些操作之前会通过表的分析时间来判断数据库的运行时间，如果超过1200天，则爆发这个勒索行为（因为长时间运行，说明数据库是有价值的)。

最后一个存储过程会限制程序等连接，导致客户业务无法访问数据库。

了解了上述3个存储过程之后，解决方法就不难了，大致如下：

1、alter system set job_queue_process=0 scope=both ;并重启db（为什么要重启呢？因为此时数据库肯定已经产生了大量的library cache lock，无法操作)。

2、drop上述trigger 和存储过程：

3、删除Hacker创建的大量Job

经过检查发现客户的业务用户portal_his下面被创建了14万个Job。由于内容实在是太多了，因此简单拼一个SQL来删除有问题的Job。

4、确认被truncate的表。

最后恢复之后，客户反映业务基本上正常，但是仍然有部分业务数据看不到，详查之下发现有部分表的数据看不到了？但是客户也说不上来，到底哪些表有问题？那么怎么判断呢？

其实很简单，通过dba_objects.last_ddl_Time来判断该业务用户下最近被ddl操作的表有哪些即可，最后发现有68个表。通过ODU恢复这部分被truncate的表数据即可。

请大家仔细检查你的环境，不要再出现类似的问题，为自己或公司造成损失！如果遇到此类问题，请联系我们，获取专业技术支持！