一、检查系统帐户

这是一台windows server2003的服务器，IIS上建了两个网站。存放在 C:\www 文件夹下的web1和web2文件夹中。（出于安全考虑，文中所有具体信息比如路径、文件名、帐号、口令、IP、MAC等敏感信息有可能在不影响读者理解的前提下做稍许保护性改动）

对于这样一个个人网站来说，恢复其访问倒并不十分紧迫，相对而言，我们更需要先找到***者的痕迹。

用net user命令查看帐户信息，没有发现异常。administrators组没有被加入新的帐号。guest帐号没有异常。其他系统帐户也都正常。
可以判定***者并没有得到系统管理员权限。

防：第一步需要判断***者是否得到最高权限，一个得到系统管理员权限的高手，很可能把自己的踪迹清除的干干净净。而把不请自来者驱逐出境，也应是被***后第一紧迫的事情。

攻：想要做到挥一挥衣袖不带走一片云彩的境界，搞到admin是必须的，当然这可没说起来那么容易。

二、寻找突破口

既然***者没有得到最高权限，那么应该会留下不少痕迹，首先对网站所在文件夹进行查找文件的操作，修改时间定为2009-7-1至2009-7-12日之间。查找到了三个可疑文件。经过查看源码，发现是三个webshell。
分别是 aaa.asp bbb.asp ccc.asp

经过询问“站长X”，得知其中 bbb.asp 和 ccc.asp是他用来清除批量挂马时自己上传用的webshell。而aaa.asp则属于不明来历的文件。
这里可以确定这个aaa.asp是来自于***者。

防：一般来说，很多人上传webshell时都不会注意到自己上传文件的修改时间。利用这点，管理员可以很容易找到被变动过的文件。

攻：先在本地修改掉文件的时间信息，再进行上传，会给管理员搜寻***时造成很×××烦。

三、定位***者

找到了***者上传的webshell，就可以有的放矢的进行分析了。进入C:\WINDOWS\system32\LogFiles。这里是IIS的日志存放处。由于***者没有权限删除这里的日志，我们可以直接搜索所有文件，查找内容含有 “aaa.asp”的日志记录。
结果查到了一个日志文件：ex090711.log
里面的记录为：
2009-07-11 10:08:10 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 401 5 5

可以看出，在7月11日10点08分10秒的时候，一个操作系统为XP的用户使用IE6.0为内核的浏览器对服务器提交了一个GET操作。也就是访问这个asp***了。这个用户的IP为：122.224.222.69。我们无从得知对方是否用了代理或者跳板。只知道这个访问IP的ISP是于浙江省杭州市电信，姑且认为是ADSL拨号获取的动态IP吧。

防：IIS日志记录了所有用户的GET操作和参数，以及POST操作的页面日志，可以从这里寻找到***者的蛛丝马迹，当然前提是日志还在那儿 ：）至于IP地址的归属地，网上到处都是，如果你不反对，也可以到本F个人网站查询 http://www.fbi2000.com/sjcx/ipchaxun.html)

攻：有权限的话要清理日志，当然需要先停掉iis服务才可以清理，这就需要你有足够的权限。

四、顺藤摸瓜

现在我们有了***者的IP，而且还留有IIS日志。还等什么呢？
搜寻所有日志包含有“122.224.222.69”的记录。
发现只有ex090711.log中有来访记录。扩大搜索范围，搜索含有“122.224.”内容的日志（我们考虑到***者可能会是动态获取的IP），经过分析，其他同段的IP没有值得怀疑的操作。
现在我们具体看看这个122.224.222.69做过什么。
使用BLXlogView载入ex090711.log。保留字符串选择“122.224.222.69”，将.jpg/.gif/.css/.ico/.js等设置为过滤字符串。得到下面记录：

