数据库遭遇.dewar或者.devos结尾的勒索病毒加密的恢复

thunderstorm 2020-05-09

1,devos勒索病毒说明
phobos勒索病毒家族的一款变种勒索病毒近期频繁出现,该病毒会将文件后缀篡改为dewar或者devos,该病毒非常狡猾,近期就有一个客户服务器上的Oracle数据库遇到了该病毒。加密文件如下:

数据库遭遇.dewar或者.devos结尾的勒索病毒加密的恢复

通过对底层存储数据的解析,发现该病毒有如下特点:

  1. 会对服务器上后缀名为dbf、mdf、ibd的文件进行全加密。
  2. 对其他类型的文件进行破坏,破坏规则为从文件头部开始清空256k,并且每间隔10g清空256k。

该病毒非常狡猾,会判断文件类型,专门对数据库数据文件进行全加密,这也让从加密的数据文件中抽取数据变成了一件不可能的事情,唯一的解决方法,就是找***解密。

在对加密文件分析过程中,我们发现该病毒并不会对rman备份文件或者expdp/exp的dmp文件进行全加密,这类文件会从文件头部开始清空256k,并且每间隔10g清空256k。这让我们的恢复产生了一些转机,可以通过rman备份或者dmp文件进行恢复。在本次案例中我们就是利用被加密后的文件来恢复客户的数据库。

2,利用RMAN备份还原数据库
咨询了客户是否有备份,客户防患意识非常好,定期对数据库做了rman备份。

数据库遭遇.dewar或者.devos结尾的勒索病毒加密的恢复
2.1 分析RMAN加密后的文件
截取备份片前1G简单通过dd分析一下:

[ ~]# dd if=rman_1G.bak bs=8192 count=32|od -x
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
32+0 records in
32+0 records out
262144 bytes (262 kB) copied, 0.00326108 s, 80.4 MB/s

不出所料前256k确实被清空了。而且每隔10g还会清空256k(当然这里我们只截取了1g来分析)。

[ ~]# dd if=rman_1G.bak bs=8192 count=1 skip=129|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 6.2713e-05 s, 131 MB/s
a238 0000 0081 0040 d899 ed66 0da3 0401
[ ~]# dd if=rman_1G.bak bs=8192 count=1 skip=130|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 4.6691e-05 s, 175 MB/s
a238 0000 0082 0040 d899 ed66 0da3 0401
[ ~]# dd if=rman_1G.bak bs=8192 count=1 skip=131|od -x|head -1 
0 records in
0 records out
bytes (8.2 kB) copied, 8.2504e-05 s, 99.3 MB/s
a238 0000 0083 0040 d899 ed66 0da3 0401

查看备份片后面一些的block发现块类型为0x38,当时有一种不良的预感,该备份很是压缩的备份集。这给整个恢复带来了非常大的难度。

rman备份默认采用basic压缩,测试使用的压缩算法为bzip2,有了此信息后,我们可以通过手动的方式将加密后的压缩文件进行解密。

3,还原的思路和过程
经过长达几个小时的分析研究,终于比较完美的实现了恢复,数据恢复95%以上达到了客户的要求。大致过程如下:

  1. rman_backup_uncompres.exe d:\backup % d:\backupuncompres
  2. 使用odu工具对解压的备份片把数据文件抽取出来
  3. 使用odu工具对抽取出来的数据文件进行数据抽取
  4. 将odu抽取文件导入新建数据库

4,注意事项
1,生产环境中一定要做数据库备份。
2,备份文件不能存放在数据库所在服务器上。
3,搭建数据库容灾环境,并且做好容灾环境的安全控制。

相关推荐