1. 程式人生 > >記一次服務器被入侵的調查取證

記一次服務器被入侵的調查取證

TP 應用 html mon down 幾分鐘 log 一個 elf文件

0×1 事件描述

小Z所在公司的信息安全建設還處於初期階段,而且只有小Z新來的一個信息安全工程師,所以常常會碰到一些疑難問題。一天,小Z接到運維同事的反映,一臺tomcat 的web服務器雖然安裝了殺軟,但是還是三天兩頭會出現殺軟病毒報警,希望他能查下原因。

小Z首先設想了三種可能性:

1.存在系統漏洞

2.由於前期運維在服務器上裝了一些工具軟件,會不會工具軟件引入的病毒

3.應用層漏洞。

於是,他從這三方面開始了調查。

首先,小Z用更新庫的漏掃對系統層面的漏洞檢測,未發現任何異常;由於會有開發連接進這臺服務器,他去開發那裏收集工具軟件進行查毒處理,也沒發現異常,排除通過軟件帶入病毒的可能;那難道是通過應用層漏洞進來的?因為系統上線前都會經過web滲透測試,文件上傳,SQL註入等常規漏洞已經修復,雖然這樣,小Z還是重新驗證了一遍漏洞,沒有問題,又用D盾webshell檢測工具進行了掃面,未發現任何webshell。

那病毒是怎麽產生的?

0×2 溯源準備

由於病毒無法清幹凈,也不清楚黑客是已經在機器上做了哪些手腳,業務方要求小Z重新搭建一個幹凈的環境,給系統打好最新的補丁,交給開發重新放入生產。由於前期沒有在主機端做日誌收集類工具,缺乏主機端的攻擊溯源手段,小Z臨時搭建了splunk日誌分析系統,並在新搭建的服務器上安裝了sysmon日誌收集工具,對主機層面進行了日誌收集。過了一星期左右,小Z發現系統進程裏面居然多了個叫wcmoye的進程,憑感覺這不是個正常程序,那就先從這個程序開始入手調查吧。

0×3 常規排查

常規排查還是采用了微軟經典系統工具systeminternals套件,分別對啟動項,系統進程,網絡連接等簡單做了排查。

啟動項除了services這一項發現了一個奇怪的StuvwxAbcdefg Jkl,其他沒有特別值得註意的地方。

技術分享圖片

進程排查就是那個叫wcmoye.exe的進程

技術分享圖片

進程依賴於StuvwxAbcdefgh Jkl這個服務

技術分享圖片

網絡通信:用tcpview觀察wcmoye.exe會不定時連接一公網ip的9999端口

技術分享圖片

同時會有一些註冊表及文件系統上的行為,確定wcmoye躲在C:\windows\syswow64目錄下

技術分享圖片

初步排查得出的結論是:wcmoye進程依賴於名叫Stuvwx Abcdefg Jkl系統服務,去syn鏈接公網ip的9999端口,是個木馬程序。

在對wcmoye有了一定認識之後,小Z想它是從哪裏來的,這時,小Z之前搭建的日誌分析系統派上了用場。

0×4 日誌排查

這個問題得從wcmoye.exe在系統中產生的第一時間著手調查。於是打開splunk開始搜索:通過 wcmoye關鍵字的搜索,發現6月6日20:24發生如下可疑事件:

20:24:11 Tomcat目錄下有一個叫NewRat的可執行文件生成wcmoye.exe,原來wcmoye是有一個叫NewRat的可執行文件生成的,但是回到Tomcat目錄下查看,並沒有發現NewRat.exe這個文件.

技術分享圖片

不急,進一步搜索NewRat,小Z發現了更大的信息量:在wcmoye被創建的前一秒 20:24:10,tomcat7.exe去調用cmd.exe執行了一段比較長的腳本,

技術分享圖片

隨著時序跟蹤事件的發展,發現在20:24:12 調用cmd.exe刪除了NewRat.exe

技術分享圖片

同時還觀察到services.exe的執行,系統服務創建

技術分享圖片

關註sysmon的EventCode 3 ,wcmoye的進程會與下載NewRat的那個公網ip的9999端口有通信日誌,

技術分享圖片

其實到這裏,wcmoye是從哪裏進來的已經基本搞清楚了,接下來的問題就是為什麽會進來?Tomcat為什麽去執行這些惡意命令?現在唯一的線索就是日誌中的那個ftp登陸的ip以及賬號密碼了,繼續吧。

0×5 順藤摸瓜

小Z帶著好奇心,繼續探索過程,直接進入了這個ftp服務器!

技術分享圖片

使用FileZilla進入ftp服務器的目錄,以一目十行地速度快速掃了一遍,首先蹦入小Z眼簾的就是NewRat.exe,不錯,和前面的調查結果相吻合,NewRat就安靜地躺在這裏。

技術分享圖片

還有個獨特專版st2-045 winlinux小組版文件夾,潛意識告訴小Z這個文件夾裏面很可能有謎底的答案,先直接百度一下

技術分享圖片

好家夥,雙系統傳馬還Kill國內外主流殺毒軟件,關鍵是st2-045這個就是遠程代碼執行(RCE)漏洞(S2-045,CVE-2017-5638),小Z不禁一顫,之前居然沒想到測試這個高危的提權漏洞。

技術分享圖片

start.bat開始看吧

技術分享圖片

技術分享圖片

有一個叫wincmd.txt的文件,是winows平臺下的執行腳本,紅框的內容和前面splunk日誌中的那段日誌一模一樣,也就是幫小Z引導到這裏的那段關鍵日誌。

