记一次诡异的网站篡改应急响应，结尾总结整改建议

概述

2021年1月6日下午的16点左右，本来还要在摸两个点的鱼就可以飞法法的下班了，照例下班前把安全设备都看了一遍，一刷新系统蹦出几条某某大学下的大量二级域名网站被篡改的告警，随后经过人工验证所有告警的二级网址均存在被篡改页面,并随即报告给了值班客户，随后应客户要求兴(hao)高(bu)采(qing)烈(yuan)地到了现场做应急处置，至于为什么称之为诡异请看下述分析。

事件分析

到达现场后，随之跟网络相关负责人沟通，得知被篡改的所有二级域名网站都是部署在同一台服务器上的，服务器分前台服务器和后台服务器，并且服务器出到互联网的话得经过两台waf防火墙，且内网部署有深X服EDR和明X态势感知，网站都已部署防篡改安全防护做的很充足，需要部署的点几乎都上了设备，经询问网络相关负责人得知安全设备并无任何告警，之前也有用EDR查杀过病毒但也无任何异常，这就比较诡异了。

经过勘察，站群架设在IIS中间件服务器上，同时运行着18个网站直呼好家伙。

页面发生了篡改说明攻击者已经拿到了服务器一定的权限那么很有可能会留存有webshell后门文件，因为网站文件过多，老规矩一上来就先利用D盾对这18个网站的目录进行后门文件的查杀，在查杀的同时也可以利用这个时间去找找其他可疑的点，过了许久查杀出了在某个二级学院网站目录下的IAA目录共有12.ashx、12.aspx、2012.aspx、ijvsx9.asp四个后门文件，其他站群并无疑似webshell的文件。

查看后门创建时间，均为2017年12月21日，后门创建时间久远，但发生篡改是在1月6号，这不科学啊难道不是同一批入侵者？难道入侵者篡改了页面把后门给清理了？还是说这几个后门文件被入侵者有意的修改了日期呢？小小的脑袋大大滴疑问。

进一步的分析，并未发现网站根目录下发生篡改告警时生成的后缀目录或者文件，所以说被篡改的不是网站内原有的文件或生成新的页面文件，而且网站上都部署了防篡改系统，经过验证在根目录创建文件并不成功防篡改生效这就很诡异，很像是网站的全局动态文件劫持的手法。

定位问题

果不其然在进一步的排查IIS当中，在IIS的引用模块处发现两条可疑的dll文件分别为iisW3d.dll、iisW3x.dll。

定位根据文件的路径定位到所在的C盘Windows\System32\inetsrv目录下，发现这两个dll并无任何信息任何的数字签名，dll的修改的时间为1月5号23:33分也就是发生篡改的前一天，将两个dll文件下载至本地并利用奇安信天擎查杀显示为木马文件。

网络日志排查

综合上述分析已知4个后门文件都在IAA目录下，通过这一信息对IIS的网络日志从1号至6号进行搜索关键词IAA，仅在5号有IAA目录的访问日志，在5号14:57分开始先是GET访问12.ashx后门文件，这应该是入侵者验证确认该后门是否还存在，随后确定了后门还存在后在进行POST的数据传输行为。

总结

通过以上分析，网页防篡改功能确实已经开启了但防护的仅仅只是WEB目录，经过验证后门是可以实现通过WEB跨目录到C盘下的操作的，入侵者也是利用了这点植入恶意的dll文件劫持IIS达到了篡改网站的目的，这点也说得通了为什么部署了网站防篡改后网页还是一样会遭受到篡改的原因。

因为后门文件存在过于久远无法从现有的相关日志去进行溯源后门是如何被上传的，也从网络安全的管理人员的口中得知网站之前做过一次迁移估计是迁移前就存在了后门文件，随后删除了两个恶意dll文件重启IIS网站就得以恢复。

整改建议：

1、网站上存留久远后门文件，建议每周对网站整个目录进行webshell后门查杀。

2、网站防篡改虽然生效，但在验证后门文件时可以通过后门文件进行跨目录操作，跨目录修改文件，建议对目录进行访问限制，根据实际情况配置防篡改所保护的目录不单单只保护网站目录。

3、服务器上存有恶意文件EDR却无告警，建议核查服务器上是否已安装EDR客户端，若安装了客户端是否在开启的状态。

4、1月5号时有连接后门传输数据等高危操作明X态势感知并未告警，建议核实态势感知是否能监测到网站服务器的网络访问流量,功能是否生效。