再谈隐藏进程中的DLL模块/黑月教主

最新推荐文章于 2024-08-09 07:00:00 发布

YouthWang

最新推荐文章于 2024-08-09 07:00:00 发布

阅读量6.1k

点赞数

分类专栏：内核文章标签： dll null list object table c

内核专栏收录该内容

3 篇文章 0 订阅

订阅专栏

http://hi.baidu.com/_achillis/blog/item/59bf732623fbe509918f9d87.html

相当老的话题，大约一年前就写过这个东西了，不过那时候知识比较有限，也不了解内核，因此实现得很粗浅，现在再写一下，权当是对这个老问题的总结吧。
先谈谈正规DLL的隐藏方法，这里说的正规DLL，是指用LoadLibrary以正常方式加载的DLL。
一、从PEB的Ldr链中消失
这个很简单，看雪上NetRoc有一篇关于这个的文章，从分析原理到编程实现，虽然技术不算高深，但是思路非常精彩。来复习一下吧~~
lkd> dt _PEB 7ffdc000 //当前PEB的地址
nt!_PEB
    ...
    +0x00c Ldr               : 0x001a1e90 _PEB_LDR_DATA    //这里指向Ldr结构
lkd> dt _PEB_LDR_DATA 0x001a1e90 //这个结构里有三个链表的表头
nt!_PEB_LDR_DATA
    +0x000 Length            : 0x28
    +0x004 Initialized       : 0x1 ''
    +0x008 SsHandle          : (null)
    +0x00c InLoadOrderModuleList : _LIST_ENTRY [ 0x1a1ec0 - 0x1a34f8 ]
    +0x014 InMemoryOrderModuleList : _LIST_ENTRY [ 0x1a1ec8 - 0x1a3500 ]
    +0x01c InInitializationOrderModuleList : _LIST_ENTRY [ 0x1a1f28 - 0x1a3508 ]
    +0x024 EntryInProgress   : (null)
这里看到有三个链表，其实三个链表的内容是一样的，但是链表的顺序不一样，分别按加载顺序、内存顺序、初始化顺序排列
也就是说每一个DLL由一个LDR_DATA_TABLE_ENTRY结构描述，但是第一个结构被链入了三个链表。取一个来看看：
lkd> dt _LDR_DATA_TABLE_ENTRY 0x1a34f8
nt!_LDR_DATA_TABLE_ENTRY
    +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x1a1e9c - 0x1a3450 ]
    +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x1a1ea4 - 0x1a3458 ]
    +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x1a1eac - 0x1a3460 ]
    +0x018 DllBase            : 0x20000000
    +0x01c EntryPoint        : (null)
    +0x020 SizeOfImage       : 0x549000
    +0x024 FullDllName       : _UNICODE_STRING "C:/WINDOWS/system32/xpsp2res.dll"
    +0x02c BaseDllName       : _UNICODE_STRING "xpsp2res.dll"
   ......//省略部分内容
随便取一个链表进行遍历，根据DllBase找到自己的DLL之后，从三个链中RemoveEntryList就可以了，这样所有使用PEB->Ldr结构来枚举DLL链表的就无法找到了。
由于大部分ARK对隐藏DLL的查找并不是很重视(比如RKU,Gmer,XueTr,Atool,NIAP)，因此该方法就可以bypass很多ARK了，还是有一定市场的~
但对IceSword是个例外，下面就来说说如何bypass IceSword
二、从VAD树中消失
IceSword在枚举进程模块时使用的是ZwQueryVirtualMemory，查询的InfoClass是 MemorySectionName(或者叫MemoryMappedFilenameInformation，值为2)。 NtQueryVirtualMemory首先判断Vad->ControlArea->FilePointer是否有效，若有效则调用 ObQueryNameString查询此文件对象的名称，最终由文件系统完成此次查询工作。
关于VAD的详细知识，可以参考《JIURL玩玩Win2k内存篇 VAD》，这里不作为重点，知道是平衡二叉树就可以了，树的根结点在EPROCESS中。
lkd> dt _EPROCESS 83f915b8
nt!_EPROCESS
    ...
    +0x11c VadRoot            : 0x84079c08
