被勒索后的72 小时“生死时速”

Posted 2023-04-05 腾讯安全

编者按

数字化浪潮蓬勃兴起，企业面临的安全挑战亦日益严峻。

腾讯安全近期将复盘2022年典型的攻击事件，帮助企业深入了解攻击手法和应对措施，完善自身安全防御体系。

本篇是第四期，复盘了一次勒索病毒的紧急应对事件。一旦染上勒索病毒相当于宣判了重要文件被囚禁在了数字监狱，似乎除了缴纳赎金别无他法。但如果面对的是一个有缺陷的勒索病毒呢？这是建筑工程设计师老张和安全专家zhipeng的72小时竞赛故事。

“如果您在72小时内与我们联系，可以享受50%的折扣”。

一辈子没中过大奖的工程师老张，看到这句话几乎晕厥了。

是心爱之物离自己越来越远的心悸引发的生理晕厥。

因为这不是限时优惠的促销通知，而是一则勒索留言。

勒索筹码是老张电脑中被加密的工程设计图纸，包含了老张建筑工程设计生涯近20年的图纸底稿文件。

无论老张如何操作，电脑中他熟悉的一个个设计图纸文件均无法打开，老张慌了神。

但“贴心的”黑客在“勒索信”上告诉了老张拿回图纸的唯一办法——

“请注意，您永远不会在不付款的情况下恢复您的数据”。

老张赶忙盘算了下家底，要全部赎回文件的话，50%的赎金是他能接受的范围。

这也意味着，老张要在72小时内做出选择。

“我就是下载了一个软件”

老张起初并不知道这是勒索病毒，当他发现电脑桌面不正常，文件格式都变成了像是乱码的后缀时，他本能的关机重启。

只是再次亮起的电脑屏幕依然是那些陌生的图标和无法点击的文件，老张才意识到，可能是电脑出了故障，这一次他没有丝毫犹豫就按了关机。

和周围的朋友咨询后,老张知道了这叫勒索病毒，知道了这是当今最臭名昭著的病毒，也知道了这是一种无法解决的网络病毒。但老张更想知道，如何才能解救染毒的图纸。

几番推荐和介绍后，腾讯安全云鼎实验室的专家zhipeng介入了这次事件。“面对勒索病毒整个业界都没有很好的解决方案，目前能解密的勒索基本都是使用公开的密钥进行解密恢复”，zhipeng对这次挑战并不是信心满满。无法直接分析可能是这次解题的一大难点。彼时由于疫情隔离，zhipeng只能先进行远程分析。

如同探究每一道安全难题一样，定位析因是zhipeng的第一步——弄明白老张是如何中招的。这一步并不难，通过对最近几次的电脑操作复盘后，zhipeng很快就发现这是一次典型的“水坑攻击”——在受害者必经之路上制作陷阱，守株待兔。

软件下载站就是那条“必经之路”，相比直接通过漏洞入侵到个人电脑这种费时的攻击方式，将病毒直接嵌入在各种用户经常下载的软件站里，等待受害者自动上门这种以逸待劳的方式更具效率。

至此，攻击链条基本浮出水面——老张在非官方软件下载站下载了一个软件，结果该软件被植入了勒索病毒。病毒程序在电脑本地下载安装后就开始运行，迅速加密电脑中的文件。“优先寻找的基本是带有Word、PPT、PDF这种典型的工作类型文件”，zhipeng的解释进一步回答了老张为什么打不开设计图纸文件。

不过遗憾的是，找不到敌人。“水坑攻击”+瞄准软件站投毒的“供应链攻击”并非定向对工程师发起的安全攻击，而是一种“广撒网”式的手段，本质上是黑客为了提升入侵成功率和病毒影响面。

想通过找到凶手拿回图纸的路子基本被封死了。

幸运的是文件副本被加密

时间已经过去了24小时，老张和zhipeng想对病毒再做更深入的研究。于是电脑上存着核心资产的硬盘被拆下寄往zhipeng所在地。

除去快递时间，如果zhipeng在12小时内没找到解决办法，赎金价格将超出老张的承受范围，而他收藏的设计图纸可能将永远的被囚禁在数字监狱。

zhipeng和老张的选择是一场赌博，但天平已经有所倾斜：

第一，腾讯安全云鼎实验室这一年中已经发现了多起类似手段的勒索病毒感染事件，其中不乏在业内有成功恢复案例。

第二，老张及时的关机动作，让文件恢复有理论可能——病毒也算是一个程序，需要运行。及时的关机动作，导致病毒可能尚未完全将电脑文件加密。

第三，还是病毒的运行效率——老张的电脑型号陈旧，电脑的操作系统、运行内存等配置相对落后，病毒运行速度有一定程度折损。

猜想得到了验证！

zhipeng拿到硬盘后的分析发现了有未被加密的文件。同时，他还发现了“勒索病毒无法解密”这一死刑宣告的漏洞。

zhipeng根据该勒索加密样本与源文件对比分析，病毒对一个文件的加密并非是百分百字节加密。可能是出于效率和成本的考虑，该病毒的加密机制只对部分字节起作用。用专业的数据恢复工具，就可以将部分数据恢复。

（以单个文件为例，本次事件中的勒索病毒加密机制示意）

但这种方式有局限性。zhipeng说，这种方式对于大文件有效，尤其是文本视频压缩数据文件有很大恢复的可能性。但通过这种方式会丢失文件前150kb的数据，一些小文件是没办法恢复。

但这次的勒索病毒还有第二个加密特点——删除了文件。

