SRENG不是万能的！由某款木马服务项目在SReng扫描日志中被忽略的事例谈起
原帖地址http://bbs.janmeng.com/viewthread.php?tid=888017&extra=page%3D1
1.过SReng的服务项目，文件验证扫描。该项目在SReng扫描日志中是不显示的。
2.该木马是一个捆绑形式的，但是从捆绑文件的资源目录中是看不出来的，使用PE格式分析，也是看不到附加数据，例如从MZ 和PE标志搜索全文是看不出来。某种程度类似于一个压缩安装程序。
3.病毒是采用VBS下载木马病毒运行的。本身只是启动释放VBS脚本，并使之运行之。
病毒木马为什么可以逃避SReng的文件验证检测呢？
首先我们看下该木马的服务启动项目：
该项目的状态有几点可疑，此木马只不过是替换了系统原来的服务项目Task Scheduler中的ImagePath的键值。那么为什么SReng的文件检测为什么会认为是正常呢？有观点认为SReng对于服务项目有动态链接库的，只对动态链接库文件进行检测，而病毒并没有修改后面的值，也没有修改后面的动态链接库的文件，所以只要后面不改，文件正常的话，SReng是认为该项目是正常的。真的是这样吗？我们先看下正常的该服务项目：
从项目中我们至于发现几处疑点：
1、服务状态：正常的应该是Running / Auto Start 而修改之后变成：Stopped / Auto Start
2、一般映像文件的路径只有一个文件，后面可能包含它启动需要的参数,如：%SystemRoot%\System32\svchost.exe -k netsvcs 而木马修改之后是：C:\WINDOWS\system32\shed.exe schedule.dll,netsvcs 包含了两个文件C:\WINDOWS\system32\shed.exe和 schedule.dll。
那么真的是只检测后面的吗？我修改了下注册表服务项目的键值，如图：
用SReng扫描下检测出来了，如图：
那说明SReng也对于前面的映像文件路径和服务动态链接库两个值是都检测的。那木马的值为什么没有检测呢？问题肯定出现在值上面？首先看下面这幅图：
我将系统目录中的rundll32.exe和病毒木马项目中的shed.exe文件进行对比发现，两个文件是同一个文件。既然是同一文件那么shed.exe当然可以通过验证。关键是服务映像路径中还包括schedule.dll，这个文件根本没有能通过Sreng的认证，我用SReng作者的签名认证插件进行认证，如图：
那为什么SReng没有显示呢？我又做了如下的修改。SReng是可以检测出来的，如图：
那么再这样修改：
SReng同样也不显示，有人可能认为：哦，原来SReng只判断空格符号前面的啊!后面的是不判断的。其实只说对了一半：我这样修改下，我新建了这样的文件夹explorer.exe schedule.dll，并把木马文件schedule.dll放到这个目录下：
这样看下SReng扫描结果：
看，是可以识别的。那么SReng是如何检测的呢？细心我们会发现如果空格后面没有路径标示的“\”的话，SReng会将后面的schedule.dll,netsvcs认为是一个命令参数。所以给直接忽略了，只对于C:\WINDOWS\system32\shed.exe进行检测，而shed.exe只是正常的rundll32.exe文件，因此验证当然是通过的。
文章如有不足，敬请谅解！
至此大家应该清楚该木马为什么能逃过SReng的检测了吧！关于该木马如何清理，其实并不难。请大家关注下讲的“木马清理与专杀编写”相关介绍。
用户系统信息：Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