该成员是一个MMVAD类型的结构，而成员LeftChild和RightChild分别是该结点的左子结点和右子结点。
lkd> dt _MMVAD 0x84079c08
nt!_MMVAD
    +0x000 StartingVpn        : 0x8e0
    +0x004 EndingVpn         : 0x8e0
    +0x008 Parent            : (null)
    +0x00c LeftChild         : 0x843b1128 _MMVAD //左孩子
    +0x010 RightChild        : 0x840bf4a0 _MMVAD //右孩子
    +0x014 u                 : __unnamed //标志位
    +0x018 ControlArea        : (null)
    +0x01c FirstPrototypePte : (null)
    +0x020 LastContiguousPte : (null)
    +0x024 u2                : __unnamed
要对目标DLL实施隐藏时，先获取该DLL基址，然后遍历VAD树，根据MMVAD->StartingVpn做匹配 (StartingVpn实际上是内存地址的高20位，比如0x7c800000在这里将只显示为0x7c800)找到目标DLL的VAD结构(这里以 kernel32.dll为例，其加载地址正为0x7c800000):
lkd> dt _MMVAD 84174a18
nt!_MMVAD
    +0x000 StartingVpn       : 0x7c800
    +0x004 EndingVpn         : 0x7c91b
    +0x008 Parent            : 0x841223a0 _MMVAD
    +0x00c LeftChild         : 0x84120470 _MMVAD
    +0x010 RightChild        : 0x841a4790 _MMVAD
    +0x014 u                 : __unnamed
    +0x018 ControlArea       : 0x876d0b88 _CONTROL_AREA //关键域
    +0x01c FirstPrototypePte : 0xe177d6f0 _MMPTE
    +0x020 LastContiguousPte : 0xfffffffc _MMPTE
    +0x024 u2                : __unnamed
lkd> dt _CONTROL_AREA 0x876d0b88
nt!_CONTROL_AREA
    ...
    +0x024 FilePointer        : 0x876d0b10 _FILE_OBJECT外 //目标在这里
好了，看到FILE_OBJECT了，这时你应该会想到系统是从这里取到的文件名吧，没错，这儿就是我们要动手脚的地方。根据小伟、 Sysnap等人的测试，只要把ControlArea->FilePointer->FileName.Buffer填0就可以实现该 DLL的隐藏(根据字符串的特性，实际上只需要把第一个字符填0就可以了)，此时ZwQueryVirtualMemory将返回0xC0000039错误，即“指定的路径无效”，自然也就枚举不到了。而且对于那些共享的dll,如系统的ntdll.dll,kernel32.dll或在不同进程中被加载 2次或以上的dll，虽然是在不同进程中，但是使用的是同一个共享的ControlArea结构,因此只需要改一个，那么在所有进程中都将实现隐藏，这对于隐藏全局钩子类型的dll显然是非常方便的。
IS是在ZwQueryVirtualMemory查完全无法枚举到DLL时才采用枚举PEB的方法，因此结合前面的Ldr断链法，足以搞定N多ARK了。
我所说的“从VAD树中消失”只是使该VAD的信息从IS的查询结果中消失，而并不是真的摘掉该VAD~~
值得一说的是，Sysnap的Yas Kit在检测隐藏DLL方面也是比较强的，但是对于动了VAD的，似乎也无能为力~
三、抹掉PE特征
有的工具可以直接枚举所有有效内存并检查PE标记来确定是否有隐藏DLL,因此需要把PE特征抹掉来对抗之，方法很简单，把PE头整个填零就可以了。
这种方法主要是作为前两种方法的补充，单独搞是没有意义的。

再来说说非正规方式加载的DLL，怎么个非正规呢？其实就是不用LoadLibrary，自已实现Loader的功能.
实现Loader功能之后，不管你是Load别的DLL，或者DLL自已Load自己(老V的ReloadAndRun同样适用于DLL)，在Load完成后，不会出现在PEB->Ldr链中，它的VAD也不会与FILE_OBJECT发生任何关系，然后再抹掉PE特征，隐藏效果与上面的正规隐藏法相当，甚至要更隐蔽一些~~
再极端一点，DLL也可以完全不要，注入具有相同功能的shellcode然后开线程执行就可以了，只是shellcode写起来麻烦一点而已，写Loader也麻烦啊~~
总之只要能把我们的代码跑起来就OK，DLL隐藏就写到这儿~~