一直在国外流行的勒索软件在前几天“不远万里来到了中国”。当然它并不是来救死扶伤的而是将你的文件加密，然后要求你访问指定的服务器并支付一定比特币来解密它们。虽然从分析结果看也许作者并没有针对中国，但还是不少人“中枪了”。这类软件主要是通过邮件进行传播，通常伪装成订单之类的邮件来欺骗受害者运行。

FreeBuf科普：CTB-Locker敲诈者

昨天开始，国内有众多网友反馈中了CTB-Locker敲诈者病毒, 电脑里的文档、图片等重要资料被该病毒加密，同时提示受害者在96小时内支付8比特币（约1万元人民币）赎金，否则文件将永久无法打开。这是CTB-Locker敲诈者病毒首次现身中国，受害者大多是企业高管等商务人士。点我查看更多

核心原理详解

360对最近发现的勒索软件CTB-Locker做了分析，算得上很详细，但是有几个问题还不够详细。

比如样本使用了AES加密，那么KEY是怎么生成的? 加密后的文件是什么结构？有没有标志？为什么样本在离线的时候能够解密5个文件？我们带着这些疑问做了深入的分析。本文中我们将分享一下我们分析的结果，如有不正确还请各位大牛指正。

首先我们要说的是Downloader下载下来的CTB-Locker首先会在%All Users\Application Data%目录下释放随机名的文件，该文件是加密的。这个文件相当于一个配置文件。后面提到的主公钥(master key)以及加密后的磁盘路径，加密的文件个数等都会保留在这个文件中。

这个配置文件很重要。接下来才是将自身复制到临时目录，然后添加计划任务运行自拷贝的文件，接着注入到svchost进程中。在svchost进程中完成对磁盘上的文件加密。下面我们就针对前面提到的几个疑问做出分析。

1. AES的KEY是如何生成的?

在360的报告中提到是“根据计算机启动时间,文件创建，修改，访问时间等信息为随机种子生成KEY”,同时报告中还给出了截图。但是事实上截图没有给全,还要经过一个过程才能计算出来。实际上它是使用了Elliptic curve Diffie-Hellman(ECDH)算法生成了AES加密的KEY。我们也对此结论做了验证。大致流程可以描述如下(详细可参考卡巴的分析[1]):

(1) CTB-Locker的作者首先生成一个公私钥对。公钥保存在前面说的释放出来的配置文件中，私钥保存在服务器上. 这里我们把这个公钥称为master public key,私钥称为master private key。(2)  在对每一个文件加密的时候会产生一个会话公私钥对，当然使用的是ECDH算法。私钥生成的算法是对文件的时间，系统运行时间等计算SHA256,这里我们称为session private key。然后使用ECDH算法生成公钥即session public key.之所以称为会话公私钥是因为每一个文件的公私钥对都是和文件自身时间以及系统运行时间有关的。(3)  根据ECDH算法,我们知道 sessionshared secret=ECDH(masterpublic key, session private key)=ECDH(session public key,master private key). 在计算的时候要使用会话私钥和主公钥计算出sessionshared secret，然后对session shared secret计算sha256作为AES的密钥。虽然我们可以获取到主公钥但是会话私钥是不保存的，唯一的解密方法是通过主私钥和会话公钥计算出session shared secret。会话公钥是保存在加密的文件里的。

计算出会话公钥的代码如下:

其中var_104是一个长度为0×20的缓冲区，第一个字节为9其余的字节为0。这个值就相当于ECDH算法中爱丽丝与鲍伯协定使用的g值。

接着就是使用会话私钥和主公钥计算出来sessionshared secret，然后对其计算sha256并将其作为AES加密的KEY。需要强调的是这里面会话私钥是不保存的。相关代码如下:

图中的najzljf_data就是解密出来的配置文件的内容。

一句话总结:要想解密文件只能通过主私钥和保存在文件中的会话公钥计算出来session shared secret,再计算一下sha256才能得到AES的KEY。除此外别无他法。

解密的过程是在释放到临时目录中的进程来完成的,相关代码如下:

2. 加密文件的结构是什么？

原始文件经过ZLIB压缩和AES加密后，写在了一个临时文件的x030开始的位置。最后再向临时文件头部写入0×30长度的数据，其中前0×20是会话公钥，接下来是的四个DWORD分别是标志“CTB1”,压缩后的大小，压缩前的的大小，标志(值为1). 会话公钥是明文不加密的，但是针对“CTB1”及后面的长度为0×10数据进行加密。在对该段长度为0×10的数据解密后首先判断开头是否是“CTB1”接着判断尾部是不是1，两者同时匹配才会认为是CTB-Locker加密过的文件。

3. 为什么样本在离线的时候仍然能够解密5个文件?

在系统中文件被加密后，如果我们选择对话框中的“NEXT”,CTB-Locker会让我们搜索一些文件来测试能否解密.如下图:

如果我们选择解密文件，文件是可以解密成功的。这让我们产生一个错觉:密钥是不是在本地保存了? 其实可以说是保存了但是只是保存了5个.保存的是AES的KEY并且是保存在开始提到的配置文件中。首先在为每一个文件产生AES KEY时都会将这个AES的KEY返回给调用者:

调用者会判断当前保存的KEY是否超过了5个,如果超过了5个就不再保存了。代码如下:

当你选择解密5个文件时，CTB-Locker会遍历所有的已加密文件尝试着使用这5个KEY来解密文件偏移0×20处的数据.如果和标志相匹配就说明KEY匹配上了。然后就把这5个可以解密的文件名字输出到屏幕上。相关代码如下:

因此离线解密5个文件并不足为奇，有种你保存所有的密钥啊…

4. 要求受害者向服务器提交的public key和文件加密有关系吗？

最开始我们猜测这个publickey是不是和文件加密有关系或者它会携带一些能够帮助解密的信息。经过分析几乎没有。这个public key 是在所有文件被加密完成后产生的，它主要包含了配置文件中的一些数据以及所有加密文件的总的大小.某种程度上算是类似一个序列号的东西.

5. 可以借助数据恢复工具恢复吗?

我们使用了两款恢复软件来试验但都没有成功。我们发现样本还会调用vssadmin删除掉所有的卷影副本。因此数据恢复的希望非常渺小。