-
-
[原创]WannaMine2.0 挖矿蠕虫变种研究分析
-
发表于: 2020-2-29 18:44
-
“挖矿”是一种使用他人设备，并在他人不知晓、未允许的情况下，秘密地在受害者的设备上挖掘加密货币的行为。黑客使用“挖矿”手段从受害者的设备中窃取计算资源，以获得复杂加密运算的能力。大多数加密货币，正是通过“挖矿”方式开始进入流通。挖矿实质上是将计算资源转变为加密货币。起初，任何拥有计算机的人都可以挖掘加密货币，但它很快就变成了军备竞赛。如今，大多数挖矿者使用功能强大的专用计算机来全天候地挖掘加密货币。不久，人们开始寻找挖掘加密货币的新方法，挖矿木马应运而生。黑客不用购买昂贵的采矿计算机，仅需要感染常规计算机，就可以窃取他人的资源来牟取自身利益。
负责测试的同事新装了一个 Win7 旗舰版系统，为了进行测试，安装了一个惠普测试工具软件。后续其余部门同事首先就发现自己的火绒终端检测到存在网络攻击，该同事定位 IP 后，发现是一台测试人员使用的 Win7 虚拟机向内网扫描攻击。据描述，这台虚拟机安装完后，只安装过该 loadrunner11 破解+汉化.rar 工程专用软件，至于是不是该破解软件导致的问题，需要后续单独隔离进行排除分析。
经本地分析后，该挖矿蠕虫感染流程，如下。
3 溯源排查
3.1 受害环境
已感染的系统版本，如下。
已感染的系统版本，如下。
3.2 定位矿池
由于已经存在蠕虫传播行为了，于是使用 WireShark 抓取流量看看能不能找到有用的信息。最后发现了一些 IP 地址，对其进行查询，查询 TCP 流发现存在XMRig 痕迹，这是一个开源的挖矿项目，可判断这是一个矿池地址 ip，那么如何找到实际的域名地址呢？
由于已经存在蠕虫传播行为了，于是使用 WireShark 抓取流量看看能不能找到有用的信息。最后发现了一些 IP 地址，对其进行查询，查询 TCP 流发现存在XMRig 痕迹，这是一个开源的挖矿项目，可判断这是一个矿池地址 ip，那么如何找到实际的域名地址呢？
下图为访问矿池时的配置信息，具体内容为：{"id":1,"jsonrpc":"2.0","method":"login","params":{"login":"physics1","pass":"x","agent":"XMRig/2.8.1 (Windows NT 6.1; Win64; x64) libuv/1.23.0msvc/2017","algo":["cn","cn/2","cn/1","cn/0","cn/xtl","cn/msr","cn/xao","cn/rto"]}}
下图为访问矿池时的配置信息，具体内容为：{"id":1,"jsonrpc":"2.0","method":"login","params":{"login":"physics1","pass":"x","agent":"XMRig/2.8.1 (Windows NT 6.1; Win64; x64) libuv/1.23.0msvc/2017","algo":["cn","cn/2","cn/1","cn/0","cn/xtl","cn/msr","cn/xao","cn/rto"]}}
在公开的威胁情报站点查询下，结果有标记恶意的痕迹，例如僵尸网络，这个 IP 可能是一个 C2 地址。
在公开的威胁情报站点查询下，结果有标记恶意的痕迹，例如僵尸网络，这个 IP 可能是一个 C2 地址。
再看另一个 IP，经查询这是一个已经被标记的矿池地址。
再看另一个 IP，经查询这是一个已经被标记的矿池地址。
3.3 恶意文件
找到矿池地址后，可切断来源，避免持续进行挖矿活动。接着就开始对可疑进程进行分析，首先使用 PChunter 查看下是否有可疑的进程，通过数字签名筛选发现存在紫红色的进程被标注了出来，而且该目录看起来不太正常。
找到矿池地址后，可切断来源，避免持续进行挖矿活动。接着就开始对可疑进程进行分析，首先使用 PChunter 查看下是否有可疑的进程，通过数字签名筛选发现存在紫红色的进程被标注了出来，而且该目录看起来不太正常。
在网络连接方面，发现 rundll32.exe 进程对矿池地址进行了连接。
也可使用命令行 netstat -ano 查询下此时的网络连接情况，目的是找到相关的挖矿进程，发现此时进程 ID 是 4756。
在火绒剑中找到恶意进程后，同样发现也是 rundll32.exe。这是一个微软的程序，此处用到的手法为隐藏，实际是通过 rundll32.exe 启动了一个恶意 dll 程序，因为 rundll32.exe 是一个合法的程序。查看进程中存在的TCP/IP 连接，果然存在与矿池的通信。
在火绒剑中找到恶意进程后，同样发现也是 rundll32.exe。这是一个微软的程序，此处用到的手法为隐藏，实际是通过 rundll32.exe 启动了一个恶意 dll 程序，因为 rundll32.exe 是一个合法的程序。查看进程中存在的TCP/IP 连接，果然存在与矿池的通信。
在进程中搜索下字符串看看，也发现确实存在对应的 ip 地址。
看看 rundll32.exe 有啥异常，最后发现主要是恶意的 dll 文件被 rundll32.exe 启动了，导致执行了恶意代码，如下就被火绒剑直接标注了恶意 dll 文件为未知文件，它只是伪装成一个微软的合法 dll 文件而已。
rundll32.exe 的父进程为 svchost.exe（976），而通过查询发现是 wmassrv.dll 这个 dll 启动的进程，启动参数为 C:\Windows\system32\svchost.exe -k netsvcs（后续分析后也会发现）。
最后发现存在内网横向移动的恶意文件为 spoolsv.exe，就是那标注出紫红色的进程，注：spoolsv.exe 是 Print Spooler 的进程，管理所有本地和网络打印队列及控制所有打印工作。如果此服务被停用，本地计算机上的打印将不可用。该进程属 Windows 系统服务，所以此处进行了伪装，如下是该进程产生的 tcp 连接。
最后发现存在内网横向移动的恶意文件为 spoolsv.exe，就是那标注出紫红色的进程，注：spoolsv.exe 是 Print Spooler 的进程，管理所有本地和网络打印队列及控制所有打印工作。如果此服务被停用，本地计算机上的打印将不可用。该进程属 Windows 系统服务，所以此处进行了伪装，如下是该进程产生的 tcp 连接。
3.4 挖矿情况
当时经本地测试访问矿池时还能响应，但实际在感染的机器上已经无法挖矿成功，如下。
当时经本地测试访问矿池时还能响应，但实际在感染的机器上已经无法挖矿成功，如下。
同时也能发现，该 IP 解析了很多域名。这是之前溯源时查找的记录，随着时间的推移，VT 的相关数据也会更新，如下。
3.4 日志分析
目的是想找到感染主机的具体时间，希望能借助相关的日志信息来定位判断。首先列举下应急响应中常见的事件 ID，如下。
目的是想找到感染主机的具体时间，希望能借助相关的日志信息来定位判断。首先列举下应急响应中常见的事件 ID，如下。
由于有创建服务，根据获取到的日志，事件 ID 为 7045。
很快就定位到了具体时间，时间为 2019/12/19 15:37:48，看起来比发现存在感染时还早了一个多月。
具体日志文字内容，如下。
服务已安装在系统中。
服务名称: Windows Modules Activations Services
服务文件名: %SystemRoot%\System32\svchost.exe -k netsvcs
服务类型: 用户模式服务
服务启动类型: 自动启动
服务帐户: LocalSystem
从记录的日志分析目前只能定位到 2019 年 12 月 19 日，系统存在了 WannaMine 挖矿蠕虫，创建了服务。
很快就定位到了具体时间，时间为 2019/12/19 15:37:48，看起来比发现存在感染时还早了一个多月。
具体日志文字内容，如下。
服务已安装在系统中。
服务名称: Windows Modules Activations Services
服务文件名: %SystemRoot%\System32\svchost.exe -k netsvcs
服务类型: 用户模式服务
服务启动类型: 自动启动
服务帐户: LocalSystem
从记录的日志分析目前只能定位到 2019 年 12 月 19 日，系统存在了 WannaMine 挖矿蠕虫，创建了服务。
4 本地复现
spoolsv.exe（较大文件）没有加壳，采用 VS2015 编译。对较大的 spoolsv.exe 文件进行反汇编后，可查找到对 EnrollCertXaml.dll 文件的操作。
spoolsv.exe（较大文件）没有加壳，采用 VS2015 编译。对较大的 spoolsv.exe 文件进行反汇编后，可查找到对 EnrollCertXaml.dll 文件的操作。
时间戳为 2018 年 6 月 26 日与安天分析报告中提及的时间 2018 年 5 月 3 日不同，如下。
EnrollCertXaml.dll 位于以下系统路径，如下，可发现此处对修改时间进行了伪装。
本地进行测试实验，准备两台机器，一台已经被感染，另一台存在 ms17-010 漏洞。需要两个比较重要的样本，第一个是较大的 spoolsv.exe 与位于 System32 文件夹下的 EnrollCertXaml.dll，启动后使用火绒剑观察下进程的各种行为，如下。
捕获网络流量后会发现开始进行漏洞利用，发起攻击。攻击者 192.168.153.136，受害者 192.168.153.129。
在受害者机器 192.168.153.129 利用 ProcessMonitor 进行进程行为监控，发现会接收到攻击者传输过来的文件，正在为之后的蠕虫传播做准备。
传输过来了 EnrollCertXaml.dll，如下。
Microsoft 文件夹的修改日期没有经过伪装，是真实的创建时间，这里也可以作为系统被感染的时间定位，如下。
Microsoft 文件夹下的内容看起来是 NSA 漏洞利用工具包，如下。
同样释放出了 wmassrv.dll 文件，如下。
查询记录发现 wmassrv.dll 这个恶意 dll 文件会被安装为服务（通过操作注册表的方式），如下是监控的记录。
已经设置完成的具体注册表键值，如下，显示的名称会让人以为是一个微软的合法服务。
整体一个攻击与传播感染流程与之前安天分析的差不多，只有个别存在不同，图来源于安天的分析报告，此处为引用。
5 样本分析
5.1 spoolsv.exe（大）分析
对 spoolsv.exe（大）bf98a0555212d2adbb7c020cb39084b6 进行下分析，无壳，64 位 C++程序，如下。
查找时间戳为 2018 年 6 月 26 日，如下。
调试时可去掉 ASLR，如下。
IDA 对其分析后，发现主体功能如下，注释为已经分析过的结论，是一个多线程的 C++编写的程序，无 GUI，与 32 位汇编不同的是，在 x64 下，是寄存器传参。前 4 个参数分别是 rcx、rdx、r8、r9 进行传参，多余的通过栈传参从右向左入栈，如下是整个主程序的大致流程。
5.1.1 x64dbg 调试多线程
针对多线程的调试，之前是使用的是 ollydbg，这次使用 x64dbg 对其调试。那么在 x64dbg 中如何调试多线程？这里就举当前分析的挖矿蠕虫恶意样本（bf98a0555212d2adbb7c020cb39084b6）。首先进入 main 函数位置，如下。
接下来会看到存在连续几个线程的创建，就以调试 thread1（已经在上述的 IDA 中对这些线程进行了重命名）为例。
先在 thread1 线程入口设置断点，如下。
在执行创建 thread2 线程时会进行跳转，如下。
此时来到线程列表窗口，如下。
将主线程挂起，避免影响 thread1 线程调试。
此时回到之前的汇编窗口，如下。
一步步调试，就会切换到 thread1 线程入口。
此时就可以对 thread1 线程进行调试了，针对需要调试其中一些线程的时候，其余线程都可以进行挂起，避免对正在调试的线程造成影响。
现在演示下调试第二个 thread2 线程，如下，先恢复主线程。
在 thread1 线程里进行单步调试， 不一会就立马跳转到了主线程区域。
此时接着查看线程列表窗口，将之前调试的 thread1 线程进行挂起，如下。
在需要调试的 thread2 线程入口下断点，如下。
在主线程进行单步调试，会跳转到线程处理部分，此时再将主线程进行挂起，如下。
接着调试 thread3，此时需要在线程窗口将主线程给恢复，如下。
此时处于 thread2 区域，如下。
将 thread2 线程给挂起，如下。
在主线程区域执行完创建 thread3 线程的函数，如下，此时还无法跳转。
此时来到线程列表窗口，在之前刚调试的 thread2 右键选择【转到线程】，此时回到反汇编窗口，查看是否已经是 thread2 线程区域，这时再在线程列表窗口里将主线程右键选择【挂起线程】，目前就可以继续进入 thread2线程区域调试，目的是为了调用 Sleep 函数，达到线程切换。当在 thread2 里调用 Sleep 函数后，此时就切换到 thread3 线程区域，然后将 thread2 再次进行挂起，如下。
运行之后就会切换到 thread3 线程区域，如下。
成功跳转到 thread3，如下。
重新调试程序，一直单步调试，直到进入到 thread3 区域后将其余线程给挂起，当然如果线程之间有相互的数据共享，挂起其余线程后也影响当前调试的线程，所以调试时还是具体进行决定是否全部挂起线程。
5.1.2 具体动态调试
首先出现的是硬编码的互斥量{F5175396-40C2-0218-278D6EE}，已感染的系统最早的恶意文件为 C:\Windows\System32\EnrollCertXaml.dll 与 spoolsv.exe（498k 大小）。
5.1.2.1 thread1 分析
拼接所需的路径，创建以下目录，C:\\Windows\\SpeechsTracing\\与 C:\\Windows\\SpeechsTracing\\Microsoft\\，之后 spoolsv.exe（498k 大小）进程会从 EnrollCertXaml.dll 提取并释放出 Crypt 文件，该文件为一个压缩文件。之后对其解压释放到 C:\\Windows\\SpeechsTracing\\Microsoft\\目录下，实际查看后发现为 NSA漏洞利用工具。再接着从从EnrollCertXaml.dll分别释放出x86.dll与x64.dll到 C:\\Windows\\SpeechsTracing\\Microsoft\\目录下。
会释放出 Crypt 文件，后续会被进行解压到目录下成为 NSA 工具利用包，最后会删除 Crypt 文件。
会删除 Crypt 文件，如下。
释放出 NSA 工具包后，第一步会先执行永恒之蓝漏洞工具并记录攻击日志，如下。
永恒之蓝利用时用到的相关配置文件 svchost.xml 会从程序的资源文件区域 BIN 进行读取创建，如下。
第一阶段记录的攻击日志，如下。
永恒之蓝漏洞利用成功后，接着会使用双星漏洞进行进行利用并进行日志记录，来注入恶意 dll，如下。
其中利用的双星漏洞的配置文件，如下。
对应的攻击日志，如下。
永恒之蓝的漏洞利用配置文件，如下。
获取到相应的 IP 地址时就会写入刚刚的配置文件内，如下。
开始进行漏洞利用，如下。
整体的一个利用过程，如下。
5.1.2.2 thread2 分析
thread2 每隔 500ms 最终启动 64 个线程，加快扫描速度。
再次创建线程，进行端口的扫描侦查，如下。
尝试连接 445 与 63257 端口，如下。
最终开启的大量线程进行扫描，如下。
5.1.2.3 thread3 分析
thread3 主要是获取本地 IP 地址，并排除本地环回地址。
之后将获取的到 IP 共享给其余线程使用
5.1.2.4 thread4 分析
thread4 由之前两个线程来获取有效的 ip 地址后并采用 TcpTable 进行管理，如下。
开始获取到本地的 IP 范围，准备交由 thread2 进行多线程扫描，如下。
获取到了 445 端口开启的 IP 地址，如下。
之后获取到有效 IP 后就交由 thread1 启动攻击行为
5.1.2.5 thread5 分析
thread5 会存在与 C2 的通信，并进行更新本地恶意软件，不过截止分析时已无法从 C2 获取相应数据。
字符串如何隐藏的？此处汇编层面采用了 SSE 指令，直接进行 16 个字节字符传送拼接，对抗静态分析，这样静态分析时查不到相应的硬编码字符串，这里的话是拼接后会成为一个域名。
采用 strings.exe 才查询到相应的字符串，如下
对 C2（task.attendecr.com）进行访问来获取数据，如下。
5.1.2.6 thread6 分析
thread6 此处暂未发现有使用，如下。
5.1.2.7 thread7 分析
thread7 再次传输本地的扫描与错误信息至 C2 服务器，会访问 scan.attendecr.com:80/status、error.attemdecr.com:8080/log、error.attemdecr.com:8080/error，如下。
同时也会从服务端读取数据至本地，如下。
5.2 x86.dll 分析
主要为后续在受害机器中进行服务安装保持持久化，如下，查看其导出函数。
该 dll 执行后会创建互斥量为{B3DD887C-4738-EBD0-6CD0105}，后续主要为创建服务 svchost.exe -k netsvcs（netsvcs 工作组）作为持久化运行。
5.3 x64.dll 分析
与 x86.dll 实现的功能一致，只是针对是 64 位平台，同样会读取 EnrollCertXaml.dll 并解密释放出 wmassrv.dll，之后将其安装为服务驻留在系统里。
现在首先来看看 HalPluginsServices.dll 是如何出现的，幸好在之前本地模拟攻击流程时导出了相应的进程记录，通过搜索发现了释放 HalPluginsServices.dll 的进程为 svchost.exe，如下。
svchost.exe 之前有被安装为服务，启动的源地址见下图注册表内容，如下。
5.4 wmassrv.dll 分析
所以接下来就来分析下 wmassrv.dll 这个恶意文件，对其反汇编后，如下，出现了 HalPluginsServices.dll 字符串，表示接下来有可能会对其进行操作。
该处会开启 mongoose web 服务，在 63257 端口上来传输给受害机器文件 EnrollCertXaml.dll，如下。
文件传输至受害机器完成后，会获取当前目录的文件的修改时间，对释放的文件的修改时间进行修改，确保与当前目录里文件的修改时间一致，达到伪装的目的。
利用 rundll32.exe 启动恶意 dll 文件，ServicesMain 为恶意 dll 的参数，启动后开启挖矿行为，如下。
5.5 HalPluginsServices.dll 分析
问题来了，分析挖矿程序，主要的是还是找到挖矿地址，现在发现 HalPluginsServices.dll 是一个挖矿程序，那么怎么才能找到这个挖矿的地址呢？最后字符串里发现是 2018 年 10 月 17 日编译的挖矿程序，可以说明，如果不是黑客故意伪装编译时间，该变种从 2018 年 10 月 17 日之后才开始活跃起来，如下。
找到的矿池地址：m -o physic.kinuckle.com:443 -u physics1 -p x -t 1 --donate-level=1 –nicehash
对域名查询下是否有相关的恶意活动，如下。https://x.threatbook.cn/nodev4/domain/physic.kinuckle.com
目前还没有标记，同时也可以看到，域名注册时间与挖矿程序编译时间吻合，这个过期时间还蛮长的……。
6 恶意技术
6.1 程序详细信息
恶意程序伪装成类似微软的相关程序，如下。
6.2 修改时间
获取当前目录的时间戳，修改释放的文件为对应的目录的时间 2009 年 7 月 14 日。
6.3 安装服务
x86.dll（x64.dll）执行后释放 wmassrv.dll 后，使用 C:\Windows\System32\svchost.exe -k netsvcs（netsvcs 工作组）参数来创建服务，服务名称为 Windows Modules Activations Services，看起来像是微软的服务，但请注册，这是恶意程序伪装的。
6.4 疑似合法程序挖矿
利用 rundll32.exe 启动一个恶意 dll 来开启挖矿，这样显示的就是一个合法的微软程序在运行，如果 CPU 使用率不高，不是很容易让人觉察到，这里存在恶意的程序。
6.5 同名文件
恶意文件命名为 spoolsv.exe，但与系统自有文件不在相同目录，因为 spoolsv.exe 是 Print Spooler 的进程，管理所有本地和网络打印队列及控制所有打印工作。如果此服务被停用，本地计算机上的打印将不可用。该进程属 Windows 系统服务，所以此处也进行了伪装。
7 简单溯源
对找到的完整域名进行查询，最终发现了 A 记录为之前 WireShack 抓取流量时遇到的 IP 地址，可以判断之前确实是存在挖矿行为。
本地进行测试实验，准备两台机器，一台已经被感染，另一台存在 ms17-010 漏洞。需要两个比较重要的样本，第一个是较大的 spoolsv.exe 与位于 System32 文件夹下的 EnrollCertXaml.dll，启动后使用火绒剑观察下进程的各种行为，如下。
捕获网络流量后会发现开始进行漏洞利用，发起攻击。攻击者 192.168.153.136，受害者 192.168.153.129。
在受害者机器 192.168.153.129 利用 ProcessMonitor 进行进程行为监控，发现会接收到攻击者传输过来的文件，正在为之后的蠕虫传播做准备。
传输过来了 EnrollCertXaml.dll，如下。
Microsoft 文件夹的修改日期没有经过伪装，是真实的创建时间，这里也可以作为系统被感染的时间定位，如下。
Microsoft 文件夹下的内容看起来是 NSA 漏洞利用工具包，如下。
同样释放出了 wmassrv.dll 文件，如下。
查询记录发现 wmassrv.dll 这个恶意 dll 文件会被安装为服务（通过操作注册表的方式），如下是监控的记录。
已经设置完成的具体注册表键值，如下，显示的名称会让人以为是一个微软的合法服务。
整体一个攻击与传播感染流程与之前安天分析的差不多，只有个别存在不同，图来源于安天的分析报告，此处为引用。
5 样本分析
5.1 spoolsv.exe（大）分析
对 spoolsv.exe（大）bf98a0555212d2adbb7c020cb39084b6 进行下分析，无壳，64 位 C++程序，如下。
对 spoolsv.exe（大）bf98a0555212d2adbb7c020cb39084b6 进行下分析，无壳，64 位 C++程序，如下。
查找时间戳为 2018 年 6 月 26 日，如下。
调试时可去掉 ASLR，如下。
IDA 对其分析后，发现主体功能如下，注释为已经分析过的结论，是一个多线程的 C++编写的程序，无 GUI，与 32 位汇编不同的是，在 x64 下，是寄存器传参。前 4 个参数分别是 rcx、rdx、r8、r9 进行传参，多余的通过栈传参从右向左入栈，如下是整个主程序的大致流程。
IDA 对其分析后，发现主体功能如下，注释为已经分析过的结论，是一个多线程的 C++编写的程序，无 GUI，与 32 位汇编不同的是，在 x64 下，是寄存器传参。前 4 个参数分别是 rcx、rdx、r8、r9 进行传参，多余的通过栈传参从右向左入栈，如下是整个主程序的大致流程。
5.1.1 x64dbg 调试多线程
针对多线程的调试，之前是使用的是 ollydbg，这次使用 x64dbg 对其调试。那么在 x64dbg 中如何调试多线程？这里就举当前分析的挖矿蠕虫恶意样本（bf98a0555212d2adbb7c020cb39084b6）。首先进入 main 函数位置，如下。
针对多线程的调试，之前是使用的是 ollydbg，这次使用 x64dbg 对其调试。那么在 x64dbg 中如何调试多线程？这里就举当前分析的挖矿蠕虫恶意样本（bf98a0555212d2adbb7c020cb39084b6）。首先进入 main 函数位置，如下。
接下来会看到存在连续几个线程的创建，就以调试 thread1（已经在上述的 IDA 中对这些线程进行了重命名）为例。
先在 thread1 线程入口设置断点，如下。
在执行创建 thread2 线程时会进行跳转，如下。
此时来到线程列表窗口，如下。
将主线程挂起，避免影响 thread1 线程调试。
此时回到之前的汇编窗口，如下。
一步步调试，就会切换到 thread1 线程入口。
此时就可以对 thread1 线程进行调试了，针对需要调试其中一些线程的时候，其余线程都可以进行挂起，避免对正在调试的线程造成影响。
现在演示下调试第二个 thread2 线程，如下，先恢复主线程。
在 thread1 线程里进行单步调试， 不一会就立马跳转到了主线程区域。
此时接着查看线程列表窗口，将之前调试的 thread1 线程进行挂起，如下。
在需要调试的 thread2 线程入口下断点，如下。
在主线程进行单步调试，会跳转到线程处理部分，此时再将主线程进行挂起，如下。
接着调试 thread3，此时需要在线程窗口将主线程给恢复，如下。
此时处于 thread2 区域，如下。
将 thread2 线程给挂起，如下。
在主线程区域执行完创建 thread3 线程的函数，如下，此时还无法跳转。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
最后于 2020-2-29 18:45
被jishuzhain编辑
，原因：
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
