进程木马后门程序在winnt中进程隐藏和查找的方法

在WIN9X中只需要将进程注册为系统服务就能够从进程查看器中隐形可是这一切在W INNT中却完全不同无论木马从端口、启动文件上如何巧妙地隐藏自己始终都不能欺骗W INNT的任务管理器 以至于很多的朋友问我在W INNT下难道木马真的再也无法隐藏自己的进程了?本文试图通过探讨W INNT中木马的几种常用隐藏进程手段给大家揭示木马/后门程序在W INNT中进程隐藏的方法和查找的途径。

我们知道在WINDO WS系统下可执行文件主要是Exe和Com文件这两种文件在运行时都有一个共同点会生成一个独立的进程查找特定进程是我们发现木马的主要方法之一(无论手动还是防火墙)随着入侵检测软件的不断发展关联进程和S OCKET已经成为流行的技术(例如著名的FPort就能够检测出任何进程打开的TC P/UDP端口)假设一个木马在运行时被检测软件同时查出端口和进程我们基本上认为这个木马的隐藏已经完全失败(利用心理因

素而非技术手段欺骗用户的木马不在我们的讨论范围之内)。在NT下正常情况用户进程对于系统管理员来说都是可见的要想做到木马的进程隐藏有两个办法第一是让系统管理员看不见(或者视而不见)你的进程;第二是不使用进程。

看不见进程的方法就是进行进程欺骗为了了解如何能使进程看不见我们首先要了解怎样能看得见进程在Windows中有多种方法能够看到进程的存在 PSAPI(Process Status API)

PDH(Performance Data Helper) ToolHelp API如果我们能够欺骗用户或入侵检测软件用来查看进程的函数(例如截获相应的API调用替换返回的数据)我们就完全能实现进程隐藏但是一来我们并不知道用户/入侵检测软件使用的是什么方法来查看进程列表二来如果我们有权限和技术实现这样的欺骗我们就一定能使用其它的方法更容易的实现进程的隐藏。

第二种方法是不使用进程不使用进程使用什么?为了弄明白这个问题我们必须要先了解Wind o ws系统的另一种“可执行文件”----D LL DLL是Dynamic Link Library(动态链接库)的缩写DLL文件是Wind o ws的基础因为所有的AP I函数都是在DLL中实现的。DLL文件没有程序逻辑是由多个功能函数构成它并不能独立运行一般都是由进程加载并调用的。 (你你你你刚刚不是说不用进程了?)别急呀听我慢慢道来 因为DLL文件不能独立运行所以

在进程列表中并不会出现DLL假设我们编写了一个木马DLL并且通过别的进程来运行它那么无论是入侵检测软件还是进程列表中都只会出现那个进程而并不会出现木马DLL如果那个进程是可信进程 (例如资源管理器Exp lo rer.exe没人会怀疑它是木马吧?)那么我们编写的DLL作为那个进程的一部分也将成为被信赖的一员而为所欲为。

运行DLL文件最简单的方法是利用Rund ll 32.ex e

Rund ll/Rund ll32是W ind o ws自带的动态链接库工具可以用来在命令行下执行动态链接库中的某个函数其中Rund ll是16位而Rund ll 32是32位的(分别调用16位和32位的DLL文件) Rund ll 32的使用方法如下

Rundll32.exe DllF ileName FuncName

例如我们编写了一个MyDll.dll这个动态链接库中定义了一个MyFunc的函数那么我们通过Rundll32.exe MyDll.dll MyFunc就可以执行MyF unc函数的功能。

如何运行DLL文件和木马进程的隐藏有什么关系么?当然有了假设我们在MyF unc函数中实现了木马的功能那么我们不就可以通过Rund l l32来运行这个木马了么?在系统管理员看来进程列表

中增加的是Rund ll32.exe而并不是木马文件这样也算是木马的一种简易欺骗和自我保护方法(至少你不能去把Rund ll32.exe删掉吧?)

使用Rund ll 32的方法进行进程隐藏是简易的非常容易被识破。 (虽然杀起来会麻烦一点)比较高级的方法是使用特洛伊DLL特洛伊DLL的工作原理是替换常用的DLL文件将正常的调用转发给原DLL截获并处理特定的消息。例如我们知道WINDO WS的Soc ket

1.x的函数都是存放在wsock32.dll中的那么我们自己写一个ws oc k32.dll文件替换掉原先的wsoc k32.dll(将原先的DLL文件重命名为wsocko ld.dll)我们的ws ock32.dll只做两件事一是如果遇到不认识的调用就直接转发给ws oc ko ld.dll(使用函数转发器forward);二是遇到特殊的请求(事先约定的)就解码并处理。这样理论上只要木马编写者通过SOCKET远程输入一定的暗号就可以控制wsock32.dll(木马DLL)做任何操作。特洛伊DLL技术是比较古老的技术因此微软也对此做了相当的防范在Win2K的system32目录下有一个dllc ache的目录这个目录中存放着大量的DLL文件(也包括一些重要的exe文件)这个是微软用来保护DLL的法宝一旦操作系统发现被保护的DLL文件被篡改(数字签名技术)它就会自动从dllc ac he中恢复这个文件。虽然说先更改dllc ac he目录中的备份再修改DLL文件本身可以绕过这个保护但是可以想见的是微软在未来必将更加小心地保护重要的DLL文件 同时特洛伊DLL方法本身有着一些漏洞(例如

修复安装、安装补丁、检查数字签名等方法都有可能导致特洛伊DLL失效)所以这个方法也不能算是DLL木马的最优选择。

