基本信息            ：Lab10-02.exe

报告名称               ：Lab10-02.exe分析
作者                   ：精灵（^_^）/淘气鬼
报告更新日期           ：
样本发现日期           ：
样本类型               ：.exe文件
样本文件大小           ：32.0 KB
被感染文件变化长度     ：
样本文件的MD5校验值  ：3F3A29CA2467D2D05FEAC9D233366F45
样本的SHA1校验值     ：29A1DD1242DE0B67BF9B5FBECFD49490B13CFBB5
壳信息                 ：无
可能受威胁的系统       ：XP
先关漏洞               ：
一只检测名称           ：

简介                ：该文件被瑞星查杀，提示：Trojan.Win32.Genneric.16AB2C22（百度得知是木马病毒）

被感染的网络症状       ：无

系统文件变化           ：在C:\\Windows\\System32\\目录中生成一个隐藏的Mlwx486.sys文件，创建一个服务

注册文件变化           ：无

网络症状               ：无

详细分析/功能介绍
（当样本运行后会出现的操作）
（本次分析主要在虚拟机上进行分析，在进行分析之前，首先对虚拟机进行快照）

首先将对目标文件进行初步的静态分析、动态分析，其中主要涉及到的工具为：IDA，RegShot，depends，Process Explorer，process monitor等初级分析工具。
1．首先使用IDA将目标文件载入，使用它的一个插件功能，查看目标文件导入的相关函数。依据个人经验得到可疑结果如下所示：
Address    name                   Library     调用描述
00405004  StartServiceA            ADVAPI32  开启服务
00405008  CloseServiceHandle       ADVAPI32  关闭服务
0040500C  OpenSCManagerA        ADVAPI32  开启系统控制管理器
00405014  CreateFileA              KERNEL32 创建文件
00405018  SizeofResource           KERNEL32 获取资源大小
0040501C  WriteFile                KERNEL32 写文件
00405020  FindResourceA           KERNEL32 查找资源
00405024  LoadResource            KERNEL32 加载资源
0040502C  GetCommandLineA       KERNEL32 获取命令行
    综合以上函数可分为三类：加载资源，创建文件，开启系统控制管理器调用系统服务。这三类都是比较可疑的，因为一般文件不会同时使用到这三类函数进行使用。特别是打开系统控制管理器函数OpenSCManagerA ，这是开启/创建一个服务的必经之路，可以说这是提取r0权限最长使用的方法，也可以说rootkit经常使用到的方法。结合杀毒软件的描述，可疑初步怀疑他就是rootkit。但空凭这些证据就落实结论，会显得如此粗糙与不负责。最起码还要知道他创建了什么服务？在哪创建？创建服务需要到相关的.sys文件，哪里来的.sys数据源，还有一点要说明并没有找到DeleteFile( )函数（这说明目标文件只创建一个文件，并将其隐藏于硬盘的某个地方）。
这就需要我们进一步分析以上这三类调用的函数，实现的结果是什么？能否给我们答案。
2．在为运行目标程序之前，我们无法得知目标程序会创建什么文件，开启什么服务，但是我们可以尝试找一下LoadResource这个函数要加载的资源。所以我们需要将目标文件加载到Resource Hacker里面，检查他的资源段里面是否有可疑的“东西”（正常情况下，资源段里面只存放少量的图标，图片，所以很多可执行程序的资源段是空的）。得到结果确实是里面藏有“猫腻”，存放有一个pe文件。如图1所示：

    而且还在里面发现一个可以的字符串ASCII码：
