事件概况

最近应急，遇到一起官网非法链接事件。如下图所示，使用百度搜索引擎语法site:www.网站域名 搜索某关键字，会出现一堆结果。并且只有百度搜索引擎可以搜索出来，其他的都没有记录。

挨个点开，都是404，最近的一条是8.15的。

到现场后，先建议工作人员分批进行用户反馈，期望百度能够尽快删除搜索结果，将负面影响降低到最小，之后着手应急。

既然是挂链接，又是404，说明在百度爬虫收录之后，链接原文已经被删除。作案者相当谨慎，估计是下次接到活儿还想如法炮制。现场资产情况是：

• Windows Server 2016

• IIS 10

• Microsoft Sql Server 2008

• WAF

排查角度有两个，一是服务器被入侵了，这是最糟糕的结果，二是网站本身存在漏洞，作案者直接操作网站后台发的文。

上机排查

登录服务器，看到桌面还算整洁，与运维人员核实，安装的软件也都正常。查看服务器上仅有的安全防护措施——卡巴斯基，未发现活动威胁，情况还算可以。

翻看卡巴斯基防护日志，并没有异常行为告警，只有一条漏洞利用防御的记录，还是告警的D盾。

将D盾拿上服务器，逐一翻看一遍，并没有发现异常，IIS模块都是正常运行。

排查到这里基本可以排除服务器被入侵的可能了。然后，有效的安全设备仅有一台WAF，登录上去看看与该网站相关的日志。

看到很多发文异常的告警，但仅仅是告警，没有阻断，估计是不允许影响业务。

从这条告警来猜测，网站有可能存在编辑器漏洞，kindeditor。但也就这些告警，没有参考价值，因为响应结果记录为空。

既然没有入侵服务器，没有植入马儿，那就还是通过网站操作来发布的文章。所以下面的排查思路是跟踪文章的发布和删除时间，以及发布者账号、登录IP等等。

联系软件开发公司的人，询问文章删除逻辑：

顿时感觉这套系统开发的好随意，文章说删就删了，真的删了，没有给追踪溯源留下一丝余地。接下来怎么办？看看web日志吧。

web日志

web日志分为两种，一种以ex开头，记录的是爬虫行为，文件普遍偏小，另一种以nc开头，记录的是网站的访问日志，文件普遍偏大。

根据“Baiduspider”关键字搜索百度爬虫的时间。

302太多，只需要200的，并且加上大概的时间范围：

记录还是太多。询问开发人员有没有url白名单，不出所料，回复依然是“不知道”。如此一来，从百度收录时间入手排查的思路就断了。然后怎么办？看看访问日志吧，根据访问数量筛选一下。

果然，有一个IP的访问数量特别多，针对这个IP筛选一下。

访问时间大多在凌晨一两点，且url多数和kindeditor有关，着实可疑。然后根据这个IP查一下登录账号：

只有寥寥几条，应该是只供页面展示用，而且不支持下一页查询。既然开发不给力，那就只有自己登录数据库查询了。

Database

登录之后翻看表空间，首先看到一张User表，本能地打开。看到loginPwd列，自然是存储的密码，不过，再仔细瞧瞧这些记录，16位的MD5啊！

继续翻看发现，怎么有几个相同的MD5值？难不成是初始密码还没改。

把这几个相同的MD5拿出来解密一下：

解出来了，又是一个MD5，再次解密：

出来了，弱口令，111。用户密码的加密规则是两次MD5处理。以这个密码为查询条件筛选一下用户，好家伙，总共6个人都是用的这个密码。

在其中随便找个账号查询其近两个月的登录记录：

果然，8.11登录过，而且是外省地址。回看百度爬虫收录时间是8.15，从发文到被爬取用了4天时间，符合爬虫效率。

之后再去除源地址转换、出口IP地址、IPv6地址，筛选所有弱口令账号近三月的登录日志，共53条。

经分析发现其中一个账号存在多地点多IP登录的情况，且登录IP中有多个为恶意IP，下图是其一。

用其账号登录网站后台管理系统，瞬间一目了然：

账号权限包括发布文章、修改文章、删除文章......一应俱全。

总结两点

• 说一千道一万的是弱口令，屡禁不止的是弱口令，明知故犯的还是弱口令。

• 应急是个综合性很强的活儿，有时候不需要多么高超的技术，像这次，我就当了一把系统运维和数据库运维。