2009-07-11 09:52:40 W3SVC1972102721 59.175.179.181 GET /admin/soft/admin_collection.asp action=edit&ChannelID=2&ItemID=25 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 302 0 0
2009-07-11 09:52:42 W3SVC1972102721 59.175.179.181 GET /admin/showerr.asp action=error&Message=%3Cli%3E%C4%FA%C3%BB%D3%D0%BD%F8%C8%EB%B1%BE%D2%B3%C3%E6%B5%C4%C8%A8%CF%DE%21%B1%BE%B4%CE%B2%D9%D7%F7%D2%D1%B1%BB%BC%C7%C2%BC%21%3Cli%3E%BF%C9%C4%DC%C4%FA%BB%B9%C3%BB%D3%D0%B5%C7%C2%BD%BB%F2%D5%DF%B2%BB%BE%DF%D3%D0%CA%B9%D3%C3%B5%B1%C7%B0%B9%A6%C4%DC%B5%C4%C8%A8%CF%DE%21%C7%EB%C1%AA%CF%B5%B9%DC%C0%ED%D4%B1%2E%3Cli%3E%B1%BE%D2%B3%C3%E6%CE%AA%5B%3Cfont+color%3Dred%3E%B9%DC%C0%ED%D4%B1%3C%2Ffont%3E%5D%D7%A8%D3%C3%2C%C7%EB%CF%C8%3Ca+href%3Dadmin%5Flogin%2Easp+class%3Dshowmeun+target%3D%5Ftop%3E%B5%C7%C2%BD%3C%2Fa%3E%BA%F3%BD%F8%C8%EB%A1%A3 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:52:45 W3SVC1972102721 59.175.179.181 GET /admin/admin_login.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:14 W3SVC1972102721 59.175.179.181 GET /admin/admin_login.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:21 W3SVC1972102721 59.175.179.181 GET /common/getcode.asp t=0.7473073218337293 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:22 W3SVC1972102721 59.175.179.181 GET /common/ajaxcheck.asp rs=check_code&value=9103 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:23 W3SVC1972102721 59.175.179.181 POST /admin/admin_login.asp action=login 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 302 0 0
2009-07-11 09:55:23 W3SVC1972102721 59.175.179.181 GET /admin/admin_index.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:26 W3SVC1972102721 59.175.179.181 GET /admin/admin_left.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:26 W3SVC1972102721 59.175.179.181 GET /admin/admin_top.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 09:55:26 W3SVC1972102721 59.175.179.181 GET /admin/admin_main.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 10:08:10 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 401 5 5
2009-07-11 10:08:53 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 10:08:55 W3SVC1972102721 59.175.179.181 POST /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 10:09:00 W3SVC1972102721 59.175.179.181 POST /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 302 0 0
2009-07-11 10:09:00 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp - 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 10:09:00 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp Action=MainMenu 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0
2009-07-11 10:09:02 W3SVC1972102721 59.175.179.181 GET /common/aaa.asp Action=Show1File 80 - 122.224.222.69 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 200 0 0



简化后的日志如下：

1、09:52:40 GET /admin/soft/admin_collection.asp action=edit&ChannelID=2&ItemID=25
2、09:52:42 GET /admin/showerr.asp 3、action=error&Message=%3Cli%3E%C4%FA%C3%BB%D3%D0%BD%F8%C8%EB%B1%BE%D2%B3%C3%E6%B5%C4%C8%A8%CF%DE%21%B1%BE%B4%CE%B2%D9%D7%F7%D2%D1%B1%BB%BC%C7%C2%BC%21%3Cli%3E%BF%C9%C4%DC%C4%FA%BB%B9%C3%BB%D3%D0%B5%C7%C2%BD%BB%F2%D5%DF%B2%BB%BE%DF%D3%D0%CA%B9%D3%C3%B5%B1%C7%B0%B9%A6%C4%DC%B5%C4%C8%A8%CF%DE%21%C7%EB%C1%AA%CF%B5%B9%DC%C0%ED%D4%B1%2E%3Cli%3E%B1%BE%D2%B3%C3%E6%CE%AA%5B%3Cfont+color%3Dred%3E%B9%DC%C0%ED%D4%B1%3C%2Ffont%3E%5D%D7%A8%D3%C3%2C%C7%EB%CF%C8%3Ca+href%3Dadmin%5Flogin%2Easp+class%3Dshowmeun+target%3D%5Ftop%3E%B5%C7%C2%BD%3C%2Fa%3E%BA%F3%BD%F8%C8%EB%A1%A3
4、09:52:45 GET /admin/admin_login.asp
5、09:55:14 GET /admin/admin_login.asp
6、09:55:21 GET /common/getcode.asp t=0.7473073218337293
7、09:55:22 GET /common/ajaxcheck.asp rs=check_code&value=9103
8、09:55:23 POST /admin/admin_login.asp action=login
9、09:55:23 GET /admin/admin_index.asp
10、09:55:26 GET /admin/admin_left.asp
11、09:55:26 GET /admin/admin_top.asp
12、09:55:26 GET /admin/admin_main.asp
13、10:08:10 GET /common/aaa.asp
14、10:08:53 GET /common/aaa.asp
15、10:08:55 POST /common/aaa.asp
16、10:09:00 POST /common/aaa.asp
17、10:09:00 GET /common/aaa.asp
18、10:09:00 GET /common/aaa.asp Action=MainMenu
19、10:09:02 GET /common/aaa.asp Action=Show1File

