在WIN9X中，只需要将进程注册为系统服务就能够从进程查看器中隐形，可是这一切在WINNT中却完全不同，无论木马从端口、启动文件上如何巧妙地隐藏自己，始终都不能欺骗WINNT的任务管理器，以至于很多的朋友问我：在WINNT下难道木马真的再也无法隐藏自己的进程了？本文试图通过探讨WINNT中木马的几种常用隐藏进程手段，给大家揭示木马/后门程序在WINNT中进程隐藏的方法和查找的途径。
我们知道，在WINDOWS系统下，可执行文件主要是Exe和Com文件，这两种文件在运行时都有一个共同点，会生成一个独立的进程，寻找特定进程是我们发现木马的方法之一（无论手动还是防火墙），随着入侵检测软件的不断发展，关联进程和SOCKET已经成为流行的技术（例如著名的FPort就能够检测出任何进程打开的TCP/UDP端口），假设一个木马在运行时被检测软件同时查出端口和进程，我们基本上认为这个木马的隐藏已经完全失败（利用心理因素而非技术手段欺骗用户的木马不在我们的讨论范围之内）。在NT下正常情况用户进程对于系统管理员来说都是可见的，要想做到木马的进程隐藏，有两个办法，第一是让系统管理员看不见（或者视而不见）你的进程；第二是不使用进程。
让系统管理员看不见进程的方法就是进行进程列表欺骗，为了了解如何看不见进程，我们首先要了解怎样能看得见进程：在Windows中有多种方法能够看到进程的存在：PSAPI（Process Status API），PDH（Performance Data Helper），ToolHelp API，如果我们能够欺骗用户和入侵检测软件用来查看进程的函数（例如截获相应的API调用，替换返回的数据），我们就完全能实现进程隐藏，但是一来我们并不知道用户和入侵软件使用的是什么方法来查看进程列表，二来如果我们有权限和技术实现这样的欺骗，我们就一定能使用其它的方法更容易的实现进程的隐藏。（例如：能够替换DLL或挂接API来隐藏进程不如直接用来做木马。）
第二种方法是不使用进程，不使用进程使用什么？为了弄明白这个问题，我们必须要先了解Windows系统的另一种“可执行文件”----DLL，DLL是Dynamic Link Library（动态链接库）的缩写，DLL文件是Windows的基础，因为所有的API函数都是在DLL中实现的。DLL文件没有程序逻辑，是由多个功能函数构成，它并不能独立运行，一般都是由进程加载并调用的。（你你你，你刚刚不是说不用进程了？）别急呀，听我慢慢道来：因为DLL文件不能独立运行，所以在进程列表中并不会出现DLL，假设我们编写了一个木马DLL，并且通过别的进程来运行它，那么无论是入侵检测软件还是进程列表中，都只会出现那个进程而并不会出现木马DLL，如果那个进程是可信进程，（例如资源管理器Explorer.exe，没人会怀疑它是木马吧？）那么我们编写的DLL作为那个进程的一部分，也将成为被信赖的一员而为所欲为。
运行DLL文件最简单的方法是利用Rundll32.exe，Rundll/Rundll32是Windows自带的动态链接库工具，可以用来在命令行下执行动态链接库中的某个函数，其中Rundll是16位而Rundll32是32位的（分别调用16位和32位的DLL文件），Rundll32的使用方法如下：
Rundll32 DllFileName FuncName
例如我们编写了一个MyDll.dll，这个动态链接库中定义了一个MyFunc的函数，那么，我们通过Rundll32.exe MyDll.dll MyFunc就可以执行MyFunc函数的功能。
这个和木马的进程隐藏有什么关系么？当然有了，假设我们在MyFunc函数中实现了木马的功能，那么我们不就可以通过Rundll32来运行这个木马了么？在系统管理员看来，进程列表中增加的是Rundll32.exe而并不是木马文件，这样也算是木马的一种简易欺骗和自我保护方法（至少你不能去把Rundll32.exe删掉吧？想从Rundll32进程找到DLL木马还是有一点麻烦的）
使用Rundll32的方法进行进程隐藏是简易的，非常容易被识破。（虽然杀起来会麻烦一点）比较高级的方法是使用特洛伊DLL，特洛伊DLL的工作原理是使用木马DLL替换常用的DLL文件，通过函数转发器将正常的调用转发给原DLL，截获并处理特定的消息。例如，我们知道WINDOWS的Socket1.x的函数都是存放在wsock32.dll中的，那么我们自己写一个wsock32.dll文件，替换掉原先的wsock32.dll（将原先的DLL文件重命名为wsockold.dll）我们的wsock32.dll只做两件事，一是如果遇到不认识的调用，就直接转发给wsockold.dll（使用函数转发器forward）；二是遇到特殊的请求（事先约定的）就解码并处理。这样理论上只要木马编写者通过SOCKET远程输入一定的暗号，就可以控制wsock32.dll（木马DLL）做任何操作。特洛伊DLL技术是比较古老的技术，因此微软也对此做了相当的防范，在Win2K的system32目录下有一个dllcache的目录，这个目录中存放着大量的DLL文件（也包括一些重要的exe文件），这个是微软用来保护DLL的法宝，一旦操作系统发现被保护的DLL文件被篡改（数字签名技术），它就会自动从dllcache中恢复这个文件。虽然说有种种方法可以绕过DLL保护（例如先更改dllcache目录中的备份再修改DLL文件、或者利用KnownDLLs键值更改DLL的默认启动路径等），但是可以想见的未来微软必将更加小心地保护重要的DLL文件；同时由于特洛伊DLL方法本身有着一些漏洞（例如修复安装、安装补丁、升级系统、检查数字签名等方法都有可能导致特洛伊DLL失效），所以这个方法也不能算是DLL木马的最优选择。
DLL木马的最高境界是动态嵌入技术，动态嵌入技术指的是将自己的代码嵌入正在运行的进程中的技术。理论上来说，在Windows中的每个进程都有自己的私有内存空间，别的进程是不允许对这个私有空间进行操作的（私人领地、请勿入内），但是实际上，我们仍然可以利用种种方法进入并操作进程的私有内存。在多种动态嵌入技术中（窗口Hook、挂接API、远程线程），我最喜欢的是远程线程技术，这种技术非常简单，只要有基本的进线程和动态链接库的知识就可以很轻松地完成嵌入，下面就为大家介绍一下远程线程技术。
远程线程技术指的是通过在另一个进程中创建远程线程的方法进入那个进程的内存地址空间。我们知道，在进程中，可以通过CreateThread函数创建线程，被创建的新线程与主线程（就是进程启动时被同时自动建立的那个线程）共享地址空间以及其他的资源。但是很少有人知道，通过CreateRemoteThread也同样可以在另一个进程内创建新线程，被创建的远程线程同样可以共享远程进程（是远程进程耶！）的地址空间，所以，实际上，我们通过一个远程线程，进入了远程进程的内存地址空间，也就拥有了那个远程进程相当的权限。例如在远程进程内部启动一个DLL木马（与进入进程内部相比，启动一个DLL木马是小意思，实际上我们可以随意篡改那个远程进程的数据^_^）
闲话少说，我们来看代码：
首先，我们通过OpenProcess 来打开我们试图嵌入的进程（如果远程进程不允许打开，那么嵌入就无法进行了，这往往是由于权限不足引起的，解决方法是通过种种途径提升本地进程的权限）
hRemoteProcess = OpenProcess( PROCESS_CREATE_THREAD | //允许远程创建线程
PROCESS_VM_OPERATION | //允许远程VM操作
PROCESS_VM_WRITE, //允许远程VM写
FALSE, dwRemoteProcessId )
由于我们后面需要写入远程进程的内存地址空间并建立远程线程，所以需要申请足够的权限（PROCESS_CREATE_THREAD、VM_OPERATION、VM_WRITE）。
然后，我们可以建立LoadLibraryW函数这个线程来启动我们的DLL木马，LoadLibraryW函数是在kernel32.dll中定义的，用来加载DLL文件，它只有一个参数，就是DLL文件的绝对路径名pszLibFileName，（也就是木马DLL的全路径文件名），但是由于木马DLL是在远程进程内调用的，所以我们首先还需要将这个文件名复制到远程地址空间：（否则远程线程是无法读到这个参数的）
//计算DLL路径名需要的内存空间
int cb = (1 + lstrlenW(pszLibFileName)) * sizeof(WCHAR);
//使用VirtualAllocEx函数在远程进程的内存地址空间分配DLL文件名缓冲区
pszLibFileRemote = (PWSTR) VirtualAllocEx( hRemoteProcess, NULL, cb,
MEM_COMMIT, PAGE_READWRITE);
//使用WriteProcessMemory函数将DLL的路径名复制到远程进程的内存空间
iReturnCode = WriteProcessMemory(hRemoteProcess,
pszLibFileRemote, (PVOID) pszLibFileName, cb, NULL);
//计算LoadLibraryW的入口地址
PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE)
GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
OK，万事俱备，我们通过建立远程线程时的地址pfnStartAddr（实际上就是LoadLibraryW的入口地址）和传递的参数pszLibFileRemote（实际上是我们复制过去的木马DLL的全路径文件名）在远程进程内启动我们的木马DLL：
//启动远程线程LoadLibraryW，通过远程线程调用用户的DLL文件
hRemoteThread = CreateRemoteThread( hRemoteProcess, NULL, 0,
pfnStartAddr, pszLibFileRemote, 0, NULL);
至此，远程嵌入顺利完成，为了试验我们的DLL是不是已经正常的在远程线程运行，我编写了以下的测试DLL：
BOOL APIENTRY DllMain(HANDLE hModule, DWORD reason, LPVOID lpReserved)
{
char szProcessId[64] ;
switch ( reason )
{
case DLL_PROCESS_ATTACH:
{
//获取当前进程ID
_itoa ( GetCurrentProcessId(), szProcessId, 10 );
MessageBox ( NULL, szProcessId, "RemoteDLL", MB_OK );
}
default:
return TRUE;
}
}
当我使用RmtDll.exe程序将这个TestDLL.dll嵌入Explorer.exe进程后（PID=1208），该测试DLL弹出了1208字样的确认框，同时使用PS工具也能看到
Process ID: 1116
C:\WINNT\Explorer.exe (0x00400000)
……
C:\TestDLL.dll (0x100000000)
……
这证明TestDLL.dll已经在Explorer.exe进程内正确地运行了。
无论是使用特洛伊DLL还是使用远程线程，都是让木马的核心代码运行于别的进程的内存空间，这样不仅能很好地隐藏自己，也能更好的保护自己。
这个时候，我们可以说已经实现了一个真正意义上的木马，它不仅欺骗、进入你的计算机，甚至进入了进程的内部，从某种意义上说，这种木马已经具备了病毒的很多特性，例如隐藏和寄生（和宿主同生共死），如果有一天，出现了具备所有病毒特性的木马（不是指蠕虫，而是传统意义上的寄生病毒），我想我并不会感到奇怪，倒会疑问这一天为什么这么迟才到来。
DLL木马的查杀
要是我的这篇文章到此结束，那么就变成了DLL木马编写教学了:P，其实我们了解DLL木马原理的最终目的还是为了更好的防御它，所以，让我们来讨论一下DLL木马的查杀。
DLL木马对于进程管理器来说是隐藏的，所以我们既不能用进程管理器来查找，也无法直接将它停止运行，假设DLL木马嵌在Explorer.exe这样的进程我们还能直接将宿主进程杀掉，但是如果木马通过提升权限等方法进入了inetinfo.exe这样的系统进程（IIS），那么即使是管理员，也不能直接终止木马的运行。（在NT中，系统进程不能被直接kill）。因此，我们不能指望NT自带的进程管理器了，需要使用一些附加的工具。
一、 进程/内存模块查看器：
为了能发现DLL木马，我们必须能查看内存中运行的DLL模块（记得么？DLL木马运行在已有的进程内），前面说了，在Windows下查看进程/内存模块的方法很多，有PSAPI、PDH和ToolHelper API。我用PSAPI写了一个这样的工具，补天的雏鹰用PDH写了一个更加强大的进程查看器，支持查看远程主机状况（知道系统管理员密码的情况下），希望早日整理发布。
PS工具可以在以下地址下载到：
http://www.patching.net/shotgun/ps.zip
实际上，由于Windows系统的复杂性，即使有了上面的工具，查找DLL木马仍然是非常艰难的，只有非常了解系统结构的管理员才能从无数的DLL文件中找到异常的那一个，所以，平时使用PS工具备份一个DLL文件列表会比较有帮助，方法很简单，ps.exe /a /m >ps.log。
二、 端口进程关联软件：
关联端口和进程的软件也是重要的工具之一，虽然DLL木马隐藏在其他进程中，但是多多少少会有一些异常，功能强大的Fport就是一个优秀的进程端口关联软件，可以在以下地址下载到：（我自己同样写了一个，但是没有Fport好用，所以就不拿出来献丑了，呵呵）
http://www.foundstone.com/rdlabs/termsofuse.php?filename=FPortNG.zip
三、 嗅探器：
嗅探器帮助我们发现异常的网络通讯，从而引起我们的警惕和关注，嗅探器的原理很简单，通过将网卡设为混杂模式就可以接受所有的IP报文，嗅探程序可以从中选择值得关注的部分进行分析，剩下的无非是按照RFC文档对协议进行解码。在补天的主页上我放置了一个WIN2K下的命令行嗅探器，任何有兴趣的朋友都可以去下载源码并改写成自己需要的工具：
代码及头文件： http://www.patching.net/shotgun/GUNiffer.zip
编译后的程序： http://www.patching.net/shotgun/GUNiffer.exe
四、 注册表保护软件：
可以想象，DLL木马仍然会继续利用注册表来启动自己（在Windows中到哪里去找一个比注册表更复杂、更适合木马隐藏的地方呢？）不同的是，DLL木马不仅仅局限于Run、Runonce这些众所周知的子键，而是拥有更多的选择。例如对于特洛伊DLL来说，KnownDLLs子键就是再好不过的藏身之处，在注册表的HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\KnownDLLs子键下，存放着一些已知DLL的默认路径，假设DLL木马修改或增加了某个键值，那么木马DLL就可以无声无息地在进程加载知名DLL的时候取代原本的DLL文件进入进程。注册表保护的软件非常多，Lockdown2000就内置这样的功能，另外，SysInternals的Regmon也很不错，下载地址：
http://www.nttoolbox.com/public/tools/ntregmon.zip
五、 文件保护：
除了注册表，文件也是DLL木马的启动工具，利用Appname.local 文件进行的DLL转移就可以顺利替换任何应用程序启动时加载的默认DLL，特洛伊DLL更是层出不穷，同样是SysInternals出品的Filemon可以担当文件保护的重则：
http://www.nttoolbox.com/public/tools/ntfilmon.zip
DLL木马的查杀非常复杂，并不是一天两天能够掌握的，目前补天公司也正在进行相关防御软件的开发，希望很快能为大家提供一个简单快捷的解决方案。
最后，感谢西祠的Lion Hook在DLL文件操作上对我的指导，同时也感谢补天的abu、yagami、eyas、sztwww、大鹰、大皮球和其他兄弟们跟我一起讨论隐藏进程的技术，让我学到了很多的东西。
我们知道，在WINDOWS系统下，可执行文件主要是Exe和Com文件，这两种文件在运行时都有一个共同点，会生成一个独立的进程，寻找特定进程是我们发现木马的方法之一（无论手动还是防火墙），随着入侵检测软件的不断发展，关联进程和SOCKET已经成为流行的技术（例如著名的FPort就能够检测出任何进程打开的TCP/UDP端口），假设一个木马在运行时被检测软件同时查出端口和进程，我们基本上认为这个木马的隐藏已经完全失败（利用心理因素而非技术手段欺骗用户的木马不在我们的讨论范围之内）。在NT下正常情况用户进程对于系统管理员来说都是可见的，要想做到木马的进程隐藏，有两个办法，第一是让系统管理员看不见（或者视而不见）你的进程；第二是不使用进程。
让系统管理员看不见进程的方法就是进行进程列表欺骗，为了了解如何看不见进程，我们首先要了解怎样能看得见进程：在Windows中有多种方法能够看到进程的存在：PSAPI（Process Status API），PDH（Performance Data Helper），ToolHelp API，如果我们能够欺骗用户和入侵检测软件用来查看进程的函数（例如截获相应的API调用，替换返回的数据），我们就完全能实现进程隐藏，但是一来我们并不知道用户和入侵软件使用的是什么方法来查看进程列表，二来如果我们有权限和技术实现这样的欺骗，我们就一定能使用其它的方法更容易的实现进程的隐藏。（例如：能够替换DLL或挂接API来隐藏进程不如直接用来做木马。）
第二种方法是不使用进程，不使用进程使用什么？为了弄明白这个问题，我们必须要先了解Windows系统的另一种“可执行文件”----DLL，DLL是Dynamic Link Library（动态链接库）的缩写，DLL文件是Windows的基础，因为所有的API函数都是在DLL中实现的。DLL文件没有程序逻辑，是由多个功能函数构成，它并不能独立运行，一般都是由进程加载并调用的。（你你你，你刚刚不是说不用进程了？）别急呀，听我慢慢道来：因为DLL文件不能独立运行，所以在进程列表中并不会出现DLL，假设我们编写了一个木马DLL，并且通过别的进程来运行它，那么无论是入侵检测软件还是进程列表中，都只会出现那个进程而并不会出现木马DLL，如果那个进程是可信进程，（例如资源管理器Explorer.exe，没人会怀疑它是木马吧？）那么我们编写的DLL作为那个进程的一部分，也将成为被信赖的一员而为所欲为。
运行DLL文件最简单的方法是利用Rundll32.exe，Rundll/Rundll32是Windows自带的动态链接库工具，可以用来在命令行下执行动态链接库中的某个函数，其中Rundll是16位而Rundll32是32位的（分别调用16位和32位的DLL文件），Rundll32的使用方法如下：
Rundll32 DllFileName FuncName
例如我们编写了一个MyDll.dll，这个动态链接库中定义了一个MyFunc的函数，那么，我们通过Rundll32.exe MyDll.dll MyFunc就可以执行MyFunc函数的功能。
这个和木马的进程隐藏有什么关系么？当然有了，假设我们在MyFunc函数中实现了木马的功能，那么我们不就可以通过Rundll32来运行这个木马了么？在系统管理员看来，进程列表中增加的是Rundll32.exe而并不是木马文件，这样也算是木马的一种简易欺骗和自我保护方法（至少你不能去把Rundll32.exe删掉吧？想从Rundll32进程找到DLL木马还是有一点麻烦的）
使用Rundll32的方法进行进程隐藏是简易的，非常容易被识破。（虽然杀起来会麻烦一点）比较高级的方法是使用特洛伊DLL，特洛伊DLL的工作原理是使用木马DLL替换常用的DLL文件，通过函数转发器将正常的调用转发给原DLL，截获并处理特定的消息。例如，我们知道WINDOWS的Socket1.x的函数都是存放在wsock32.dll中的，那么我们自己写一个wsock32.dll文件，替换掉原先的wsock32.dll（将原先的DLL文件重命名为wsockold.dll）我们的wsock32.dll只做两件事，一是如果遇到不认识的调用，就直接转发给wsockold.dll（使用函数转发器forward）；二是遇到特殊的请求（事先约定的）就解码并处理。这样理论上只要木马编写者通过SOCKET远程输入一定的暗号，就可以控制wsock32.dll（木马DLL）做任何操作。特洛伊DLL技术是比较古老的技术，因此微软也对此做了相当的防范，在Win2K的system32目录下有一个dllcache的目录，这个目录中存放着大量的DLL文件（也包括一些重要的exe文件），这个是微软用来保护DLL的法宝，一旦操作系统发现被保护的DLL文件被篡改（数字签名技术），它就会自动从dllcache中恢复这个文件。虽然说有种种方法可以绕过DLL保护（例如先更改dllcache目录中的备份再修改DLL文件、或者利用KnownDLLs键值更改DLL的默认启动路径等），但是可以想见的未来微软必将更加小心地保护重要的DLL文件；同时由于特洛伊DLL方法本身有着一些漏洞（例如修复安装、安装补丁、升级系统、检查数字签名等方法都有可能导致特洛伊DLL失效），所以这个方法也不能算是DLL木马的最优选择。
DLL木马的最高境界是动态嵌入技术，动态嵌入技术指的是将自己的代码嵌入正在运行的进程中的技术。理论上来说，在Windows中的每个进程都有自己的私有内存空间，别的进程是不允许对这个私有空间进行操作的（私人领地、请勿入内），但是实际上，我们仍然可以利用种种方法进入并操作进程的私有内存。在多种动态嵌入技术中（窗口Hook、挂接API、远程线程），我最喜欢的是远程线程技术，这种技术非常简单，只要有基本的进线程和动态链接库的知识就可以很轻松地完成嵌入，下面就为大家介绍一下远程线程技术。
远程线程技术指的是通过在另一个进程中创建远程线程的方法进入那个进程的内存地址空间。我们知道，在进程中，可以通过CreateThread函数创建线程，被创建的新线程与主线程（就是进程启动时被同时自动建立的那个线程）共享地址空间以及其他的资源。但是很少有人知道，通过CreateRemoteThread也同样可以在另一个进程内创建新线程，被创建的远程线程同样可以共享远程进程（是远程进程耶！）的地址空间，所以，实际上，我们通过一个远程线程，进入了远程进程的内存地址空间，也就拥有了那个远程进程相当的权限。例如在远程进程内部启动一个DLL木马（与进入进程内部相比，启动一个DLL木马是小意思，实际上我们可以随意篡改那个远程进程的数据^_^）
闲话少说，我们来看代码：
首先，我们通过OpenProcess 来打开我们试图嵌入的进程（如果远程进程不允许打开，那么嵌入就无法进行了，这往往是由于权限不足引起的，解决方法是通过种种途径提升本地进程的权限）
hRemoteProcess = OpenProcess( PROCESS_CREATE_THREAD | //允许远程创建线程
PROCESS_VM_OPERATION | //允许远程VM操作
PROCESS_VM_WRITE, //允许远程VM写
FALSE, dwRemoteProcessId )
由于我们后面需要写入远程进程的内存地址空间并建立远程线程，所以需要申请足够的权限（PROCESS_CREATE_THREAD、VM_OPERATION、VM_WRITE）。
然后，我们可以建立LoadLibraryW函数这个线程来启动我们的DLL木马，LoadLibraryW函数是在kernel32.dll中定义的，用来加载DLL文件，它只有一个参数，就是DLL文件的绝对路径名pszLibFileName，（也就是木马DLL的全路径文件名），但是由于木马DLL是在远程进程内调用的，所以我们首先还需要将这个文件名复制到远程地址空间：（否则远程线程是无法读到这个参数的）
//计算DLL路径名需要的内存空间
int cb = (1 + lstrlenW(pszLibFileName)) * sizeof(WCHAR);
//使用VirtualAllocEx函数在远程进程的内存地址空间分配DLL文件名缓冲区
pszLibFileRemote = (PWSTR) VirtualAllocEx( hRemoteProcess, NULL, cb,
MEM_COMMIT, PAGE_READWRITE);
//使用WriteProcessMemory函数将DLL的路径名复制到远程进程的内存空间
iReturnCode = WriteProcessMemory(hRemoteProcess,
pszLibFileRemote, (PVOID) pszLibFileName, cb, NULL);
//计算LoadLibraryW的入口地址
PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE)
GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
OK，万事俱备，我们通过建立远程线程时的地址pfnStartAddr（实际上就是LoadLibraryW的入口地址）和传递的参数pszLibFileRemote（实际上是我们复制过去的木马DLL的全路径文件名）在远程进程内启动我们的木马DLL：
//启动远程线程LoadLibraryW，通过远程线程调用用户的DLL文件
hRemoteThread = CreateRemoteThread( hRemoteProcess, NULL, 0,
pfnStartAddr, pszLibFileRemote, 0, NULL);
至此，远程嵌入顺利完成，为了试验我们的DLL是不是已经正常的在远程线程运行，我编写了以下的测试DLL：
BOOL APIENTRY DllMain(HANDLE hModule, DWORD reason, LPVOID lpReserved)
{
char szProcessId[64] ;
switch ( reason )
{
case DLL_PROCESS_ATTACH:
{
//获取当前进程ID
_itoa ( GetCurrentProcessId(), szProcessId, 10 );
MessageBox ( NULL, szProcessId, "RemoteDLL", MB_OK );
}
default:
return TRUE;
}
}
当我使用RmtDll.exe程序将这个TestDLL.dll嵌入Explorer.exe进程后（PID=1208），该测试DLL弹出了1208字样的确认框，同时使用PS工具也能看到
Process ID: 1116
C:\WINNT\Explorer.exe (0x00400000)
……
C:\TestDLL.dll (0x100000000)
……
这证明TestDLL.dll已经在Explorer.exe进程内正确地运行了。
无论是使用特洛伊DLL还是使用远程线程，都是让木马的核心代码运行于别的进程的内存空间，这样不仅能很好地隐藏自己，也能更好的保护自己。
这个时候，我们可以说已经实现了一个真正意义上的木马，它不仅欺骗、进入你的计算机，甚至进入了进程的内部，从某种意义上说，这种木马已经具备了病毒的很多特性，例如隐藏和寄生（和宿主同生共死），如果有一天，出现了具备所有病毒特性的木马（不是指蠕虫，而是传统意义上的寄生病毒），我想我并不会感到奇怪，倒会疑问这一天为什么这么迟才到来。
DLL木马的查杀
要是我的这篇文章到此结束，那么就变成了DLL木马编写教学了:P，其实我们了解DLL木马原理的最终目的还是为了更好的防御它，所以，让我们来讨论一下DLL木马的查杀。
DLL木马对于进程管理器来说是隐藏的，所以我们既不能用进程管理器来查找，也无法直接将它停止运行，假设DLL木马嵌在Explorer.exe这样的进程我们还能直接将宿主进程杀掉，但是如果木马通过提升权限等方法进入了inetinfo.exe这样的系统进程（IIS），那么即使是管理员，也不能直接终止木马的运行。（在NT中，系统进程不能被直接kill）。因此，我们不能指望NT自带的进程管理器了，需要使用一些附加的工具。
一、 进程/内存模块查看器：
为了能发现DLL木马，我们必须能查看内存中运行的DLL模块（记得么？DLL木马运行在已有的进程内），前面说了，在Windows下查看进程/内存模块的方法很多，有PSAPI、PDH和ToolHelper API。我用PSAPI写了一个这样的工具，补天的雏鹰用PDH写了一个更加强大的进程查看器，支持查看远程主机状况（知道系统管理员密码的情况下），希望早日整理发布。
PS工具可以在以下地址下载到：
http://www.patching.net/shotgun/ps.zip
实际上，由于Windows系统的复杂性，即使有了上面的工具，查找DLL木马仍然是非常艰难的，只有非常了解系统结构的管理员才能从无数的DLL文件中找到异常的那一个，所以，平时使用PS工具备份一个DLL文件列表会比较有帮助，方法很简单，ps.exe /a /m >ps.log。
二、 端口进程关联软件：
关联端口和进程的软件也是重要的工具之一，虽然DLL木马隐藏在其他进程中，但是多多少少会有一些异常，功能强大的Fport就是一个优秀的进程端口关联软件，可以在以下地址下载到：（我自己同样写了一个，但是没有Fport好用，所以就不拿出来献丑了，呵呵）
http://www.foundstone.com/rdlabs/termsofuse.php?filename=FPortNG.zip
三、 嗅探器：
嗅探器帮助我们发现异常的网络通讯，从而引起我们的警惕和关注，嗅探器的原理很简单，通过将网卡设为混杂模式就可以接受所有的IP报文，嗅探程序可以从中选择值得关注的部分进行分析，剩下的无非是按照RFC文档对协议进行解码。在补天的主页上我放置了一个WIN2K下的命令行嗅探器，任何有兴趣的朋友都可以去下载源码并改写成自己需要的工具：
代码及头文件： http://www.patching.net/shotgun/GUNiffer.zip
编译后的程序： http://www.patching.net/shotgun/GUNiffer.exe
四、 注册表保护软件：
可以想象，DLL木马仍然会继续利用注册表来启动自己（在Windows中到哪里去找一个比注册表更复杂、更适合木马隐藏的地方呢？）不同的是，DLL木马不仅仅局限于Run、Runonce这些众所周知的子键，而是拥有更多的选择。例如对于特洛伊DLL来说，KnownDLLs子键就是再好不过的藏身之处，在注册表的HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\KnownDLLs子键下，存放着一些已知DLL的默认路径，假设DLL木马修改或增加了某个键值，那么木马DLL就可以无声无息地在进程加载知名DLL的时候取代原本的DLL文件进入进程。注册表保护的软件非常多，Lockdown2000就内置这样的功能，另外，SysInternals的Regmon也很不错，下载地址：
http://www.nttoolbox.com/public/tools/ntregmon.zip
五、 文件保护：
除了注册表，文件也是DLL木马的启动工具，利用Appname.local 文件进行的DLL转移就可以顺利替换任何应用程序启动时加载的默认DLL，特洛伊DLL更是层出不穷，同样是SysInternals出品的Filemon可以担当文件保护的重则：
http://www.nttoolbox.com/public/tools/ntfilmon.zip
DLL木马的查杀非常复杂，并不是一天两天能够掌握的，目前补天公司也正在进行相关防御软件的开发，希望很快能为大家提供一个简单快捷的解决方案。
最后，感谢西祠的Lion Hook在DLL文件操作上对我的指导，同时也感谢补天的abu、yagami、eyas、sztwww、大鹰、大皮球和其他兄弟们跟我一起讨论隐藏进程的技术，让我学到了很多的东西。
