記一次IIS-Raid應急響應&溯源
0x01 緣由
晚上9點學校打電話說官網服務器可能被入侵了,第一時間登錄服務器發現被裝了一堆 360 的產品,360安全衛士,360安全殺毒 等等,之后又重新安裝上了卡巴斯基卸載了360
0x02 應急
服務器環境:
Windows Server 2016 IIS10.0.NET ASPX
因為服務器是雙網卡,分別通校園資產內網和外網教育網,第一時間登錄服務器把內網網卡禁用掉(外網登錄),目的是為了防止入侵者做橫向攻擊,然后對關鍵文件做備份,修改RDP密碼,數據庫密碼,殺毒,拍快照方便后期取證等手段...
卡巴斯基掃描發現存在一些以 .cs 結尾的.net惡意文件(這個 .cs 文件后面會詳細說到)和木馬文件 autohbas.dll,之后卡巴斯基直接把autohbas.dll給刪了,結果服務器產生了503錯誤

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

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

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

文件屬性

卡巴斯基KSN信譽掃描對比


打開 edge 瀏覽器發現,在 19點 左右入侵者搜索360安全衛士并且下載了安裝包進行了安裝,一開始不了解為什么會這樣做,如果要搞隱蔽為什么要有這么大的動靜?

檢查了一下用戶發現存在 vmadmin 并且還啟用了 Guest
PS: 開始以為vmadmin是虛擬機管理用戶一直沒去排查,過了幾個小時才反應過來 :(

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

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

用D盾做了一下檢測發現vmadmin是克隆的administrator賬號,且DLL是被惡意注冊到了IIS的 Modules


掃了一下Web服務下的文件,找到了幾個 Webshell ,發現 1月份 就已經有了,可見埋伏時間之長
因為dll不能直接刪除,所以先把webshell和創建的用戶給刪除掉,之后把這些webshell和dll做一下樣本提取

后來百度搜索了一下,發現后門手法是 IIS-Raid,將惡意dll注冊到IIS服務端,之后可直接獲取服務器權限
用list modules 找到惡意的modules,之后用命令刪除已經注冊的模塊即可,因后來截的圖,之前已經卸載過


刪除掉模塊后接著隔離刪除dll,之后重啟服務器和IIS服務器,發現官網不會在報503且一切功能正常使用,再用卡巴斯基和D盾做了一次全盤查殺都一切正常
再接著進行一些常規檢查,檢查完之后發現沒什么異常,至此應急告一段落
官網后臺賬號系統進程網絡連接驅動模塊文件修改時間內容自啟動計劃任務等
0x03 排查
應急之后接著排查問題出在哪里,入侵者怎么黑進來的,做一個溯源。
因服務器做了反向代理,只對外網開放了80、53、3389服務,猜測入侵的手法:
DNS服務 Nday/0DayWeb服務入侵RDP爆
先說一下DNS漏洞基本不太可能,就算是0day也不可能打到我們頭上來,純純浪費,RDP爆破的話,服務器密碼包含 字符數字大小寫 也不太可能,爆破成本量太高,也更不至于,于是大概率是從Web下手
先看了下卡巴斯基的Web攻擊日志,看到攻擊者一直在用代理進行端口掃描,接著不管是什么中間件和開發環境,就拿一些exp亂打,目測是PoC集成工具做的掃描,但是有一條IP引起了注意

放到了微步看了一下

猜測這個可能是攻擊者在做掃描的時候代理池斷了一下導致真實IP發生泄露,不過并不確定
接著又看了一下卡巴的殺毒日志,發現刪掉了很多 autohbas.dll 也就是那個IIS后門,之后的 svchost.exe 猜測是遠控或者其他的后門,發現在19點之后,也就是安裝了360之后就沒有日志,通過這里可以知道,攻擊者安裝360的目的是為了替換掉卡巴斯基的安全防護,因為如果想退出卡巴斯基或結束掉進程都需要提供一個密碼,而這個密碼攻擊者沒有拿到,就只能利用360來接管卡巴斯基

Waf的日志,不明白為什么沒阻斷,看來規則需要加強了


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

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

看了一下系統日志,發現在20點做了日志清理(沒有日志審計),估計后門留好準備跑路了

接著看了一下4624的日志,發現IP也是代理

根據webshell創建的時間找了一下IIS的日志,結果5.27那天的日志被刪了

只能去看01.16的日志

這幾個IP放到微步和QAX情報社區發現都是來自泰國的傀儡機,也去掃了端口只開了3389和22
之后接著去排查webshell是怎么傳上來的,因為shell的所在 文件夾目錄 為后臺上傳圖片所在的目錄,初步猜測是上傳圖片的地方過濾不嚴格導致任意文件上傳,但是我測了幾個小時的任意文件上傳發現webshell根本無法上傳成功,且無法得知上傳的路徑反饋,加上我有服務器權限可以配合著D盾做文件監控,后來決定先上傳正常的圖片文件看看上傳路徑,發現可以上傳成功,但是上傳的路徑卻是在 \photo\product\ 下,不是在webshell的路徑\photo\temp\ 下,哪怕是正常的圖片也無法傳到這個目錄來,不知道代碼對于圖片的處理邏輯,且后臺和前臺的一些圖片也被上傳到了目錄,百思不得其解,很沒有道理
后來靈機一動,猜測temp目錄下可能是損壞的圖片,于是burp抓包故意把圖片的內容做一些刪除和增加,結果最后還是沒有上傳到webshell目錄下,這個時候就很絕望,明明是通過官網后臺上傳上來的(webshell文件命名規則和上傳圖片命名一樣),但是一直沒有找到上傳點,這個時候就猜想可能是0day,但是這個程序沒有第二套都是單獨開發的,入侵者應該也拿不到源碼,正當一頭霧水的時候,我聯系了網站的開發商,對話如下:




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



結果顯而易見,至此漏洞點基本排查完成
正以為后門已經全部檢查完成之后,過了一會,D盾的文件檢測檢測到了Webshell的創建,看了一下Waf日志確定Webshell不是從官網后臺傳上來的,卡巴斯基掃了下,發現是 .cs 文件,因為上回卡巴斯基直接做了刪除沒去看源文件,這次準備把文件先隔離到沙箱拖出來看一下,直接上圖
路徑:C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\b595ac21\4cd2f735



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


0x05 加固
排查官網后臺所有用戶做弱口令檢查,服務器RDP遠程登陸設置白名單,Waf加強規則

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


0x06 附錄
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 ** 中國 北京市 |中國教育網223.166.75.202 ** 中國/上海/上海/浦東新區 |南碼頭|住宅用戶|中國聯通 | 家庭寬帶| 121.510116,31.18071247.112.133.172 中國廣東深圳 阿里云/電信/聯通/移動/教育網