Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

“双枪”木马的基础设施更新及相应传播方式的分析

0
0

“双枪”木马的基础设施更新及相应传播方式的分析
1. 引述

2018.12.23 日,我们的 DNSMon 系统监测到以下三个异常的域名,经过研判这些域名属于双枪木马的网络基础设施。考虑到这些域名仅在最近才注册并启用,我们认为双枪木马近期在更新其基础设施,建议安全社区加以关注。

white[.]gogo23424.com
www[.]src135.com
www[.]x15222.com

双枪木马是目前我们见过的最复杂的恶意程序之一,最早由 360 安全卫士团队披露,并对其木马工作原理做了详细的技术分析。双枪木马本身集 Rootkit 和 Bootkit(同时感染 MBR 和 VBR)于一身,还有诸多对抗措施。除此之外,双枪木马恶意活动相关的网络基础设施十分庞杂,感染路径繁琐、传播手段多样,涉及的黑灰产业务种类也五花八门。

之前对双枪木马的公开披露内容主要涉及双枪木马本身的工作原理、涉及的黑灰产业以及部分溯源。对其传播过程的技术细节少有涉及。在双枪木马多种多样的传播方式中,按照我们的统计,与本次更新相关的这种传播方式是感染范围比较大的,并且之前未见披露。本文将着重分析本次双枪木马更新其网络基础设施的情况,以及相应的木马传播技术细节。

1.1 域名 通过分析上述 3 个域名的 IP 解析情况,我们发现white[.]gogo23424.com与以前用来传播双枪木马的恶意域名white.shougouji.top之间存在直接关联:
“双枪”木马的基础设施更新及相应传播方式的分析

根据我们的 PassiveDNS 数据,可以看出这 3 个异常域名的解析时间分别如下:


“双枪”木马的基础设施更新及相应传播方式的分析

对应的注册时间信息分别如下表所示:


“双枪”木马的基础设施更新及相应传播方式的分析
值得注意这些域名的注册和解析时间都发生在近期,例如www[.]src135.com和www[.]x15222.com;而white[.]gogo23424.com虽然注册信息早在今年 5 月底,但是实际提供域名解析也是发生在近期。 1.2 样本

近期这些域名上的恶意代码,正在被大量下载。这些恶意代码的URL和 md5sum 如下:

hxxp://www.src135.com:802/update.txt
- MD5: 94191b6c57b185289b2eb83108d076e4
hxxp://www.x15222.com:8002/update.txt
- MD5: 3f5473826dcef015dc06b83767744ea0

虽然下载上述两个 URL 看似得到两个后缀为.txt的文件,但其实这是两个不同的 JPG 图片,并且在不同的文件偏移处嵌入了 PE 文件。这两个PE文件,经过分析认定,实际为两个功能相近的 DLL 文件:

有相同的导出函数update(); 有类似的执行流程,并且会向发出部分相同的网络请求。

执行两个 DLL 文件,从抓包中可以观察到它们的网络行为序列分别如下:


“双枪”木马的基础设施更新及相应传播方式的分析
“双枪”木马的基础设施更新及相应传播方式的分析

可以看出:

两个 DLL 文件执行的过程中都会先请求访问域名white.xxx.xxx; 然后再向百度贴吧图片服务器请求两个图片 ; 最后再向white.xxx.xxx发出一个 POST 请求。 1.3 上述新的恶意域名可以确认属于双枪木马的网络基础结构

根据我们以前对双枪木马部分传播流程的分析,我们认定这是双枪木马典型传播流程中的一个环节,这是因为新域名的网络行为与双枪木马有以下关联或者类似点:

域名解析有直接关联:如前所述,IP125.77.29.26上同时提供了新旧恶意域名的解析 white[.]gogo23424.com与white.shougouji.top子域名相同,都是white; 两个域名上的下载URL中的URI部分,也遵循了类似的命名规则(stat1.ashx / stat2.ashx / stat4.ashx); 都将恶意 PE 文件嵌入到图片文件中; 都滥用了百度贴吧图片服务器承载恶意代码。 结合我们对双枪木马该传播途径的分析,可以推断双枪木马背后的团伙在更新他们的网络基础设施。并且可以猜测white[.]gogo23424.com可能会部分替代以前的 C2 Domainwhite.shougouji.top,用来承载双枪木马传播过程中的云端配置文件以及木马状态统计服务。这一点值得安全社区关注。