可以看出***者首先访问的是后台的一个功能页面admin_collection.asp（时间为09:52:40）。2秒钟后（09:52:42）服务器脚本经过权限分析自动跳转到错误提示页面。通过行为模拟，发现提示为“可能您还没有登陆或者不具有使用当前功能的权限!请联系管理员.”等信息。3秒钟后（09:52:45）***者点击了错误提示页面中的“登陆”连接，进入了后台管理登陆页面，但并没有尝试登陆。

两分半钟后（09:55:14），***者再次打开了管理登陆页面，并且准备登陆，因为他在7秒钟后（09:55:21）点击了“点击获取验证码”连接（这7秒钟他应该是在输入登陆帐号与口令），我们从日志中看到，从5－12，就是一个标准的登陆后台管理的过程。***者毫不费力进入了后台管理，可以判定***者早已经拥有了管理员的合法帐号和登陆口令。

十几分钟后，***者访问了他的webshell。并且做了两次post操作。可以看出他输了两次密码才登陆了***（打错了口令？），接着打开了某个页面查看了源码。很奇怪的是***者没有继续做其他操作。

经过询问得知“站长X”在前段时间为了释放硬盘空间，删除过IIS日志。这解释了为什么在日志中查不到这个webshell当初是如何被放入网站内的，如此一来，我们无法方便的重现被***的经过，分析漏洞所在了。残念啊！！

根据***者登陆过网站后台，网站的后台应该有日志系统，如果运气好的话，可能也能找到一些蛛丝马迹（假设***者没有擦脚印的意识）。。。。可是现实是残酷的，“站长X”说网站是免费版，根本没有日志的功能。我打开数据库一看，果然连日志数据表都不存在。汗。。。

经过上面的分析，只好暂时得出结论，网站虽然被***过，但是这个***行为至少在半个月之前，因为现在最早保存的IIS日志是6月29日的。显然这个***者并不一定需要对这次挂马事件负责。

防：日志的分析非常重要，完整的日志可以用来重现***情景。对服务器的安全风险评估有着重要作用。网站后台的系统日志也很有用。在***者没有得到webshell之前，想清掉自己的痕迹还是不那么容易的。所以没事别删日志，就是要删，也先备份到本地再说。

攻：还是那句话，擦去脚印可以让你悄无声息，不能指望每个管理员都会好心帮你删掉日志。：）

五、恢复网站

既然没有更多线索，就先恢复网站的正常服务吧。“站长X”说他已经用利用自己上传的webshell批量清除过挂马语句。那么，我只需要找到网站无法正常访问的原因并排除就可以了。在查看了IIS的设置与硬盘的NTFS权限设置后，找到了网站无法服务的原因。因为两个虚拟主机文件夹（web1/web2）是同处一个父文件夹(www)下，虽然两个网站文件夹的NTFS设置了相应的匿名访问帐号(web1:webguest1/web2:webguest2)的读取权限。但是父文件夹www却只有administrator和system两个帐户可以访问。将www的读取及运行权限开放给webguest1和webguest2两个匿名访问帐号。然后分别将web1和web2的权限重新分配一下。让webguest1和webguest2不能相互访问对方的虚拟主机目录。以限制webshell的访问能力。

经过处理，网站服务成功恢复。

防：对每个虚拟主机设定不同的匿名访问帐户，是隔离webshell的重要方法。但是要注意父路径的权限设置。保持可用性前提下的权限最小化，是权限设置的精髓。

攻：没什么好说的，利用漏洞提权呗，如果运气好，webshell的权限就会让你在几个站点间穿梭观赏，如果运气非常好，你不但可以浏览你想看的一切，可能还可以直接改写很多配置文件，比如serv_u的ini。如果你走了超级狗屎运，扔批处理或脚本丢管理员的启动组里也不是没可能。好了，醒醒！醒醒！该起床咯。

六、安全设置

由于短时间内无法知道具体是因为什么漏洞而被***，先做一些安全设置加强安全性。

1、将所有数据库文件移到www外，另外新建一个db文件夹。db允许webguest1和webguest2读取。查看网站内的conn.asp文件。将数据库文件移动到db文件夹下。针对每个数据库文件设置相应的NTFS权限。修改相应的conn.asp文件，使用绝对路径连接数据库。将后台管理文件夹改名。

2、由于数据库文件已经不在web1或者web2中。所以直接将这两个网站文件夹的NTFS写入权限完全剥去。杜绝了因为脚本漏洞而生成webshell的可能性。

3、将serv-u FTP的启动帐号降权，从system降到一个身处guests组的帐号。只需要将这个帐号拥有serv-u配置文件的写权限就可以了，如果你无需图形界面管理，那么只给它一个读权限也是一个好选择。

4、删除所有没用的ISAPI映射。只留下.asp。

