此文发表于《电子数据取证与网络犯罪调查》（第五辑），一度在硬盘里遍寻不见，幸好张老师有留存。年纪是大了，记性差许多，还是觉得放在这里有个保障。今天是“人民警察节”，就以这种方式纪念下。

感慨：在分析木马程序时，我会关心两个问题，一是分析的最终目标是什么？应该是上线控制端；二是我经历了什么？就是在不断抽丝拔茧过程中努力达成目标。当回头总结时，才发觉作者平淡无奇之下隐藏着一颗玲珑剔透的心(编程手法和技巧)，蕴含着他的思想和造诣，这也是木马能不断突破防线的原因。

曾以为，只是一次例行的勘验，但恰如那句广告词，简约而不简单。最终我收获了启迪，打破了思维定式：①抓包分析中，始终抓不到上线地址，一度怀疑人生。后来才发觉：木马在其体内设置了延时（14544秒=4小时）处理，对木马程序我们根本不会抓包持续这么长时间；同时它对我们的使用习惯很了解：当长时间抓包时喜欢用轻量型的minisniffer（我就是），但程序中恰恰对这款抓包工具进行特别限制，两方面决定了我们抓取不到上线地址。②程序分析中，我忽略漏掉了sleep(时长)函数，编程中我们常使用sleep来缓冲延时，但仅仅是几秒，没想到木马是4个小时，大跌眼镜。③最后，作者用DeviceIoControl直接发送控制代码来执行相应的操作，这种情况在CS木马中较少见。因为这种方式常见于rootkit木马，多见于驱动程序中。 但在深入调试跟踪线程的过程中对IOCTL_CODE值的含义没查到文档对其具体动作不详，留下遗憾。

下面言归正传，开始分析过程。

一、现场情况

内网服务器一台192.168.100.249，Windows server 2008，内网主机十几台，监控设备若干。

二、勘验过程

1、抓包：只发现访问网站的行为，未发现有攻击行为。 

图1

2、可疑程序分析

到现场后，发现业主用360扫了一堆可疑文件，其中就包括了这个系统目录中的system.exe文件。以下我们围绕这个来展开。

1）system.exe分析

当System.exe运行后，会释放两个dll文件，这里为：ugmkn.dll和uvsln.dll（两个dll名字每次生成都不同），放置在c:\windows\syswow64目录下（图2）。 

图2

发现系通过 rundll32.exe来加载运行dll（图3、图4）， 

图3 

图4

System.exe将自身加入注册表启动项，位于c:\windows\system32下（图5）

图5

System.exe每启动一次都会产生两个不同名的dll文件（图6），但互斥体(图15)保证它不会重复运行，

图6

这里出现一个问题（图7），rundll32加载的dll的路径指向system32，而实际dll文件又在syswow64下，导致该rundll32找不到该dll文件。但实际上又能运行，不影响它的加载，有点奇怪。这里涉及到system32和syswow64的区别，在64位系统中system32目录下放置的是64位程序，而将32位程序放置在syswow64目录下，微软这么做也是绕人。所以，两个32位的dll在syswow64目录下存在，但工具标记显示又在system32下，所以显示为找不到，怀疑这是工具的问题。

图7

2）ugmkn.dll的逆向分析

图8

在此注册表项（图8）下，如果发现有这些杀软，由DeviceIoControl发送控制码干掉。

图9

1FA0：StartAddress，1630的上一层，禁掉微软防火墙(图10)；

 图10

没找到这两个文件（图11），奇怪。

图11

利用ShellExecuteA函数来执行命令 sc stop PolicyAgent，隐藏GUI（图12）；

图12

启动aav服务（图13）；

图13

程序入口指向Execute（图14）：

图14

执行以下命令：

net stop WinDefend
net stop MpsSvc
sc config WinDefend start= disabled
sc config MpsSvc start= disabled
sc stop PolicyAgent
svchost.exe -k WerSvcGroup

总结：该ugmkn.dll功能为：停止安全防护服务或进程，创建 C:\Program Files\KAV\CDriver.sys程序；创建启动aav、WerSvc服务。

3）uvsln.dll的逆向分析

3-1、Execute函数：入口

图15

（图15）创建互斥体SeBebugPrivilege后，启动了“StartAddress、sub_10002160、sub_10002DD0”三个线程。

