引子
很久前手里的一个样本，之前因为技术不够一直没有详细分析，最近心血来潮尽我所能详细分析一下。
样本概览
文件名：2017-01-31-EITest-Rig-EK-payload-CryptoShield-rad6BF31.tmp.exe
文件大小：93.5Kb（95,744字节）
文件版本：11,20,2,0
修改时间：2017/2/1 2:03:35
CRC32：e879afbd
MD5：cc882e0f288b8996bfa66cda9a27e137
SHA1：e5686d807ada9e7e953dd2a125fdaf5be958375b
行为分析
运行情况
首先双击运行，等待40s左右(一会的分析就能告诉你为什么它这么慢）弹出勒索文档，大概就告诉你：“你的电脑被我加密啦，我用的RSA-2048”，它还贴心的给你放上了维基百科。总之就是你的重要文档都被强加密，不交钱的话休想复原了（后续我们来解决这件事）：
大概查看一下发现各个文件夹下都产生了这两个勒索文档，同时被加密的文件会以“加密串.CRYPTOSHIELD”格式显示：
同时里面的内容也被加密的无法判断出这是一个什么类型的文件：
具体行为监控
接下来我们查看一下样本都有哪些行为，火绒剑记录的行为很多，这里我只贴一下主要的行为。首先病毒将自身移动到系统文件夹并将自身伪装为SmartScreen软件：
之后创建了注册表自启动项，便于后续持久化攻击：
各处创建勒索文档：
这部分访问了加密相关的注册表值应该是使用CSP加密库进行加密了，同时也能看到文件名被修改了：
接着病毒又删除了备份文件，停止与备份相关的服务防止用户进行数据恢复（这里程序名称不同，因为这是我提取到的子进程，后续会说到）。
逆向分析
接下来我们从静态分析和动态分析上来搞明白这个程序到底是如何运行的，以及尝试看看我们是否有挽救数据的机会。
加载器部分
查看导入表
查看导入表发现几乎找不到与病毒行为相关的函数，这里猜测此程序应该只是一个加载器，实际程序应该是隐藏在程序某个段中，待此程序加载到内存中进行释放并执行真正的病毒：
静态分析
将程序拖入IDA，定位到主函数查看一下主要流程实际上就是先将数据进行解密，解密后再加载至内存运行，专业上讲这叫做：“病毒文件不落地”hhh。实际上也是躲避杀软检测的手法之一：
接下来我们主要分析一下病毒数据是如何解密并加载到内存中的。这里看到实际上病毒数据是存储在了资源段中，程序读取名为“FSKLJDHFUISDOJGOISDHGIOKDSHUGIJSDOI”的资源并加载到0x7E00大小的内存中（实际上这就是病毒文件的大小，为我们后续解密资源提供了帮助），加载后经过分析发现这段数据是被RC4算法加密了，程序先对数据进行RC4解密，之后将病毒进行分段加载到内存中：
RC4算法特征是具有一个256的SBOX，这里就不贴了。我们简单看下它的加载函数。实际上这就是一个简易的PE加载器，先将病毒程序分段加载到内存中，然后依次修复重定位表，导入表：
因为主要内容不在这个程序中，这里我们只粗略地分析了过程，接下来我们手动将病毒程序提取出来。
动态调试提取病毒文件
由于我们在上文看到了程序先将资源文件读入到内存中对数据进行解密后再进行加载的，那实际上我们断点断在解密后的位置就能顺利的提取出病毒数据，下图红框中便是病毒文件：
写一个简单的IDC脚本将内存dump出来即可提取到病毒文件。
病毒主程序
查看导入函数
用到了CryptoAPi相关函数、注册表相关函数、Socket相关函数。确定了这就是勒索软件本体，另外这里还用到了很多次网络连接相关的函数（行为分析没有查看到应该是我断网运行的原因= =），猜测会与C2服务器进行通信：
梳理病毒运行过程
由于病毒涉及到很多流程，为了能分析得更加具有条理性这里我先将病毒大概的运行过程贴一下，方便后续一步一步的分析：
获取电脑第一个盘的序号作为第一个部分，获取用户名并对用户名数组进行简单的异或和移位操作得到第二部分。这两部分共同组成互斥锁ID避免勒索软件重复加密：
接下来程序检测是否存在名为“1FAAXB2.tmp”的文件并且文件内容是否为“AFEE16BC"。第一次运行是不会产生这个文件的，这实际上可以看做一个病毒存档的文件，一旦用户电脑中有这种特征就证明已被感染，所以为了让它闭嘴我们其实也可以手动创建个这个文件【滑稽】:
对于第一次运行的电脑，程序会伪装到系统目录同时创建自启动项便于持久化攻击：
注册表情况，这里多了两个启动项都是病毒文件：
上述几部分准备工作完成后接下来开始尝试对文件进行加密。程序在不同地方多次出现这一部分操作，这其实是程序生成的密钥文件，主要目的是通过检测它是否生成来判断用户是通过哪种方式加密的(单机情况不会生成这个文件）：
开始检测系统网络连通性，程序尝试与C2服务器进行连接：
如果连接成功程序会随机导出一个密钥，接着将密钥进行RC4加密后存入下面这个文件中：
如果存在密钥文件就将密钥文件进行上传，上传的参数有三个分别为：唯一序列号、密钥、用户代{过}{滤}理：
上传完成后到达了这一步。这一步是为了获取密钥明文形式。如果存在密钥文件那就直接读取并进行RC4解密得到key，如果不存在那就对准备好的机器码解密也能得到key：
这一部分就是被RC4加密的Key了：
这里我事先写好一个RC4解密脚本，试着将这部分解密一下得到情况如下：
接下来主体加密部分，程序并没有使用多线程进行加密（这就是之前为什么我等待感染都要等待那么长时间的原因 = =），对三种大小的文件进行加密：
程序循环对每个盘进行感染，这里注意到如果是U盘或者网络介质，程序还会将自己伪装成解密软件储存到介质中，这一步是为了产生大范围感染：
程序列出了一份白名单不感染这些文件夹，这一步为了让系统能够正常运行：
程序会感染的文件的后缀名，这里看一下发现大多都是文档数据类，不至于系统所有东西都运行不了：
这里开始加密，发现程序使用了我们之前分析的Key生成一个Hash，用它作为AES加密的key。到这里我们可以思考一下程序使用的是AES对称加密，如果我们能得到Key文件，至少在用户单机被感染的情况下我们是可以完全解救的：
加密完文件后，这里还会对文件名进行一下简单的加密：
最后这里我们简单梳理一下作者对文件的加密逻辑，在大小符合0~256M这区间的文档，程序将文件进行直接加密，而对于过大的文件选择直接改名不进行加密（无语）：
紧接着程序在每个感染的文件夹内写入两个勒索文档：
程序还会尝试去删除密钥文件防止用户拿到进行解密。这一部分对于网络感染的用户实际上是基本无解的（其实可以尝试一下数据恢复密钥文件）：
这一部分在行为分析部分我们已捕捉到了，程序最后还会删除系统中的所有备份文件，防止用户进行系统恢复：
最后弹出两个勒索文档，提示用户电脑已被绑架：
分析部分到此为止，我们已经将程序全部的行为分析出来了，接下来我们尝试去解决解密的问题。
数据恢复
目前所知的情况如下：
- 程序使用AES对称加密。
- 程序会在单机和联网上产生两种不同的加密方案。
- 单机情况下AES的key以RC4加密的形式储存在程序内。
- 联网情况下AES的key储存在文档内，最后程序会删除。
那么对于联网感染用户来说，我们有两种办法得到key：
- 在生成密钥时进行Debug追踪，在程序删除前即可拿到Key。
- 使用专业的数据恢复手段恢复出Key。
对于第一种方式这就是纯废话，因为用户并不会在得知这是勒索病毒的情况下进行debug运行（皮一下），而第二种办法也希望渺茫。但是对于单机用户情况就完全不同了，因为我们的Key是明晃晃的储存在程序中，我们只要拿到Key就完全可以恢复出数据，为此我写了一个Demo用于测试解密，解密情况如下所示，成功的解密出了文件名和数据：
使用的是Win7自带的视频，测试是正常的，文中用到的各种文件都在附件中：
总结
自认为这一次对文件的分析还是比较全面的。另外吐槽一下分析病毒真是一个花费时间的活，对某个前辈所说的“病毒分析很多时候就是人对抗人”不能再认同了。
[复制链接]
发表于 2021-7-29 18:27
|
发表于 2021-8-19 10:38
发表于 2021-7-30 01:02
发表于 2021-7-30 19:27
，格式搞错好多次，这回应该没问题了
