勒索病毒频发，信息安全事件如何破 --记两次勒索病毒数据恢复实例

勒索病毒怎么破

记录两次客户中勒索病毒恢复的情况。 2020年5月在公众号‘成文数科’写的文章，现在安全事故愈发频繁。故重新贴到CSDN来

勒索病毒的前世今生

2017年4月14日晚，黑客团体Shadow Brokers公布“永恒之蓝”工具，该工具可利用Windows系统的共享文件服务漏洞获取系统最高权限。不久后，不法分子通过改造“永恒之蓝”制作了wannacry勒索病毒，英国、俄罗斯等欧洲国家以及中国国内多个高校校内网、大型企业内网和政府机构专网中招，被勒索支付高额赎金才能解密恢复文件。
此后，wannacry和各种变种的勒索病毒肆虐全球

想必中过招的朋友对下图非常熟悉

勒索病毒为什么可怕

我们作为软件服务商，在2017年开始已经碰到非常多起勒索病毒的事件，很多客户由此造成数据丢失，系统停运等各种问题带来的损失无法估量，勒索者通常索取BTC(一种基于区块链技术的电子货币),由于BTC匿名的特点，报案也是无法追溯到作者的。所以我们也剖析了一些勒索病毒原理：

首先攻击者获得权限后，通常采用给快速的对称加密算法对文件加密后，使用非对称加密将密钥进行加密，常用的加密算法RSA、Elgamal等

加密算法和BTC这里不详细说，感兴趣的朋友可以搜索一下相关信息详细了解，总之采用这种加密勒索BTC，以目前计算机的算力不通过私钥解密是不太可能的，也无法通过合法途径报案追溯犯罪者。

我们在17-19年中碰到的勒索病毒案例中发现，勒索病毒为了快速的对系统中所有数据文件的加密，通常对大文件仅加密头部信息通过破坏文件完整性的方式，这种情况下，对数据库实体文件来说是可以通过数据库修复工具进行非加密部分数据的提取从而进行修复。

但在最近我们接到的3起勒索病毒事件请求中，不管多大的数据库文件都被全部加密了，剖析了部分勒索病毒源码发现新的勒索病毒变种几乎都改变了加密机制，变成先快速全盘数据文件加密后，对没有100%加密的文件定时进行逐步加密到100%，也就是如果是在中招后，如果在100%加密之前没有发现和清除病毒，想要恢复文件就只有找作者交赎金这一条风险很高的路可走，这也是我们写这篇文章的原因，希望大家能事先做好防护，事后补救可能为时已晚

恢复实例

1.通过数据库修复某药企用友U8财务系统数据库

在收到客户反馈后，我们对比了一下有备份的文件和被加密文件，发现这种只是头部数据加密破坏了数据的完整性，所以重装软件也无法附加被破坏的数据库实体文件，如下图

接下来我们通过数据库修复工具，读取加密的数据库实体文件中的表和数据，可以把正式环境数据恢复98%左右

此时这种情况下，距离完全恢复仅一步之遥，这种情况我们询问了客户是否有前一段时间的完整备份，客户反馈完整可用的备份是一个月前的。于是我们通过把一个月前的正常的数据作为对比，两个库对U8中相关的系统参数表/基础资料/总账凭证/固定资产/余额表/辅助账表等逐一进行排查，最终完全恢复了数据，恢复在用友U8中正常使用

2.代向勒索者交赎金获取密钥解密（某上市药企WMS系统数据库）

2020年1月份，临近春节假期。一个曾找我们开发过ERP-WMS接口的客户信息部来电反馈仓库系统无法运行，疑似中勒索病毒。经远程验证后确实中了后缀.chch的CrySiSV2家族勒索病毒。数据库修复工具读取账套，数据大部分还是可以修复的。

但经了解客户的情况，数据库实体50多G，WMS系统通过数据库的存储过程和一些配置性xml文件实现的二次开发，程序文件和数据库均未曾做过任何备份。

基于以上情况，如果数据库和配置文件不能100%修复也没有意义，系统还是跑不起来。于是跟客户领导领导沟通后，最终拍板由我们代付BTC赎金，获取私钥解密文件

于是我们联系了勒索信中的邮箱 [email protected]，用我小学水平的英语简单粗暴的问了多少钱，对方马上有了回复，0.3BTC

0.3BTC大概要多少钱呢，按当天BTC的市值换算了一下，19800，大约两万块

后续往来了很多邮件，过程也略曲折，最后还价到了0.22BTC成交，为了取得信任，作者让我们提供了被加密的小文本文件证明他手上有解密私钥（这步很关键，如果对方有解密的私钥，一般大概率付费后会提供私钥），以及先提供了btc地址做了个0.01btc付费的测试。

往来邮件：

最终作者发过来了解密私钥程序 ，通过该程序放在加密文件下运行，解密了所有加密文件恢复了系统的运行

可以看到作者来的解密程序，为什么有两个呢，是因为管理员在没有清理病毒的情况下，直接改了文件后缀名，从而被加密了两次，得亏付钱后作者还有耐心多生成了一个ID的解密程序，此次恢复实属万幸

所以切记，碰到中勒索病毒情况一定不要自己去处理，可能造成无法恢复的后果。第一时间应该拔掉网线关机，把硬盘挂载其他系统拷出数据，才有最大可能恢复

追溯原因

近几年我们处理过的勒索病毒的情况，都分析了相关日志文件进行攻击溯源，发现普遍（95%）以上都是运维人员安全意识较薄弱，将RDP服务用默认端口3389和默认超管administrator弱密码开在外网,被扫描后暴力破解进入系统。
以下是我司一台在阿里云的服务器临时放开了RDP端口访问的登录日志

![sjck.png][13]

可以看出暴露在外网RDP服务无时不刻都有人在挂代理扫描端口，只有中一次密码则立马中招

总结

经过多次勒索病毒的处理，简单总结了几点经验，希望对大家有所帮助

1. 备份，备份，备份。重要的事情说三遍，特别是要定期做好离线备份
2. 网络的分区分域，让攻击限制在局部
3. 服务器尽量使用Linux，性能好安全性高，虽然也有针对Linux的勒索病毒，相对难度会更高
4. RDP远程桌面不要使用默认端口和默认超管用户，做好网络的权限梳理和基于端口的访问策略
5. 定期排查日志和用户管理中记录是否有可疑情况

只要能做到以上几点，基本可以杜绝99%的中勒索病毒的可能，但最后还是要说，安全无绝对，勒索病毒这事儿未来一定会越来越多，说了这么多，还是希望大家保持良好的运维习惯，别中勒索，如需要更详细的自救和防护指南，可长按下方图片关注我们，回复‘防勒索’获取勒索病毒自救和防护指南