記一次詭異的網站篡改應急響應，結尾總結整改建議

概述

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態勢感知并未告警，建議核實態勢感知是否能監測到網站服務器的網絡訪問流量,功能是否生效。