最近,在论坛看帖子时发现:中毒后,杀而不净的现象比较普遍。更有甚者,毒没杀净,杀软反而被干掉了。其实,这也不是什么新鲜事,针对各有名杀软的病毒早就有。卡巴斯基这样的名杀软被病毒干掉也不是什么新鲜事。
不废话了。言归正传。
中毒后,杀不净,常见的原因之一是病毒插入了系统/应用程序进程。
不将被插进程中的病毒模块处理掉,毒是杀不净的。
如何发现进程被插?常见的方法是:在中招的电脑上扫SRENG日志。SRENG日志的“正在运行的进程”部分可找到进程被插信息(阅读这部分日志判断进程中的病毒木块————需要经验)。当然,你也可以用IceSword一一检视进程列表中各进程的“模块信息”(比较累)。
按照手工杀毒时的不同处理方式,被插进程大致可分为以下几类:
1、系统核心进程。系统核心进程不能结束。否则,系统崩溃。
下面是阅读论坛中求助帖时,在SRENG日志见到的一个具体例子:
正在运行的进程
[PID: 668][\??\C:\WINDOWS\system32\csrss.exe] [Microsoft Corporation, 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)]
[C:\WINDOWS\system32\E5CEBDF.DLL] [Microsoft Corporation, ]
正在运行的进程
[PID: 668][\??\C:\WINDOWS\system32\csrss.exe] [Microsoft Corporation, 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)]
[C:\WINDOWS\system32\E5CEBDF.DLL] [Microsoft Corporation, ]
这段日志提示:系统核心进程C:\WINDOWS\system32\csrss.exe被病毒模块插入了。插入此进程的病毒模块是C:\WINDOWS\system32\E5CEBDF.DLL。
如果不采取相应措施卸掉csrss.exe进程中的E5CEBDF.DLL,病毒文件C:\WINDOWS\system32\E5CEBDF.DLL无法删除。
除了csrss.exe以外,属于系统核心进程的还有:
SystemRoot\System32\smss.exe
SystemRoot\System32\winlogon.exe
SystemRoot\System32\lsass.exe
SystemRoot\System32\services.exe
SystemRoot\System32\svchost.exe
处理这些进程中的病毒模块,我尝试过:
(1)用IceSword禁止进程创建,然后,强制卸除之。有时可以成功卸除,有时卸除失败(系统崩溃,重启)。
(2)如果(1)失败。可以尝试“禁止进程创建”后,强制删除病毒模块文件,有时也可达到目的(如木马Keygen.exe的处理)。
(3)如果(1)、(2)均失败,可以尝试用SSM解决问题:将病毒模块录入SSM的规则中,禁止病毒模块加载。将SSM设置为“启动加载”。然后,重启系统。
(4)将病毒模块录入Tiny的黑名单。重启系统。
(5)在安全模式下尝试删除病毒模块(成功率并非100%)。需要注意的是:有些病毒感染后,用户根本无法进入安全模式。这时,就别想这招了。没用。
如果不采取相应措施卸掉csrss.exe进程中的E5CEBDF.DLL,病毒文件C:\WINDOWS\system32\E5CEBDF.DLL无法删除。
除了csrss.exe以外,属于系统核心进程的还有:
SystemRoot\System32\smss.exe
SystemRoot\System32\winlogon.exe
SystemRoot\System32\lsass.exe
SystemRoot\System32\services.exe
SystemRoot\System32\svchost.exe
处理这些进程中的病毒模块,我尝试过:
(1)用IceSword禁止进程创建,然后,强制卸除之。有时可以成功卸除,有时卸除失败(系统崩溃,重启)。
(2)如果(1)失败。可以尝试“禁止进程创建”后,强制删除病毒模块文件,有时也可达到目的(如木马Keygen.exe的处理)。
(3)如果(1)、(2)均失败,可以尝试用SSM解决问题:将病毒模块录入SSM的规则中,禁止病毒模块加载。将SSM设置为“启动加载”。然后,重启系统。
(4)将病毒模块录入Tiny的黑名单。重启系统。
(5)在安全模式下尝试删除病毒模块(成功率并非100%)。需要注意的是:有些病毒感染后,用户根本无法进入安全模式。这时,就别想这招了。没用。
总之,中招者必须想办法将这些系统核心进程处理干净。否则,病毒杀不净。
2、explorer.exe(资源管理器)进程。这种进程插入比较常见。
explorer.exe进程可以结束(不会导致系统崩溃)。但是,用户若结束了explorer.exe进程,那他就只能对着一个空荡荡的桌面发呆了。
插入了explorer.exe进程的病毒模块,用IceSword禁止进程创建后,一般可以顺利卸除。
explorer.exe进程可以结束(不会导致系统崩溃)。但是,用户若结束了explorer.exe进程,那他就只能对着一个空荡荡的桌面发呆了。
插入了explorer.exe进程的病毒模块,用IceSword禁止进程创建后,一般可以顺利卸除。
3、一般应用程序进程。
这种情形最容易处理。用IceSword禁止进程创建,然后,找到相应进程,结束之。
这种情形最容易处理。用IceSword禁止进程创建,然后,找到相应进程,结束之。
4、比较“掉轨”的情形:
用IceSword,预先设置了禁止进程创。然后,根据SRENG日志提供的信息,所有被插进程都处理干净了,但病毒文件依然无法删除!
导致这种情形的原因常被忽视: 您遇到了“动态插入”(即:中毒后,用户运行哪个程序,病毒模块随即插入其进程中)。很可能是————您运行IceSword时,病毒插入了IceSword进程。这时,应检查IceSword进程的“模块信息”,找到其中的病毒模块,强制卸除之。
用IceSword,预先设置了禁止进程创。然后,根据SRENG日志提供的信息,所有被插进程都处理干净了,但病毒文件依然无法删除!
导致这种情形的原因常被忽视: 您遇到了“动态插入”(即:中毒后,用户运行哪个程序,病毒模块随即插入其进程中)。很可能是————您运行IceSword时,病毒插入了IceSword进程。这时,应检查IceSword进程的“模块信息”,找到其中的病毒模块,强制卸除之。
将所有被插进程处理干净后,即可开始删除病毒文件。
注意:如果前面用IceSword处理进程时一切顺利,删除病毒文件时,请不要更换工具,继续用IceSword操作。
删净病毒文件后,还要删除病毒添加的注册表项(根据SRENG日志)。
当然,您愿意先删除病毒添加的注册表项,然后再删除病毒文件,也是可以的。这只是个操作顺序问题。用IceSword禁止进程创建并处理干净所有进程后,这种不同的操作顺序————没有什么本质区别。
注意:如果前面用IceSword处理进程时一切顺利,删除病毒文件时,请不要更换工具,继续用IceSword操作。
删净病毒文件后,还要删除病毒添加的注册表项(根据SRENG日志)。
当然,您愿意先删除病毒添加的注册表项,然后再删除病毒文件,也是可以的。这只是个操作顺序问题。用IceSword禁止进程创建并处理干净所有进程后,这种不同的操作顺序————没有什么本质区别。
总之,进程插入问题,是导致病毒屡杀不净的常见原因。手工杀毒时,需重视这个问题,并根据实际情况,灵活采取相应的措施。
此贴于2007-4-3 10:16:23被baohe修改
发贴时间:2007-4-3 10:25:12
发贴时间:2007-4-3 10:25:12
部分回复:
1、辨认系统进程中病毒模块问题:凭经验。正常系统中C:\WINDOWS\system32\文件夹中没有E5CEBDF.DLL这个文件(这个回答可能让你失望)。
2、用IceSword强制邪除系统进程中的病毒模块,实质是“结束病毒模块的运行状态”(运行的文件是无法删除的)。
3、不结束病毒模块的运行状态而强制删除病毒模块文件的例子较少(这样做,要辅以特殊措施),据我的经验,也只有IceSword可以实现这种操作(尽管成功率不是100%)。那个Keygen.exe木马的处理就是个例子。强制删除病毒文件后,待硬盘无读写动作时,立即断开系统电源,即可奏效。这算个特例吧。
尽管是特例,但也是实践证明成功的例子,必要时可以考虑这样的方法。总之,手工杀毒讲究的是“灵活”,不必拘泥于什么“成规”。有时,就是要打破成规。
1、辨认系统进程中病毒模块问题:凭经验。正常系统中C:\WINDOWS\system32\文件夹中没有E5CEBDF.DLL这个文件(这个回答可能让你失望)。
2、用IceSword强制邪除系统进程中的病毒模块,实质是“结束病毒模块的运行状态”(运行的文件是无法删除的)。
3、不结束病毒模块的运行状态而强制删除病毒模块文件的例子较少(这样做,要辅以特殊措施),据我的经验,也只有IceSword可以实现这种操作(尽管成功率不是100%)。那个Keygen.exe木马的处理就是个例子。强制删除病毒文件后,待硬盘无读写动作时,立即断开系统电源,即可奏效。这算个特例吧。
尽管是特例,但也是实践证明成功的例子,必要时可以考虑这样的方法。总之,手工杀毒讲究的是“灵活”,不必拘泥于什么“成规”。有时,就是要打破成规。
转载自卡卡论坛病毒版baohe大虾的大作
本文转自starger51CTO博客,原文链接: http://blog.51cto.com/starger/22559,如需转载请自行联系原作者