某大学大量二级域名网站被篡改，应急处置过程及诡异情况分析

于一次日常巡检期间，出现这般情况，发现某高校存在大批二级域名网站被篡改的状况。更为诡异的是，此家单位安全设备堆积得满满当当，诸如Web防火墙、防篡改系统、EDR、态势感知等设备一应俱全，然而却集体“失明”了，未曾有一条告警信息。这究竟是一场经过精心策划的入侵行为呢，还是安全体系自身出现的“灯下黑”情况呢？

看似固若金汤的防线

到达现场之后，我跟网络方面的负责人交流沟通从而得知，所有那些被篡改了的二级域名相关网站，全部都集中在同一台服务器上运行。这台服务器划分成了前台与后台，若要通向互联网，必定得经过两台WAF防火墙的检查，真可谓是层层都设置了防线。

内网上，单位布置了深X服的EDR，也设置了明X的态势感知，每个网站都配备了防篡改系统。从网络边界直至主机内部，能安装的安全设备差不多全装上了。负责人满心困惑，因为这些设备毫无任何告警，之前运用EDR查杀病毒时也全然一无所获。

尘封四年的后门文件

是我最先去检查的服务器，经查看发现站群是架设在IIS之上的，并且同时有18个网站处于运行状态。页面出现了被篡改的情况一起看，这表明攻击者已然获取了权限，而且极有可能留有后门。随后我马上运用D盾来针对18个网站目录展开webshell查杀操作。

查杀之后得出的结果让人感到意外，仅仅是在某一个二级学院的网站相应目录之下，也就是IAA目录当中一起看博客，发现了四个相关的后门文件，分别是12.ashx、12.aspx、2012.aspx、ijvsx9.asp。更为奇特的是，这些文件的创建时间是在2017年12月21日，距离现今已经过去了四年还要多，然而篡改这一事件发生的时间却是在1月6日。

防篡改为何形同虚设

时间方面存在的矛盾致使我陷入深深的思索之中。倘若入侵者属于同一批，那为何遗留下是四年前的后门呢？在他们对页面进行篡改之后，难道还会特地将自身的工具清理掉吗？又或者说，他们是故意对文件时间作出了改动，企图以此来干扰调查吗？

经过进一步的深入分析，得出的结果是，在网站根目录之下并没有出现新增的、发生了篡改的页面文件。明明已经部署了具备防篡改功能的系统，并且经过验证，根本无法在根目录当中创建文件，然而页面却实实在在地被更改了。这种情况显得极为不寻常，使得人不禁联想到，或许是借助劫持IIS全局动态文件的方式来达成绕过的目的。

IIS模块里的“幽灵”

有着疑问，我深入去排查IIS配置，于IIS的引用模块处，两条可疑的dll文件引发了我的留意，那便是iisW3d.dll和iisW3x.dll。它们所在位置为C盘Windows\System32\inetsrv这个目录下，且并无任何数字签名。

1月5日23点33分，是这两个dll的修改时间，此时间恰好是发生篡改的前一天。我把文件下载至本地，运用奇安信天擎进行扫描，扫描结果证实是木马。入侵者极有可能借助老后门上传了恶意dll，进而劫持了IIS处理流程，最终绕过了根目录的防篡改规则。

日志里的最后行动

之所以对IIS日志进行关键词搜索，是因为后门文件处于IAA目录之下。从1月1日起始，一直到6日，仅在5日的时候发现了访问记录。在当天14点57分这个时刻开始，有IP率先以GET方式去访问12.ashx，这般情况应当是入侵者针对后门是否存活展开验证。

在确认后门能够正常使用之后，日志里头紧接着就出现了POST数据传输的行为，这表明攻击者借助这个陈旧的后门，上传了具有恶意的dll文件，且完成了对于IIS的劫持配置，从而为第二天的批量篡改做好了相应准备。

亡羊补牢的整改建议

最终整个事件变得清晰起来，网页防篡改仅仅保护了网站目录，然而后门却能够进行跨目录操作C盘。入侵者恰恰是利用了这个存在的盲区，植入dll来劫持IIS。而后门文件为什么会存在呢？根据管理员的回忆，网站曾经做过迁移，极有可能在迁移之前就已经被植入了。

对应此次事件，我给出了四条建议：其一，每一周针对网站所有目录开展webshell扫描，将历史遗留风险予以清除；其二，防篡改配置不能仅注视网站根目录，需对跨目录操作加以严格限制；其三，核查EDR客户端是不是正常运行，确保主机监控不会失效；其四，检查态势感知能不能真正解析网站服务器的南北向流量，防止设备沦为摆设。

若是屏幕跟前的你，碰到了所有安全设施都毫无声息，然而站点却实实在在被更改了的状况，你会从哪儿着手去展开排查呢，欢迎于评论区域分享你的想法，并且请点赞转发，以使更多同行能够看到这个典型事例。