記一次IIS-Raid后門應(yīng)急經(jīng)歷

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

0x01 緣由

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

服務(wù)器環(huán)境：

Windows Server 2016 IIS10.0.NET ASPX

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

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

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

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

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

文件屬性

卡巴斯基KSN信譽掃描對比

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

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

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

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

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

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

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

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

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

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

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

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

官網(wǎng)后臺賬號系統(tǒng)進程網(wǎng)絡(luò)連接驅(qū)動模塊文件修改時間內(nèi)容自啟動計劃任務(wù)等

0x03 排查

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

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

DNS服務(wù) Nday/0DayWeb服務(wù)入侵RDP爆破

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

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

放到了微步看了一下

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

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

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

看了一下dll的導(dǎo)出函數(shù)和內(nèi)存，注冊到IIS模塊的函數(shù)

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

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

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

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

只能去看01.16的日志

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

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

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

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

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

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

路徑：C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\b595ac21\4cd2f735

App_Web_x7curnr-.0.cs

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

猜測攻擊手法：

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

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

3）.NET 內(nèi)存馬，參考文章：

https://tttang.com/archive/1408/

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

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

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

IIS-Raid：

https://github.com/zhangdebiao/iisbackdoor/https://github.com/0x09AL/IIS-Raidhttps://www.cnblogs.com/zaqzzz/p/12942439.htmlhttps://www.codercto.com/a/112760.htmlhttps://y4er.com/post/using-csharp-to-develop-the-iis-module-backdoor/

.Net DLL后門：

https://www.anquanke.com/post/id/153602

IOC：

IOC:45.8.68.96149.154.161.4223.24.162.36223.24.160.2
185.240.246.6 IDC機房 3389  49154 5342.247.33.214 ** 中國 北京市 |中國教育網(wǎng)223.166.75.202 ** 中國/上海/上海/浦東新區(qū) |南碼頭|住宅用戶|中國聯(lián)通 | 家庭寬帶| 121.510116,31.18071247.112.133.172 中國廣東深圳 阿里云/電信/聯(lián)通/移動/教育網(wǎng)