下分详细分析双枪木马本次更新相关的传播流程。

2.双枪木马传播流程 2.1 概述 2018 年 9 月初,我们的 DNSMon 系统监测到*.dztworld[.]com/*.minding99[.]com/white.shougouji.top等异常域名。通过关联分析,我们定位到了异常域名背后的一批样本,对其中的典型样本(比如 MD5:cfe79da256441e45195d6f47049cb2a8)进行深入分析发现,这是一波主要用来传播双枪木马的恶意活动。整个恶意传播活动的典型特征有以下几个: 多阶段样本执行,至少 4 个阶段的样本活动才最终下载到双枪木马的恶意驱动文件; 利用公共网络服务(比如百度贴吧图片服务器)承载云端配置文件和恶意样本; 对抗手段多样,检测运行环境上报云端、对抗杀软难以检测、变形 DES 加密算法对抗分析等等; 盗用数字签名; 涉及业务种类繁杂,除了传播双枪木马的恶意驱动程序,还传播游戏私服驱动,还会盗窃 Steam 账号、劫持 QQ 进行恶意推广。 2.2 母体样本

后文以 MD5 为cfe79da256441e45195d6f47049cb2a8的母体样本为例进行分析。母体样本会访问下面 4 个 URL,下载下一阶段要运行的恶意程序:

hxxp://69.30.193.66/aa.exe md5=d5f6d28be828225cc429589ec6fa2409
hxxp://69.30.193.66/cj.exe md5=e86a9f5819582493837850a25c28915e
hxxp://222.186.138.30:8080/tgp.exe md5=e88b1d3c9bfb95d02e8dcd9931cfe99e
hxxp://69.30.193.66/15.exe md5=99d94b61a04a19e74bb5b84c1e75e451

整体结构如下所示:


“双枪”木马的基础设施更新及相应传播方式的分析

关于 cj.exe 的Steam 盗号功能,友商的分析报告 火绒安全警报:疑似方正集团子公司签名泄露 遭黑客利用盗取Steam账号 已经分析的比较清楚。从样本的 PDB 文件路径来看,该恶意程序的功能也可窥见一斑:


“双枪”木马的基础设施更新及相应传播方式的分析

关于 aa.exe / tgp.exe 的劫持 QQ 进行恶意推广功能,友商也有分析。木马会访问类似以下的接口来获取推广信息,然后呈现在受害机器上:


“双枪”木马的基础设施更新及相应传播方式的分析

据我们统计分析,该团伙中类似的恶意活动中用到的类似接口,至少曾经包括以下几个:

hxxp://42.51.44.167/api/api
hxxp://42.51.44.215/api/api
hxxp://42.51.32.166/api/api
hxxp://42.51.42.106/api/api
hxxp://42.51.44.168/api/api
hxxp://42.51.39.60/api/api
hxxp://42.51.39.208/api/api
hxxp://42.51.33.3/api/api
hxxp://42.51.32.20/api/api

服务端接口返回来的 JSON 数据中的图片 URL,打开之后如下(网赚推广):


“双枪”木马的基础设施更新及相应传播方式的分析

我们的重点在最后传播双枪木马的15.exe。

2.3 双枪传播第一阶段――15.exe

15.exe其实是一个下载器,它会下载百度贴吧图片服务器上的被嵌入了恶意代码的图片文件,从图片文件中解析出恶意 PE 文件并执行。15.exe的主要流程如下:


“双枪”木马的基础设施更新及相应传播方式的分析

流程说明:

解析得到C2 URL(后文简称C2_stat4):密文字串tjXWjFcYZBxxsY0CE2nZUpjLsVUtkFA7BNQ7UxV017ELdPXvPvQM00tSnlsDVtSA经过 Base64+变形 DES 解密出 C2 URLhxxp://white.shougouji.top:8889/stat4.ashx,DES Key 为giwdyaiw; 将字串B6qXVH6POR3lH+CzEzpNX9nIpUQc29lbeeaCHg18AcE=经过同上的解密过程,解出字串Chinesestyleinternetmanhunt; 将步骤2中得到的Chinesestyleinternetmanhunt经过变形的 DES 加密后,作为 POST Data 发送到C2_stat4,DES Key 为HQDCKEY1; 用变形 DES 来解密从C2_stat4获取到的 HTTP 响应数据,得到如下示例字符串,内含两个可以进一步下载的URL。本步骤中可能会返回不同的数据,故解出不同的字符串,用到DES Key 是HQDCKEY1:
hxxp://imgsrc.baidu.com/tieba/pic/item/d788d43f8794a4c227adb80603f41bd5ad6e3914.jpg|hxxp://imgsrc.baidu.com/tieba/pic/item/a08b87d6277f9e2fa7e042251230e924b999f3c2.jpg 访问步骤4中解密出来的两个图片 URL,从两个图片文件的偏移0x1E30处开始到文件末尾各自切出数据,再拼凑在一起,最后再用变形 DES 解密出一个 DLL 文件(后文简称此文件为ReportDLL,此次解密用到的 DES Key 为HQXCKEY7; 起 3 个同样的线程,执行如下工作:在内存中解析这个ReportDLL文件,找到导出函数Report()的地址,导入 DLL 文件需要的 Import Functions,然后执行函数DLL::Report()。

补充说明:

步骤1/2中用到的 DES Key,也是经过解密得到的: 用 Base64 解码字串vGbZFzOaw4A=得到0xBC66D917339AC380; 然后用变形 DES 解密上述二进制数据,才得到giwdyaiw,此处用到的 DES Key 为样本中硬编码的0x0000310000004959 木马用Crypt32.dll::CryptBinaryToStringA()函数来实现 Base64 解密,但Crypt32.dll和CryptBinaryToStringA两个字串并不是硬编码在样本中,而是由IYIJIFINIKGAFAGCIFIOIO和DDDSECDVDSCTDSDZEUEQEJCPEQDHEJEOEQEDDSDN两个字符串用另外的解密算法分别解密得出,然后再用LoadLibrary()和GetProcAddress()函数得到CryptBinaryToStringA的函数地址,最终才会调用函数进行 Base64 解密。 所谓变形 DES,指的是木马作者修改了 DES 加解密用到的初始化向量中的部分字节顺序,导致按照已有的标准 DES 加解密库/程序不能直接解密,必须按照样本中的初始化向量来运算 DES 算法才可以顺利加解密。后文会详细解析该算法。 步骤3/4和步骤5中用到的 DES Key(HQDCKEY1/HQXCKEY7),也不是硬编码在样本中的,而是分别对1ZGNGIWO和7ZGNG]WO利用另外的解密算法解密得出的。 通过这一阶段的分析,据我们的初步推测,从我们最新监测到的 2 个异常域名www[.]src135.com和www[.]x15222.com下载到的两个update.txt文件,其中嵌入的 DLL 文件,功能应该跟15.exe类似。 2.4 双枪传播第二阶段――ReportDLL

第一阶段中通过多重解密得到的 ReportDLL,是第二阶段的主要样本,其主要工作流程包括:

Step 1 监测本地环境、对抗杀软:样本会收集系统信息,包括CPUid/磁盘信息/guid/hostname/MAC地址/进程列表/UAC 级别等信息,样本会检查当前磁盘是否为虚拟磁盘、进程/服务中是否有反病毒软件。样本会将收集好的系统信息整理成JSON文件,然后用变形 DES 加密(DES Key 为HQDCKEY1),示例配置如下:

{
"cpuid": "2",
"disks": "San HARDDISK ATA Device",
"dllver": 20170428,
"exever": 20170807,
"guid": "{4F0C293C-C8D5-4bb2-9249-3E4057E5268B}",
"hddsn": "Sane024ebad-d59c3157",
"hostname": "HanFang-PC",
"iswin64": 0,
"macs": "A0-48-1C-9D-63-F2",
"osver": 61,
"parent": "15.exe",
"process": "[System Process]|System|smss.exe|csrss.exe|wininit.exe|winlogon.exe|services.exe|lsass.exe|lsm.exe|svchost.exe|QQ.exe|spoolsv.exe|FoxitProtect.exe|taskhost.exe|dwm.exe|explorer.exe|SearchIndexer.exe|sppsvc.exe|SogouCloud.exe|notepad.exe|calc.exe|15.exe|conhost.exe",
"sd": 0,
"srvstat": false,
"startby": 702,
"uac": 0
}

样本在这一步检查的磁盘列表如下:

Richdisk
VXPDISK
Diskless 2000/XP
MZD
NMenu
Virtual Disk
[VSCSICLN]
CGM
vDisk
ZHDisk
VxpDisk
iCafe8 SSD
Icafe8 LTA

检查的进程/服务/驱动列表如下:


Viewing all articles
Browse latest Browse all 12749