1、先查看本机日志，没什么可疑的系统用户，管理登陆等信息。（入侵者一般不会给你留下有用的日志的）
2、NETSTAT，看看端口的情况，也是一切正常。
3、再检查开启的服务，看到朋友的IPSEC安全策略是启动的，而且朋友有一定的计算机知识，也配置了IP安全策略。再往下看，朋友的Remote Access Auto Connection Manager和Remote Access Connection Manager两项服务已经启动。我们都知道，此服务是当某个程序引用一个远程DNS或NETBIOS名或者地址的时候建立远程网络连接用的，但是此服务开启也很正常，没有可以利用的端口是无法连接的，朋友的135，137，138，139，445端口是关闭的。
4、检查IPC$，朋友的IPC$是开启的，危险，但是又想到防火墙和IP安全策略，能连接的可能性几乎为零。
作为一台个人使用PC来说，朋友的安全性是不错的，正准备往下查的时候，看到一台NB摆在旁边，朋友说公司的NB，拿回来COPY资料。我看了下NB，因为配置问题装的98，于是想起98和XP互连，朋友估计装了NETBEUI协议的，于是继续检查。
装了NETBIOS协议，并没有NETBEUI，但是朋友说曾经装过，但是卸了。
NETBEUI协议其实是NETBIOS的本地延伸，用于不同的计算机网络互通的， 但是我记得NETBEUI协议的卸载不是那么简单从协议组中就卸了的，于是发现了点问题的可疑点。
再次检查日志，发现了可疑点：
Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 3/26/2005
Time: 9:54:24 AM
User: N/A
Computer: KK
Description:
The NetBEUI Protocol service failed to start due to the following error:
The system cannot find the file specified.
原来协议还在系统中，这是启动失败信息。
于是马上检查注册表：
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNbf
看到了NETBEUI的信息，原来系统中的NETBEUI并未被删除
我们知道，系统的口令进行校验时是以发送的长度数据为依据的。在发送口令认证数据包时可以设置长度域为“1”，同时发送一个字节的明文口令，校验程序会将发来口令与保存的口令的第一个字节进行明文比较，如果匹配就认为通过了验证。特别是作为NETBIOS协议来说，漏洞是很大的。
再看朋友的Internet连接，TCP/IP上的NETBIOS没有禁用这个时候可以来查找问题的根源了。
扫描软件？其实不用，利用系统的端口监听，就可以完成。端口监听过程中，发现端口7777正在被监听（因为时间有点长，在整理东西时候朋友喊的，忘记了抓图），这个有点异常，所以马上看进程，但是却没有异常，感到越来越奇怪了。
于是用TCPDUMP抓包，看到tcpdump: listening on 7777，果然端口被占用了。看来是后台进程。于是使用TCP Connect()扫描，因为端口处于侦听状态，所以Connect()就能成功。这时出现了大量的错误信息，不一会，系统的LOGS文件显示一连串的连接出错消息，然后关闭了服务。（以非线性方式连接）这时，本打算继续扫描TCP SYN和TCP FIN都不需要了。
于是返回注册表，把NETBEUI协议的信息删除，REBOOT，在连接，一切正常。
回过头来看事情的正个经过，其实都缘于朋友装卸NETBEUI协议的不正确和大意，导致了NETBEUI协议和NETBIOS协议在使用中发生冲突。原来朋友的爱机曾经中过YAI蠕虫病毒，虽然杀毒成功，但是滞留在系统的错误设置却没有改变过来。
TCP 7777=NetSpy(YAI)，病毒利用了系统的7777端口，那时NETBEUI在启用中，虽然协议从协议组中消失了，但是注册表和配置信息却还在，所以导致有TCP数据连接时，系统又自然而然的开启了7777端口来找寻NETBEUI协议的数据流，因此产生了错误的日志。
就这样，朋友的问题也解决了，“入侵者”的担心也烟消云散，原来是这小小协议在捣鬼，呵呵，还让我们为这个“入侵者”搞得晕头转向。