DLL木马的最高境界是动态嵌入技术动态嵌入技术指的是将自己的代码嵌入正在运行的进程中的技术。理论上来说在Wind o ws中的每个进程都有自己的私有内存空间别的进程是不允许对这个私有空间进行操作的(私人领地、请勿入内)但是实际上我们仍然可以利用种种方法进入并操作进程的私有内存。在多种动态嵌入技术中(窗口Hook、挂接API、远程线程)我最喜欢的是远程线程技术(其实、其实我就会这一种……)下面就为大家介绍一下远程线程技术。

远程线程技术指的是通过在另一个运行的进程中创建远程线程的方法进入那个线程的内存地址空间。我们知道在进程中可以通过C reateThread函数创建线程被创建的新线程与主线程(就是进程创建时被同时自动建立的那个线程)共享地址空间以及其他的资源。但是很少有人知道通过CreateRemo teThread也同样可以在另一个进程内创建新线程被创建的远程线程同样可以共享远程进程(注意是远程进程!)的地址空间所以实际上我们通过创建一个远程线程进入了远程进程的内存地址空间也就拥有了那个远程进程相当多的权限例如启动一个DLL木马(与进入进程内部相比启动一个DLL木马是小意思实际上我们可以随意篡改那个进程的数据)

闲话少说我们来看代码

首先我们通过Op enP roc es s来打开我们试图嵌入的进程(如果不允许打开那么嵌入就无法进行了这往往是由于权限不够引起的例如你试图打开一个受系统保护的进程)hRemoteProc ess=

Op enProc es s(PROCESS_CREATE_THREAD| //允许远程创建线程

PROC ES S_VM_OP ERAT ION| //允许远程VM操作

PROCESS_VM_WRITE, //允许远程VM写

FALS E,dwRemoteProc es sId);

由于我们后面需要写入远程进程的内存地址空间并建立远程线程所以需要申请足够的权限(PROCESS_CREATE_THREAD、VM_O P ERAT ION、VM_WRIT E)。

然后我们可以建立Lo adLib raryW这个线程来启动我们的DLL木马 Lo adLib raryW函数是在kerne l32.dll中定义的用来加载DLL文件它只有一个参数就是DLL文件的绝对路径名

p s zLib F ileName (也就是木马DLL的全路径文件名)但是由于木马DLL是在远程进程内调用的所以我们首先还需要将这个文件名复制到远程地址空间 (否则远程线程读不到这个参数)

//计算DLL路径名需要的内存空间int cb=(1+lstrlenW(p szLibFileName))*sizeof(WCHAR);

//使用Virtua lA llo c Ex函数在远程进程的内存地址空间分配DLL文件名缓冲区ps zLibF ileRemote=(PWSTR)

Virtu alAllo c Ex(hRe mo teP ro c es s,NULL,c b,

MEM_COMMIT,PAGE_READWRITE);

//使用WriteP ro c e s s Memo ry函数将DLL的路径名复制到远程进程的内存空间iReturnC o de=WritePro c ess Memory(hRemo tePro c ess,ps zLib F ileRemote, (P VO ID)ps zLib F ileName,cb,NULL);

//计算Lo ad Lib raryW的入口地址

PTHREAD_S TART_ROUTINE pfnStartAddr=

(P THREAD_START_ROUTINE)

G etP ro c Ad dres s(G etMo dule Hand le(T EXT("Kerne l32")),"Lo adLib raryW");

说明一下上面我们计算的其实是自己这个进程内

Lo adLibraryW的入口地址但是因为kerne l.dll模块在所有进程内的地址都是相同的(属于内核模块)所以这个入口地址同样适用于远程进程。

OK万事俱备我们通过建立远程线程时的地址p fnStartAddr(实际上就是Lo adLibraryW的入口地址)和传递的参数p s zLib F ileRemo te(我们复制到远程进程内存空间的木马DLL的全路径文件名)在远程进程内启动我们的木马DLL

//启动远程线程Lo adLib raryW通过远程线程调用用户的DLL文件

hRemo teThread=C reateRemo teThread(hRemo teP ro c e s s,//被嵌入的远程进程

NULL,0,p fnS tartAddr,//Lo adLibraryW的入口地址ps zLibF ileRemote, //木马DLL的全路径文件名

0,NULL);

至此远程嵌入顺利完成为了试验我们的DLL是不是已经正常的在远程线程运行我编写了以下的测试DLL这个DLL什么都不做仅仅返回所在进程的PID

BOOL APIENTRY DllMain(HANDLE hModule,DWORDreason,LPVOID lpRes erved)

{c har*s zPro c ess Id=(c har*)mallo c(10*s iz eo f(c har));switch(reas on){