00007640  49 00 00 00 63 3A 5C 77 69 6E 64 64 6B 5C 37 36   I晻昪:\winddk\76
00007650  30 30 2E 31 36 33 38 35 2E 31 5C 73 72 63 5C 67   00.16385.1\src\g
00007660  65 6E 65 72 61 6C 5C 72 6F 6F 74 6B 69 74 5C 77   eneral\rootkit\w
00007670  64 6D 5C 73 79 73 5C 6F 62 6A 66 72 65 5F 77 78   dm\sys\objfre_wx
00007680  70 5F 78 38 36 5C 69 33 38 36 5C 73 69 6F 63 74   p_x86\i386\sioct
00007690  6C 2E 70 64 62 00 00 00 00 00 00 00 00 00 00 00   l.pdb晻晻晻晻晻?   
    这可以进一步确定就是一个rootkit了。然而这还不能落实他究竟干了什么！
接下来开始进行初步动态分析。
3．使用RegShot进行快照拍摄，然后双击运行（这是通常pe文件运行的快捷方式），但这次却提示权限不够，说明运行这个文件需要赋予它更高的权限（以管理员身份运行）。这更具有rootkit的特点，因为rootkit需要你赋予它权限进去内核模式，然后生成/注入相关的服务。我们发现他在"C:\\Windows\\System32\\Mlwx486.sys"创建一个Mlwx486.sys。根据得到的文件创建路径，查看数否存在Mlwx486.sys文件。经过搜索并未找到相关的文件，可是整个程序并未找到调用/执行删除文件的相关函数。那唯一的解释就是文件被隐藏起来，也更吻合rootkit隐藏的特性。因为生成的文件是.sys文件，所以接下来需要使用windbg进行内核调试。（RegShot快照并没有发现注册表有可疑异动）
4．创建驱动就应该有服务调用它，所以接下来先从服务上下手。在IDA中找到StartServiceA，并找到这函数被调用的地方（其实上面"C:\\Windows\\System32\\Mlwx486.sys"，也可以用IDA查找到CreateFile调用的地方吗，便知道文件生成并存放的位置）得知服务名称为"486 WS Driver"，调用的内核驱动文件正是创建的文件。
push    offset BinaryPathName ; "C:\\Windows\\System32\\Mlwx486.sys"                                               源文件 支撑服务的脚本文件
push    1               ; dwErrorControl
push    3               ; dwStartType           服务开始类型（什么时候开启）
push    1               ; dwServiceType         服务类型（权限）
push    0F01FFh         ; dwDesiredAccess
push    offset DisplayName ; "486 WS Driver"
push    offset DisplayName ; "486 WS Driver"       服务名
push    eax             ; hSCManager           系统控制管理器句柄
call    ds:CreateServiceA
5．得到服务名之后，可以用sc命令+服务名 "486 WS Driver" 做参数，获取 以"486 WS Driver" 为名的服务状态。得到的结束如图2所示：

现在重点只需要关注前两个信息：
TYPE  ：1   LERNEL_DRIVER  （服务类型，为kernel类型驱动）
STATE ：4   RUNNING         （正在运行）
得知该服务还在运行，那就方便使用windbg调试了。
6．打开windbg将物理机与虚拟机联通
kd> lm
start       end             module name
7c920000 7c9b3000   ntdll      (pdb symbols)          d:\symbolslocal\ntdll.pdb\1751003260CA42598C0FB326585000ED2\ntdll.pdb
804d8000 806d0480   nt         (pdb symbols)          d:\symbolslocal\ntkrnlpa.pdb\30B5FB31AE7E4ACAABA750AA241FF3311\ntkrnlpa.pdb
806d1000 806f1300   hal        (deferred)  
…………
f8c84000 f8c84b80   Null       (deferred)             
f8cf6000 f8cf6d00   dxgthk     (deferred)             
f8d95000 f8d95d80   Mlwx486    (deferred)             
f8d9a000 f8d9ac00   audstub    (deferred)   
找到了我们的目标服务（起始地址）f8d95000  （结束地址）f8d95d80   （模块名）Mlwx486  
现在已经确定rootkit产生的服务已经开启，但是在硬盘上又找不到Mlwx486.sys 文件，因此很可能是进行了挂钩。所以需要查看SSDT（系统服务调度表）。