如果是标准的勒索病毒加密，它的原理是将受害者电脑中文件直接加密。这一次案例中的加密原理则是，病毒运行后，先对电脑中的文件复制一个副本，对副本进行加密，再将原来的文件删除。

而删除的动作，就给设计图纸恢复留下了一个窗口——磁盘修复——类似于普通用户在电脑使用中删除（包括清空了“垃圾桶”）了本地文件后的数据恢复场景，通过专业的数据恢复工具，有几率恢复成功。

最终，在发现加密机制缺陷后，zhipeng尝试了多种数据恢复工具，恢复了大概六到七成的被加密数据，老张也得以找回大部分的设计图纸文件。

有用的“无用功”

本次事件中，其实还有第三种数据恢复方式，也是完美的数据恢复方式——百分百恢复——解密器恢复。“该家族的勒索病毒有非常多的后缀。这次案件的勒索病毒是其中一种，目前该病毒的密钥未公开暂时不可用，可能未来一段时间会更新。所以最好先做好备份，未来有完全恢复的可能性” ，zhipeng说。

这并非是遥不可及，zhipeng说现在已经有国外安全人员在持续收集这个家族的密钥，并更新勒索解密工具，帮助受害者免受勒索之苦。

这背后不仅是正义与邪恶的较量，更是全球安全从业者面对挑战时的态度，没有绝对安全的系统，也没有绝对无解的威胁。

可能未来很长一段时间，人类仍将处于勒索病毒无解的支配中，但总有人在无解的题上孜孜不倦的求解。

另外，也不要给勒索病毒可乘之机，对于普通用户而言提高警惕能避免绝大多数的勒索病毒，就像最后zhipeng告诉老张的:“不随意打开陌生链接、邮件，不在不正规的网站下载软件”。

但这仍然不够。企业和社会关键基础设施才是勒索病毒肆虐的主战场。

当下一次，一个没有缺陷的勒索病毒利用水坑攻击、侵入供应链等手段悄无声息的潜入了一家企业的员工电脑时，被加密的可能就不仅仅是设计图纸了。

记域名备案被注销后的9个小时

收到通知

7月6日下午收到运维转告公司收到ICP的邮件，告知公司主站已被注销，该站的备案号已被收回。收到通知的那一刻就傻了，这意味这上百个子域名将被停用，紧接着就发现部分网站已经开始出现TestPage 184的提示。

更换域名

第一时间想到的是更换域名，被注销的域名是xxx.com，公司名下还有一个xxx.cn的域名备案正常。于是开始购买 cn 域名的 SSL 证书，先把用户无感知的一些后台服务换成了 *.xxx.cn 的子域名。更换的过程中发现好多代码中硬编码了好多域名进去，于是召集研发排查硬编码的域名并更换。

CNAME 的诱惑

域名换了几个发现进度太慢，距离被注销已经1个小时了，发现原有域名下的 CDN 服务并没有失效，难道是因为阿里云的 DNS 只是屏蔽了主域名，增加一层 CNAME 就绕过去了？怀着侥幸心理，把一个 yyy.xxx.com CNAME 的记录改为了 yyy.xxx.cn 并将 yyy.xxx.cn 的 A 记录改为了源站的IP。结果是竟然可以了，暗自窃喜了10分钟后，访问 yyy.xxx.com 发现网站又是 TestPage 184了。

无奈之举，境外服务器

CNAME 方法失败后开始反思，可选的方案有两种：

1. 更换域名
2. 原有域名解析到境外服务器

两种方案的优劣比较：

方案	优势	劣势
解析境外	配置简单、业务影响小	访问速度慢、非长久之计，后期需要再调整回来
更换域名	风险小、可长久使用	配置繁琐、业务影响大

综合考虑后还是决定解析至境外的服务器，并用Nginx反向代理回境内服务器上。需要做的就是：

• 购买新加坡节点的服务器，安装 Nginx ，配置反向代理。
• 解析原有域名至新加坡服务器的IP。

下面列出一个站点的 Nginx 配置：

server {
    listen 443 ssl;
    server_name libraryplus.api.xxx.com photo.api.xxx.com;
    root html;
    index index.html index.htm;
    ssl_certificate   /etc/nginx/api.xxx.com.pem;
    ssl_certificate_key  /etc/nginx/api.xxx.com.key;
    ssl_session_timeout 5m;
    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    client_max_body_size   1024m;
    location / {
            proxy_pass http://39.107.253.80:80;
            proxy_redirect  off;
             if ( $host ~* (.*).com )
            {
                set $host_my $1;
            }
            proxy_set_header  Host  $host_my.cn;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

其中需要强调的一个地方是 proxy_set_header Host 的配置。因为原有域名是被阿里云的防火墙过滤的，如果不修改回源的 Host 的话，即使 DNS 可以逃脱，内容还是会被拦截的。所以 Host 改为一个已备案的域名就可以了，上面我通过正则批量改成了 .cn ，对应的要在后端的web服务器上做对应的修改，如 IIS 里要在站点的网站绑定里添加对应 cn 域名的主机头。
至此，在7日的凌晨3点把120多个子网站全部配置完成，客户感知的最长宕机时间为9个小时...

恢复操作

9日下午收到ICP的备案通过邮件，告知备案已通过，域名可以在7小时内生效。（正常的审核速度应该是7-14个工作日，后来才得知，注销和再次审核通过都是有背后操作的。）
从境外的撤离操作就简单很多，业务站点几乎不用动，只要把域名的 DNS 重新解析回原来的IP就可以了，web站点绑定的备用域名主机头可以删了，境外服务器也可以释放了。