防：数据库移到网站文件夹外，只能阻挡暴库者的直接下载。修改后台管理的路径，减少被***的几率。尽可能的降低网站访问匿名帐号的权限，能不给写就不给写。如果实在有需要上传的路径，比如上传图片的目录，则一定要拿掉该目录的执行许可。任何服务的启动帐号，也是权限越小越好。只要设置得当，guests 组是它们的最好归宿。应用程序映射也别舍不得删，用不到的坚决删掉，不留给漏洞利用者任何机会。

攻：下载数据库分析表结构，数据内容，运气好还可能得到帐号口令。serv-u提权、利用ISAPI扩展的远程溢出获取shell都是老生常谈了。

七、峰回路转

正当我做完这一切，准备休息时，随手浏览了一下“站长X”的网站，居然发现又被挂马了！从服务器端查看页面源码却没有***语句的踪迹。第一个反应是被挂了IIS马。但是立即否定了这个推断。因为IIS挂马不会时有时无。那可是连404错误页面都会被挂上***代码的。所以我判定应该是被arp挂马。
运行 ipconfig -all 找到服务器的网关地址：61.175.179.161。运行arp -a 发现果然有另一台机器 61.175.179.168 的MAC地址与之相同。很明显，是61.175.179.168在对服务器进行ARP欺骗，服务器的所有跨网段通讯都流经了61.175.179.168进行中转。而61.175.179.168可以在http协议的通讯过程中进行挂马操作。这就是挂马语句时有时无的原因。

首先通知了“站长X”，让他与ISP交涉，至于61.175.179.168是被恶意***植毒，还是所有者本身即为幕后黑手，都很难说。但是我们不能一直这样等着，趁着一次arp***波的过去，立即刷新得到真实的网关MAC：00-0f-e2-8d-11-85。使用arp -s 61.175.179.161 00-0f-e2-8d-11-85 命令进行静态绑定，阻挡住了来自外界的ARP欺骗。但是当系统重启后这个绑定命令就会失效。为了永久性的解决问题。我在服务器上运行了我写的小工具：BLX ARP防火墙。它的优点是每次重启后自动进行静态绑定网关MAC的操作后退出程序释放内存。（下载地址http://www.fbi2000.com/sjcx/arp.html）

既然确定了是ARP***，那么就要提防很多敏感信息已经被嗅探的危险。通知“站长X”修改掉后台口令等信息。考虑到一些嗅探软件专门瞄准password等敏感数据。我修改了登陆页面中提交的postid。这样可以让一些嗅探软件瞎掉。

防：如果在被挂马以后，发现在源代码中找不到挂马痕迹，就需要考虑IIS挂马和ARP挂马两种可能了。两者的区别就是ARP挂马是页面一会儿正常一会儿又被挂上***代码。IIS挂马则是无论什么时候访问什么页面都会看到挂马语句在返回的页面中（包括IIS返回的错误提示页面）。IIS挂马可以在IIS的设置中找到痕迹，在“文档”设置页中，有个“启用文档页脚”的设定。若被莫名其妙的启用，你会发现挂马代码就在这个自定义的页脚文件中。你也可以在C:\windows\system32\inetsrv\MetaBase.xml中找到DefaultDocFooter项，（IIS的很多设置就保存在这个xml文件中），删除掉这个选项即可。ARP挂马则无需多做其他设置，消除掉被ARP欺骗的影响即可。修改登陆提交的postid，可以躲过一些针对关键词的嗅探工具。

攻：IIS挂马需要对C:\windows\system32\inetsrv\MetaBase.xml有写权限，加入DefaultDocFooter="FILE:C:\www\mm.htm"就可以启到挂马效果。而ARP欺骗***则用途多多，不但可以挂马，还可以sniff到很多有用的信息。但注意一些傻瓜型嗅探软件虽然功能很强大，但由于是基于关键词，所以也容易被蒙蔽。如果***的是重要目标，对截获的通信数据进行人工分析还是有必要的。

八：结论

运行过BLXARPFW后，网站已经变得正常，没有再被挂马所困扰。可见，其实这次挂马***就源自于被ARP欺骗。并非由于被***的结果。“站长X”以为是被***，在做权限设置时又宁可错杀一千，结果出了差错。才导致了网站的瘫痪。

最后回到那个被牵连查出来的asp*** aaa.asp。将其删除后，丢一个假的aaa.asp用来记录来访者的信息。因为没有完整的IIS日志，无法得知这个aaa.asp的主人当初是用什么手段达到侵入的目的。是因为另一次的arp欺骗后的嗅探得到了后台管理员口令和管理路径？还是利用了其他的脚本漏洞？因为实在是懒得去分析那些乱七八糟的源码（本F的眼睛还没痊愈呢），看来目前只能是个未知的迷了。