ccleaner后门完全分析报告

2017年9月18日，piriform[1]和思科Talos团队[2]发布公告称piriform旗下产品CCleaner v5.33.6162和CCleaner Cloud v1.07.3191的32bit版本被植入后门。本文为该事件发生一个月以来我做的一个简单的回顾，包括搜集的各方信息汇总和个人的分析。

Stage1

在编译器增加的初始化代码中的__scrt_get_dyn_tls_init_callback函数中增加了解密shellcode的调用。(应该需要有符号信息才知道是这个函数)


根据360天眼实验室的分析[6]，这极有可能是定向性的编译环境污染供应链攻击。如果要向程序CRT代码中植入恶意代码，最好的方式就是攻击编译过程中引入的CRT静态链接库文件，方法有如下三种。

1. 修改CRT库文件源码，重新编译并替换编译环境中的CRT静态库文件(LIB)
2. 修改CRT库文件中某个OBJ文件对应的C源码，重新编译并替换LIB中对应的OBJ文件
3. 修改CRT库文件中某个OBJ文件的二进制代码，并替换LIB中对应的OBJ文件

修改OBJ文件不同于修改源码，此方法理论上可用于注入任何静态链接库LIB。只需按照OBJ文件格式规范即可注入任意代码，比如在OBJ中新增/扩大节，填充shellcode并跳转执行。此攻击方法可以在用户代码执行前(CRT)、执行中(调用库函数)、甚至执行结束后执行植入的恶意代码，并且由于恶意代码并不存在于编写的源代码中，所以很难被开发人员发现。攻击者完全可以植入某个深层次调用的开发环境下的静态库文件，以达到感染大部分开发程序并持久化隐藏的目的。使用源代码安全审查的方式无法发现这类攻击。
解密出来的shellcode是一个loader，会加载一个被抹去了DOS头的dll创建线程执行恶意行为。这里还要提一句，把DOS头添加之后IDA就能正确识别windows函数了。

首先获取当前时间，然后通过sleep或者ping 224.0.0.0来延迟601秒。

再获取当前时间，如果经过的时间大于600秒且大于存储在SOFTWARE\Piriform\Agomo\TCID中的时间并且当前用户具有管理员权限才会继续运行。

接下来启用SeDebugPrivilege权限。

读取SOFTWARE\Piriform\Agomo\MUID中的InstallID，如果此值不存在则为rand()^rand()^GetTickCount()。

将InstallID，IsWow64Process收集的是否是64位信息，GetComputerName收集的计算机名信息，SOFTWARE\Microsoft\Windows\CurrentVersion\uninstall中的软件安装列表信息，GetAdaptersInfo收集的IP等信息，EnumerateProcesses收集的进程列表信息等加密。

获取CC地址216.126.225.148。


伪造host speccy.piriform.com发送加密信息。

如果没有接收到响应，还会尝试连接DGA域名，并将IP地址存储在SOFTWARE\Piriform\Agomo\NID中。DGA算法如下[5]。

#include "stdafx.h"
#include 
#include 
void main()
{
SYSTEMTIME st;
DWORD r1, r2, r3, seed;
char buf[100];
const char *format = "ab%x%x.com";
GetLocalTime(&st);
seed = st.wYear * 10000 + st.wMonth;
srand(seed);
r1 = rand();
r2 = rand();
r3 = rand() * r2;
sprintf_s(buf, format, r3, r1);
}

DGA域名列表如下。
2017年01月 abde911dcc16.com
2017年02月 ab6d54340c1a.com
2017年03月 aba9a949bc1d.com
2017年04月 ab2da3d400c20.com
2017年05月 ab3520430c23.com
2017年06月 ab1c403220c27.com
2017年07月 ab1abad1d0c2a.com
2017年08月 ab8cee60c2d.com
2017年09月 ab1145b758c30.com
2017年10月 ab890e964c34.com
2017年11月 ab3d685a0c37.com
2017年12月 ab70a139cc3a.com
2018年01月 abde911dcc16.com
2018年02月 ab99c24c0ba9.com
2018年03月 ab2e1b782bad.com
随后将当前时间+2天存储到SOFTWARE\Piriform\Agomo\TID中，分配内存，解密并运行CC服务器发送的payload，之后释放内存，将当前时间+7天存储到SOFTWARE\Piriform\Agomo\TID中。