7．kd> dd dwo(KeServiceDescriptorTable) L200
80502b8c  8059a948 805e7db6 805eb5fc 805e7de8
80502b9c  805eb636 805e7e1e 805eb67a 805eb6be
80502bac  8060cdfe 8060db50 805e31b4 805e2e0c
80502bbc  805cbde6 805cbd96 8060d424 805ac5ae
80502bcc  8060ca3c 8059edbe 805a6a00 805cd8c4
80502bdc  80500828 8060db42 8056ccd6 8053600e
…………………………………………………………
80502d7c  805e4660 805a0722 8060c254 805ba77a
80502d8c  805c2522 805e4a1a 805e47d0 8060e1b0
80502d9c  8063cc78 805c0346 805eedce 805eaa16
80502dac  805eac02 805aea08 806062dc 8056d0ce
80502dbc  8060db50 8060db50 8053d02e 80607e68
80502dcc  80608ac8 f8d95486 805b4de0 805703ca
80502ddc  806063a4 8056d222 8060d2dc 80570c46
80502dec  805ccee0 8059b6fc 805c3bfc 805c27c8
80502dfc  805e4afa 80608266 8060f060 8056edda
80502e0c  8061c97e 8061a3d4 8060e93e 805bc04c
f8d95486  这个地址第一感觉就是不正常，第二感觉就是有点熟。不正常是因为他已经超出了ntoskrnl.dll的范围之内。
回顾上面Mlwx486模块其实和结束地址f8d95000 f8d95d80 发现f8d95486 正是在这个范围之内，所以可以断定80502dcc  80608ac8 f8d95486 805b4de0 805703ca 中原函数已经被挂Mlwx486的钩子。现在需要知道被挂钩前的原函数是什么，这就得恢复快照之前然后进行查找对比。
kd> dd dwo(KeServiceDescriptorTable) L100
……………………………………………………
80502d7c  805e4660 805a0722 8060c254 805ba77a
80502d8c  805c2522 805e4a1a 805e47d0 8060e1b0
80502d9c  8063cc78 805c0346 805eedce 805eaa16
80502dac  805eac02 805aea08 806062dc 8056d0ce
80502dbc  8060db50 8060db50 8053d02e 80607e68
80502dcc  80608ac8 80570074 805b4de0 805703ca
80502ddc  806063a4 8056d222 8060d2dc 80570c46
80502dec  805ccee0 8059b6fc 805c3bfc 805c27c8
80502dfc  805e4afa 80608266 8060f060 8056edda
现已确定被挂钩的函数起始地址是80570074 ，然后一个地址为基地址，使用反汇编指令查看相关基址的函数。
kd> u 80570074
nt!NtQueryDirectoryFile:
80570074 8bff            mov     edi,edi
80570076 55              push    ebp
80570077 8bec            mov     ebp,esp
80570079 8d452c          lea     eax,[ebp+2Ch]
8057007c 50              push    eax
8057007d 8d4528          lea     eax,[ebp+28h]
80570080 50              push    eax
80570081 8d4524          lea     eax,[ebp+24h]

百度搜索nt!NtQueryDirectoryFile:得知：ntdll 中的NtQueryDirectoryFile 来实现隐藏文件名为test.hook的文件。这也正吻合了之前为什么找不到这个文件的原因。原来是我们打开相关文件路径是机已经调用到了NtQueryDirectoryFile  这个函数才能找到相关的文件，而rootkit却将NtQueryDirectoryFile  函数挂钩所以我们将查询不到相关文件

相关服务器信息分析
（可以提供一些详细的目标域名，IP地址，邮件地址…………相关信息）
无

预防及修复措施
更新查毒软件，现在大多是国内的查毒工具都可以查杀出来。

技术热点及总结
一、创建隐藏文件。
二、在资源段中插入一个pe文件。
三、生成服务
四、使用hook技术，将生成文件与ntoskrnl模块中的函数进行挂钩，已达到隐藏并长期潜伏效果。
                                                 精灵（^_^）/淘气鬼

[课程]Android-CTF解题方法汇总！