記一次IIS-Raid后門應急經歷

　　聲明：該公眾號大部分文章來自作者日常學習筆記，也有部分文章是經過作者授權和其他公眾號白名單轉載，未經授權，嚴禁轉載，如需轉載，聯(lián)系開白。請勿利用文章內的相關技術從事非法測試，如因此產生的一切不良后果與文章作者和本公眾號無關。

　　這篇文章已經過某師傅授權發(fā)布在該公眾號，非常詳細的一篇應急文，感謝這位師傅的分享！

　　0x01 緣由

　　晚上9點學校打電話說官網服務器可能被入侵了，第一時間登錄服務器發(fā)現(xiàn)被裝了一堆 360 的產品，360安全衛(wèi)士，360安全殺毒 等等，之后又重新安裝上了卡巴斯基卸載了360

　　0x02 應急

　　服務器環(huán)境：

　　因為服務器是雙網卡，分別通校園資產內網和外網教育網，第一時間登錄服務器把內網網卡禁用掉（外網登錄），目的是為了防止入侵者做橫向攻擊，然后對關鍵文件做備份，修改RDP密碼，數據庫密碼，殺毒，拍快照方便后期取證等手段...

　　卡巴斯基掃描發(fā)現(xiàn)存在一些以 .cs 結尾的.net惡意文件（這個 .cs 文件后面會詳細說到）和木馬文件 autohbas.dll，之后卡巴斯基直接把autohbas.dll給刪了，結果服務器產生了503錯誤

　　IS重啟和服務器重啟都無法解決503，因為是學校官網服務器很多發(fā)文都在上面，503之后就有一堆老師打電話反應，迫于無奈，只能先把dll恢復，然后重新啟動IIS讓官網先運行著

　　dll無法移動和刪除，看了一下dll被 IIS 調用，初步猜測是IIS后門

　　這里用火絨劍看了一下IIS進程的調用dll，dll沒有簽名和描述很可疑

　　文件屬性

　　卡巴斯基KSN信譽掃描對比

　　打開 edge 瀏覽器發(fā)現(xiàn)，在 19點 左右入侵者搜索360安全衛(wèi)士并且下載了安裝包進行了安裝，一開始不了解為什么會這樣做，如果要搞隱蔽為什么要有這么大的動靜？

　　檢查了一下用戶發(fā)現(xiàn)存在 vmadmin 并且還啟用了 Guest