根据卡巴斯基的说法[7]，它们发现加解密传输数据所使用的变形的base64算法和china的黑客组织Axiom使用的代码几乎相同。随后思科Talos团队证实了这一说法[3]。

Stage2

在分析时CC服务器已经失效无法取得Stage2的payload，根据思科Talos团队[3]博客中公布的IOC可以从virustotal上下载对应的文件。Stage2的payload首先检查64位还是32位，据其执行不一样的流程。

根据之前Stage1的payload获得的操作系统版本和操作系统是32位或64位解密出一个dll。
64位XP：\spool\prtprocs\x64\localspl.dll
32位XP：\spool\prtprocs\w32x86\localspl.dll
Vista及以上：TSMSISrv.dll。

将dll最后修改的时间改成系统中msvcrt.dll最后修改的时间掩人耳目。


在注册表中写入shellcode。路径为
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WbemPerf\001
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WbemPerf\002
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WbemPerf\003
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WbemPerf\004。


随后创建并启动服务加载shellcode。XP系统下服务名称为Spooler，vista及以上系统下服务名称为SessionEnv。

XP系统中释放的dll名字是localspl.dll，它的原始文件名其实是VirtCDRDrv.dll，版本是2.0.4.23。该文件原本应该是winzip中的一个dll。在win7 x86中安装了该软件，这两个dll的对比如下所示。

恶意dll跟原dll相比修改了__DllMainCRTStartup函数，把原本正常的call修改成了解密shellcode的call。

可以看到正常dll的0x1001C22E到1001C400之间并没有内容，恶意dll增加的shellcode就在这里。


Vista及以上系统中释放的dll名字是TSMSISrv.dll，它的原始文件名其实是EFACli64.dll，版本是2.2.0.65。该文件原本应该是symantec中的一个dll。symantec安装下载不太方便，这里就不对比了。

恶意dll跟原dll相比修改了__security_init_cookie函数，把最后一条指令修改成了跳转到解密shellcode的jmp。

但是在IDA的Graph view中并没有显示出来。

因为IDA可能是根据pdata来确定运行时函数的开始和结束的。

修改了函数的结束地址之后IDA可以正确显示出最后一条指令。

通过思科Talos团队提供的脚本(https://github.com/Cisco-Talos/pdata_check)可以检测出异常的最后一条指令[4]。

因为这两个恶意dll都没有数字签名，所以合法程序被植入恶意代码的可能性应该不大，攻击者是直接修改的二进制文件。接下来的分析基于localspl.dll。经过VirtualAlloc之后释放loader code，解密出注册表键名，依次获取前面提到的四个注册表项中的内容。


loader code解密出真正的恶意代码，创建线程开始执行恶意行为。

尝试连接https://www.microsoft.com/和http://update.microsoft.com/，检查返回的响应中是否含有Microsoft或Internet Explorer。

随后尝试连接https://github.com/search?q=joinlur&type=Users&utf8=%E2%9C%93或https://en.search.wordpress.com/?src=organic&q=keepost，解密出这两个URL的算法如下。

在这两个网站上包含了解密出CC的信息。


ptoken中的值0x6B48622B和0x31415926异或得到CC地址13.59.9.90。

随后收集一些系统信息并加密，通过dns伪装发向ds.download.windowsupdate.com连接CC服务器，进一步接收服务器下发的内容。



之后的payload思科Talos团队[3]只提到会连接get.adoble.com，并没有给出具体的行为和IOC，分析到这里也就只能先暂时告一段落了。

参考链接

1.Security Notification for CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 for 32-bit Windows users
2.CCleanup: A Vast Number of Machines at Risk
3.CCleaner Command and Control Causes Concern
4.Disassembler and Runtime Analysis
5.Protecting the Software Supply Chain: Deep Insights into the CCleaner Backdoor
6.深入分析CCleaner后门代码-编译环境污染供应链攻击案例
7.https://twitter.com/craiu/status/910059453948579840