技術分享圖片

Linux平臺的腳本:關閉防火墻,下載一個叫tatada的ELF文件,把netstat等系統命令改名,清空日誌等等

技術分享圖片

技術分享圖片

Result.txt文件,記錄著一些掃描到的ip的端口開放情況

技術分享圖片

技術分享圖片

Windows.txt和linux.txt裏面貌似都是存在漏洞的網址。。。

而且其中有一個關鍵的發現,就是小Z所在公司的網站接口居然在一個叫http.txt的list裏面

技術分享圖片

到這裏,小Z已經大致猜得出自己的公司網站是怎麽被盯上的了。再看下幾個可執行文件:

S.exe就是掃描器

技術分享圖片

IDA載入str045

技術分享圖片

技術分享圖片

技術分享圖片

技術分享圖片

技術分享圖片

看得出Str045.exe就是struts2-045的利用腳本程序,他會去讀取S.exe掃描出的ip及端口開放情況的文件,組合do,action等開啟多線程去exploit,然後根據被攻擊的系統版本,去執行相應的腳本,像小Z公司的這臺web服務器是windows的,就會去執行wincmd.txt。

0×6 網絡架構

目前調查到的種種跡象讓小Z堅信黑客是通過struts2-45漏洞進來的!於是小Z去網上下載了一個最新的struts漏洞檢查工具,直接對網站的80端口進行檢測,但結果出乎意料,居然沒有漏洞報警。

技術分享圖片

黑客服務器上只有針對strusts2-045的攻擊腳本,但是檢測又沒有發現漏洞。這個矛盾的問題不禁讓小Z思考更多的可能性。

在陷入迷茫的深思同時, 小Z不經意的翻看著tomcat的localhost_access_log日誌,突然一批ABAB型日誌出現在他眼前,一個公網地址,一個內網地址,時間就在NewRat出現的前幾分鐘20:20:36:

技術分享圖片

這串高度相關的日誌 究竟隱藏著什麽意義?會不會是解開謎團的入口?帶著強烈的好奇心,小Z咨詢了網絡組的同事,什麽情況下才會出現這樣的情況,網絡組給出了網站如下的網絡架構,並說明了由於業務的臨時需求,新對網絡架構做了新的調整。

技術分享圖片

服務器的內網端口是7070,公網防火墻上開放了80,443和8090端口。公網端口8090作了NAT對應內網的7070端口,據說是因為業務新需求開放的;同時為了安全考慮,公網用戶如果只訪問了80後,F5會做強制443端口跳轉訪問F5的一個vip地址。

這種網絡架構,當有人在公網掃描到80和8090端口時,就會出現ABAB型日誌,即A就是通過NAT進來的,B是從vip地址過來的。所以才會出現上述奇怪日誌的原因,那個時刻,是黑客服務器在掃描 80和8090端口。

0×7 水落石出

NewRat也是在那個奇怪的日誌後產生的,這時一個念頭閃現在小Z腦海裏,還是用struts漏洞利用工具,不過這次是去嘗試web的的8090端口!一串清晰的紅字,警告:存在Struts遠程代碼執行漏洞S2-045 !

技術分享圖片

再試試443端口,也能檢測出:

技術分享圖片

獲取web系統內網IP信息

技術分享圖片

技術分享圖片

而且通過搜索tomcat目錄找到 struts的版本為2.5.10,的確是存在S2-045漏洞的版本。

至此,這次入侵的來龍去脈,小Z已經調查清楚了。由於網站使用了struts框架 版本為2.5.10,存在struts2-045漏洞,黑客通過公網掃描找到網站,進而執行exploit把病毒程序傳到服務器裏面執行,不停的病毒警告是因為不斷有人在公網利用漏洞入侵服務器。

0×8 題外話

但同時,小Z也註意到了另一個問題,為什麽struts漏洞利用工具直接訪問80端口無法檢測出漏洞?

小Z於是想到了Wireshark,這個網絡放大鏡或許能給出點蛛絲馬跡。還是抓包對比一下吧。

抓一下未檢測出漏洞的80端口的包,

技術分享圖片

技術分享圖片

技術分享圖片

技術分享圖片

第一次get請求,F5返回了一個https的302重定向後,由於connection:close,F5直接做出了FIN ACK

技術分享圖片

技術分享圖片

技術分享圖片

第二次,軟件請求的還是與80端口,而且get請求是帶完整https url路徑的,這種請求格式導致F5返回一個奇怪的重定向https://WWW.XXX.COMhttps://WWW.XXX.COM/test/test.do.導致漏洞驗證失敗。

再來對比一下瀏覽器頁面訪問80端口測試:經過tcp三次握手,瀏覽器發出get請求之後,F5返回一個302重定向,瀏覽器於是向443端口開始了三次握手,接下來就是https的通信過程,

技術分享圖片

技術分享圖片

通過對比實驗分析,發現在漏洞利用工具在測試80端口時,如果網站做了80轉443端口的強制跳轉,瀏覽器在得到302重定向後就開始向443端口開始3次握手,而測試軟件的數據包處理過程就有問題,這時候直接測試80端口軟件就會存在誤報。

小Z之前由於粗心,只測試網站的80端口,得出錯誤的結論,原因也找到了。

0×9 結尾

到此為止,所有的謎團一一解開,小Z結束了這次曲折的入侵取證之路。

參考鏈接:

https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

http://www.freebuf.com/sectool/125846.htm

記一次服務器被入侵的調查取證