对某服务器木马程序的分析
2023-1-10 22:20:56 Author: MicroPest(查看原文) 阅读量:14 收藏

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

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

曾以为只是一次例行的勘验,但恰如那句广告词,简约而不简单。最终我收获了启迪,打破了思维定式:抓包分析中,始终抓不到上线地址,一度怀疑人生。后来才发觉:木马在其体内设置了延时(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位的dllsyswow64目录下存在,但工具标记显示又在system32下,所以显示为找不到,怀疑这是工具的问题。

7

2)ugmkn.dll的逆向分析

 

8

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

9

1FA0:StartAddress1630的上一层,禁掉微软防火墙(图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)。

这里DeviceIoControlIOCTL_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,urlhttp://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.comDAG生成新的域名),但ip:193.166.255.171:8080不变。

26

至此,程序分析完成。

三、结论

木马构成:system.exe运行释放出两个dll文件,由rundll32来加载运行这两个dll文件。其中一个dllIP: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没有找到而未开展分析。


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NDcxMDQzNA==&mid=2247487562&idx=1&sn=57e54098b12c67e4c87d3879aa4fd757&chksm=a682c68791f54f91edeca911f648b79f72f096e56f1025e158cc3209948c424de9ab8feecd29#rd
如有侵权请联系:admin#unsafe.sh