网管经验谈：内网病毒缉拿记

四，高级检测——确定目标：

平时这个分支机构的计算机都是由笔者和几个同伴一起负责维护，按照常理来说安全防范级别应该比较高，系统自动更新补丁都随时安装，杀毒软件也使用的是卡巴斯基，那么为什么还会在本机出现故障呢？笔者再次检测发现出问题的几台计算机的卡巴斯基并没有升级到最新病毒库，于是手工升级，并在安全模式下全面查杀本地硬盘各个分区，确保无毒后再次访问办公系统，结果令人遗憾的是故障依旧。不过每当访问这两个服务器应用服务时卡巴斯基都给出了发现危机的提示——malcious http object :access denied。这说明在访问服务器时页面要求自动跳转到http://ck1.in/n.js这个地址，而该地址被卡巴斯基过滤禁止访问了。笔者测试了所有出问题的机器都在访问服务器时卡巴斯基给出警报提示。（如图2）

图2

由于之前已经确定了服务器自身没有问题，所以排除了服务器上存在木马或被篡改添加恶意脚本的可能，因此我们确定了目标，主要问题是病毒带来的，该病毒被卡巴斯基命名为trojan program trojan-downloader.js.agent.lg，是一种木马病毒。笔者在故障机上直接访问http://ck1.in/n.js这个地址出现了该地址被杀毒软件屏蔽的提示，看来该地址是万恶之源。（如图3）

图3

五，解决问题——Sniffer出山找源头

虽然确定了本次网络故障是由病毒引起，但是笔者一直有一个疑惑，那就是各个机器的安全级别都很高，平时都是由我们专业人员负责维护，自动打各种漏洞补丁的，那么为什么还会有这么多的计算机感染了该木马病毒呢？另外我们也针对这些故障机器进行了查杀病毒操作，卡巴斯基并没有找到对应的染毒文件。种种迹象都表明病毒未必都在这些故障机器的系统中。

这时有一个念头出现在笔者的脑海中，记得以前曾经应对和解决过ARP欺骗病毒，只要网络中有一台机器感染了ARP病毒，那么几乎这个网段的所有机器都无法上网或者访问网络时断时续。那么这次的木马trojan program trojan-downloader.js.agent.lg病毒的感染与攻击机理是否相同呢？为了证实此想法笔者拿出了看家工具——sniffer来扫描整个网段，看看是否有机器在发送或接收可疑数据包。

安装Sniffer针对出问题的网段进行扫描，笔者发现MAC地址为000BDBC2F6C5的机器频繁发送广播数据包，数量比较大。（如图4）

图4

将MAC地址切换到IP信息后笔者发现这台可疑机器的IP地址为10.82.4.89，另外从扫描的图表中我们看到了10.82.4.89这台计算机不光频繁发送广播包，还发送了基于239.255.255.250地址的组播包，这在我们平时各种服务和应用中更是少见，这点增加了他的可疑性。（如图5）

图5

为了确定笔者的想法本人通过sniffer只针对该一台机器进行扫描，并且在扫描的同时通过网络来访问之前出现问题的两台服务器应用，结果发现只要笔者在浏览器中输入地址访问办公邮件系统或信息平台，回车后10.82.4.89这台机器就马上发送数据到239.255.255.250地址，进行组播数据传输。看来这台机器是罪魁祸首的可能性已经超过百分之八十。（如图6）

图6

小提示：

通过主机扫描笔者发现该机器名为dellesp，地址是10.82.4.89，MAC信息是000BDBC2F6C5。可惜该分支机构DELL机器有几十台，由于平时没有按照科室的序号对计算机命令，所以无法从dellesp信息来定位故障来源。这点需要引起重视，应该在以后的维护中将各个员工机按照一定的顺序命令和归纳。