　　PS: 開始以為vmadmin是虛擬機管理用戶一直沒去排查，過了幾個小時才反應過來 :(

　　Guest被啟用，因為后來登錄了一下，實際上次登陸時間是 2022/5/28 18:50，后來做的復盤截的圖

　　把sam文件dump下來拉到本地做解密，因為是2016的操作系統(tǒng)，只能提取NTML Hash做解密，然后看一下入侵者設置的密碼規(guī)則能不能獲取到關鍵信息，然而最后解不開

　　用D盾做了一下檢測發(fā)現(xiàn)vmadmin是克隆的administrator賬號，且DLL是被惡意注冊到了IIS的 Modules

　　掃了一下Web服務下的文件，找到了幾個 Webshell ，發(fā)現(xiàn) 1月份 就已經有了，可見埋伏時間之長

　　因為dll不能直接刪除，所以先把webshell和創(chuàng)建的用戶給刪除掉，之后把這些webshell和dll做一下樣本提取

　　后來百度搜索了一下，發(fā)現(xiàn)后門手法是 IIS-Raid，將惡意dll注冊到IIS服務端，之后可直接獲取服務器權限

　　用list modules 找到惡意的modules，之后用命令刪除已經注冊的模塊即可，因后來截的圖，之前已經卸載過

　　刪除掉模塊后接著隔離刪除dll，之后重啟服務器和IIS服務器，發(fā)現(xiàn)官網不會在報503且一切功能正常使用，再用卡巴斯基和D盾做了一次全盤查殺都一切正常

　　再接著進行一些常規(guī)檢查，檢查完之后發(fā)現(xiàn)沒什么異常，至此應急告一段落

　　0x03 排查

　　應急之后接著排查問題出在哪里，入侵者怎么黑進來的，做一個溯源。

　　因服務器做了反向代理，只對外網開放了80、53、3389服務，猜測入侵的手法：

　　先說一下DNS漏洞基本不太可能，就算是0day也不可能打到我們頭上來，純純浪費，RDP爆破的話，服務器密碼包含 字符數字大小寫 也不太可能，爆破成本量太高，也更不至于，于是大概率是從Web下手

　　先看了下卡巴斯基的Web攻擊日志，看到攻擊者一直在用代理進行端口掃描，接著不管是什么中間件和開發(fā)環(huán)境，就拿一些exp亂打，目測是PoC集成工具做的掃描，但是有一條IP引起了注意

　　放到了微步看了一下

　　猜測這個可能是攻擊者在做掃描的時候代理池斷了一下導致真實IP發(fā)生泄露，不過并不確定

　　接著又看了一下卡巴的殺毒日志，發(fā)現(xiàn)刪掉了很多 autohbas.dll 也就是那個IIS后門，之后的 svchost.exe 猜測是遠控或者其他的后門，發(fā)現(xiàn)在19點之后，也就是安裝了360之后就沒有日志，通過這里可以知道，攻擊者安裝360的目的是為了替換掉卡巴斯基的安全防護，因為如果想退出卡巴斯基或結束掉進程都需要提供一個密碼，而這個密碼攻擊者沒有拿到，就只能利用360來接管卡巴斯基

　　Waf的日志，不明白為什么沒阻斷，看來規(guī)則需要加強了

　　看了一下dll的導出函數和內存，注冊到IIS模塊的函數

　　看到這些函數也就大概能知道這個dll做了什么

　　看了一下系統(tǒng)日志，發(fā)現(xiàn)在20點做了日志清理（沒有日志審計），估計后門留好準備跑路了

　　接著看了一下4624的日志，發(fā)現(xiàn)IP也是代理

　　根據webshell創(chuàng)建的時間找了一下IIS的日志，結果5.27那天的日志被刪了

　　只能去看01.16的日志

　　這幾個IP放到微步和QAX情報社區(qū)發(fā)現(xiàn)都是來自泰國的傀儡機，也去掃了端口只開了3389和22

　　之后接著去排查webshell是怎么傳上來的，因為shell的所在 文件夾目錄 為后臺上傳圖片所在的目錄，初步猜測是上傳圖片的地方過濾不嚴格導致任意文件上傳，但是我測了幾個小時的任意文件上傳發(fā)現(xiàn)webshell根本無法上傳成功，且無法得知上傳的路徑反饋，加上我有服務器權限可以配合著D盾做文件監(jiān)控，后來決定先上傳正常的圖片文件看看上傳路徑，發(fā)現(xiàn)可以上傳成功，但是上傳的路徑卻是在 \photo\product\ 下，不是在webshell的路徑\photo\temp\ 下，哪怕是正常的圖片也無法傳到這個目錄來，不知道代碼對于圖片的處理邏輯，且后臺和前臺的一些圖片也被上傳到了目錄，百思不得其解，很沒有道理

　　后來靈機一動，猜測temp目錄下可能是損壞的圖片，于是burp抓包故意把圖片的內容做一些刪除和增加，結果最后還是沒有上傳到webshell目錄下，這個時候就很絕望，明明是通過官網后臺上傳上來的（webshell文件命名規(guī)則和上傳圖片命名一樣），但是一直沒有找到上傳點，這個時候就猜想可能是0day，但是這個程序沒有第二套都是單獨開發(fā)的，入侵者應該也拿不到源碼，正當一頭霧水的時候，我聯(lián)系了網站的開發(fā)商，對話如下：

　　我一直用的谷歌，谷歌表示不背這個鍋 :(，接著讓朋友白菜哥拿360瀏覽器去測了一下，結果不出所料

　　結果顯而易見，至此漏洞點基本排查完成

　　正以為后門已經全部檢查完成之后，過了一會，D盾的文件檢測檢測到了Webshell的創(chuàng)建，看了一下Waf日志確定Webshell不是從官網后臺傳上來的，卡巴斯基掃了下，發(fā)現(xiàn)是 .cs 文件，因為上回卡巴斯基直接做了刪除沒去看源文件，這次準備把文件先隔離到沙箱拖出來看一下，直接上圖

　　App_Web_x7curnr-.0.cs

　　可以看到有個叫door()的后門函數，且此Webshell的特征是 哥斯拉，因為哥斯拉實例化的類名是 LY，很明顯用的哥斯拉生成的馬子

　　猜測攻擊手法：

　　1）官網文件夾下的 App_Code 文件夾可以包含 .vb、.cs 等擴展名的源代碼文件，在運行時將會自動對這些代碼進行編譯。而 123.asmx.e8a2beba.compiled 是編譯完成的輸出文件，123.asmx就是生成的文件名。攻擊者只需要將.cs源代碼文件放到 App_Code目錄下，網站每運行一次就會生成一個名叫123.asmx的Webshell在/js/目錄下

　　2）官網文件夾下 Bin 文件夾中存放著已經編譯的程序集，并且在Web 應用程序任意處的其他代碼會 自動引用該文件夾，典型的示例是為自定義類編譯好的代碼，可以將編譯后的程序集復制到Web應用程序的 Bin文件夾中，這樣所有頁都可以使用這個類，Bin文件夾中的程序集無需注冊，只要.dll 文件存在于 Bin 文件夾中，.NET 就可以識別它。如果更改了 .dll 文件，并將它的新版本寫入到了 Bin 文件夾中，則 .NET 會檢測到更新，并對隨后的新頁請求使用新版本的 .dll 文件

　　3）.NET 內存馬，參考文章：

　　0x04 復盤

　　首次攻擊發(fā)生在2022年的1月16日，那個時候的官網后臺應該是有弱口令，攻擊者通過掃描端口和Web目錄找到Web后臺，期間還進行過一系列的SQL注入測試，接著通過爆破進入到后臺進行任意文件上傳拿到shell，在拿到shell后繼續(xù)留了一個aspx的webshell后門，接著用某種方法提權到system權限創(chuàng)建了用戶vmadmin并且克隆了administrator的權限，接著以防萬一激活了Guest用戶，緊接著通過3389連接到administrator服務器桌面，發(fā)現(xiàn)有卡巴斯基，嘗試退出結束發(fā)現(xiàn)無果后，隔了一短時間后通過瀏覽器下載360來接管卡巴斯基的防護，替換掉卡巴斯基后，上傳了PChunter和dll后門，通過IIS-Raid手法將dll注冊成IIS后門，然后接著留下.NET后門通過.NET機制來做到權限維持，最后上傳了自己寄生蟲程序，給自己菠菜和某些廣告帶流量和關鍵詞，至此被學校相關人員發(fā)現(xiàn)，導致痕跡沒有清理干凈；最終的入侵目的是為了搞寄生蟲和關鍵詞排名，入侵者后來留的這些后門基本都被卡巴斯基查殺，但是寄生蟲程序已經運行且已經被百度蜘蛛爬取到，只能第一時間去做快照和關鍵詞舉報

　　0x05 加固

　　排查官網后臺所有用戶做弱口令檢查，服務器RDP遠程登陸設置白名單，Waf加強規(guī)則

　　針對任意文件上傳做修復，可以看到之前的代碼沒有對文件后綴名做處理，只是原封不動的照搬上傳文件的后綴

　　0x06 附錄

　　IIS-Raid：

　　.Net DLL后門：

　　IOC：

　　關 注 有 禮關注公眾號回復“9527”可以領取一套HTB靶場文檔和視頻，“1208”個人常用高效爆破字典，“0221”2020年酒仙橋文章打包，“2191”瀟湘信安文章打包，“1212”殺軟對比源碼+數據源，“0421”Windows提權工具包。

　　還在等什么？趕緊點擊下方名片關注學習吧！

　　推 薦 閱 讀