①StartAddress线程：通过wininet.dll(将c:\windows\system32\wininet.dll复制成c:\users\administrator\appdata\local\tmp\3DBD.tmp)底层LoadLibrary来调用连接193.166.255.171:8080（没有使用传统的bind、send之类的微软函数），完成后关闭；这里间隔 14280秒访问一次（图16）。

图16

②Sub_1002160线程：通过Advapi32.dll底层操作注册表、文件项等，完成后关闭。

图17

将自己复制到系统目录中后，添加到启动项（图17）。

③sub_10002DD0线程:遍历当前的盘符，循环执行system.exe

图18-1

图18-2

在图18-1中有个CreateFileA函数，我跟踪到线程中发现这里是创建盘符的虚拟文件创建（图18-2）。

这里DeviceIoControl的IOCTL_Code=0x2D1400h（图18、图19），

图19-1

图19-2

在图19-2中跟踪到DeviceIoControl时发现调用参数如图中右下角所示的参数。

我们利用工具对IOCTL_CODE:0x2D1400进行解读（图20）： 

图20-1

图20-1中解读出来，相当于语句：#define IOCTL_STORAGE_QUERY_PROPERTY CTL_CODE(FILE_DEVICE_MASS_STORAGE, 0x500, METHOD_BUFFERED, FILE_ANY_ACCESS)。这里的Function：0x500是微软自留的内部功能，我没查到它的具体含义，但查了网上很多都是0x500，估计这是个固定搭配。有Function解释为以上设备类型定义一个设备的唯一标识功能号（功能不详），用十六进制表示，转换为十进制后的有效范围是：0-2047是保留给微软，2048-4095是为OEM和IHV保留，其它功能代码定义大于4095。在跟踪调试的过程中发现这个0x500(图19-2)还真是非常关键，虽然执行后有了返回值但没搞明白这个动作到底要做什么，有点遗憾！

在调试的过程中，始终达不到if (v5==7)这个条件，一直在图18至图20中循环，为了进入sub_10002B20调试时就强行改变判断进入，发现图20-2，

图20-2

我们来看看图19-1中的sub_10002B20函数： 

图20-3

作用是遍历文件扩展名为’.exet’和最后一个字符为’t’的就删除该文件；如果文件扩展名为’.exe’和最后一个字符为’e’的就执行system.exe文件；

https://www.cnblogs.com/jiaping/p/9739166.html，CTL_CODE的一些说明，可了解下。

3-2、抓包分析

知道系rundll32加载dll，就对rundll32重点抓包，捕获到193.166.255.171这个IP，我们现就对这个IP进行抓包（图21）： 

图21

过了很久很久后，出现（图22）了取指令包动作： 

图22

出现了ip:193.166.255.171指向的域名tsa13.t12hg.com，url为 http://tsa13.t12hg.com:8080/sa13/d.txt(已不可访问)，怀疑是个指令文档。通过逆向该段代码及抓包验证后，发现这个木马很“鬼”，每隔14544秒(4个小时)的“潜伏”后再访问tsa13.t12hg.com（图23）。这就解释了当时我们在现场时没有抓到这个域名的原因，这点给我们提了个醒。

图23

（图23）在整个抓包过程中，仅有数量很少的几个包出现，很“谨慎小心”啊。

同时，在其体内发现有“PubwinClient.exe、Minisniffer”字符串（图24）。PubwinClient是浩艺网吧收银及管理软件的主进程，有意思。如果窗口标题为“Minisniffer”就退出（不允许抓包）。

图24

4）在对193.166.255.171查询后，发现：这是个C&C（图25），在这个IP下面罗列出了有这么多的木马指向这里，红框中列出的是我们这个木马。 

图25

5）再次抓包查看进程（图26），发现进程指向了sinkhole.fitsec.com（DAG生成新的域名），但ip:193.166.255.171:8080不变。

图26

至此，程序分析完成。

三、结论

木马构成：由system.exe运行释放出两个dll文件，由rundll32来加载运行这两个dll文件。其中一个dll与IP：193.166.255.171:8080的由DAG算法恶意生成的域名tsa13.t12hg.com进行通讯。http://tsa13.t12hg.com:8080/sa13/d.txt因失效而内容也不可知。

木马特点：一是利用win底层直接硬编码调用wininet.dll(Windows应用程序网络相关模块)，尽量少使用微软函数，导入表中有些敏感函数都没出现，使分析起来难度加大；二是由DeviceIoControl直接发送控制码来操作，工具软件无法监测到；三是通讯时采取间隔4小时方式，非常隐蔽。

驱动文件CDriver.sys没有找到而未开展分析。