0×1 事件描述
小Z所在公司的信息安全建設(shè)還處于初期階段，而且只有小Z新來的一個信息安全工程師，所以常常會碰到一些疑難問題。一天，小Z接到運維同事的反映，一臺tomcat 的web服務(wù)器雖然安裝了殺軟，但是還是三天兩頭會出現(xiàn)殺軟病毒報警，希望他能查下原因。
小Z首先設(shè)想了三種可能性:
1.存在系統(tǒng)漏洞
2.由于前期運維在服務(wù)器上裝了一些工具軟件，會不會工具軟件引入的病毒
3.應(yīng)用層漏洞。
于是，他從這三方面開始了調(diào)查。
首先，小Z用更新庫的漏掃對系統(tǒng)層面的漏洞檢測，未發(fā)現(xiàn)任何異常；由于會有開發(fā)連接進(jìn)這臺服務(wù)器，他去開發(fā)那里收集工具軟件進(jìn)行查毒處理，也沒發(fā)現(xiàn)異常，排除通過軟件帶入病毒的可能；那難道是通過應(yīng)用層漏洞進(jìn)來的？因為系統(tǒng)上線前都會經(jīng)過web滲透測試，文件上傳，SQL注入等常規(guī)漏洞已經(jīng)修復(fù)，雖然這樣，小Z還是重新驗證了一遍漏洞，沒有問題，又用D盾webshell檢測工具進(jìn)行了掃面，未發(fā)現(xiàn)任何webshell。
那病毒是怎么產(chǎn)生的？
0×2 溯源準(zhǔn)備
由于病毒無法清干凈，也不清楚黑客是已經(jīng)在機器上做了哪些手腳，業(yè)務(wù)方要求小Z重新搭建一個干凈的環(huán)境，給系統(tǒng)打好最新的補丁，交給開發(fā)重新放入生產(chǎn)。由于前期沒有在主機端做日志收集類工具，缺乏主機端的攻擊溯源手段，小Z臨時搭建了splunk日志分析系統(tǒng)，并在新搭建的服務(wù)器上安裝了sysmon日志收集工具，對主機層面進(jìn)行了日志收集。過了一星期左右，小Z發(fā)現(xiàn)系統(tǒng)進(jìn)程里面居然多了個叫wcmoye的進(jìn)程，憑感覺這不是個正常程序，那就先從這個程序開始入手調(diào)查吧。
0×3 常規(guī)排查
常規(guī)排查還是采用了微軟經(jīng)典系統(tǒng)工具systeminternals套件，分別對啟動項，系統(tǒng)進(jìn)程，網(wǎng)絡(luò)連接等簡單做了排查。
啟動項除了services這一項發(fā)現(xiàn)了一個奇怪的StuvwxAbcdefg Jkl，其他沒有特別值得注意的地方。
進(jìn)程排查就是那個叫wcmoye.exe的進(jìn)程
進(jìn)程依賴于StuvwxAbcdefgh Jkl這個服務(wù)
網(wǎng)絡(luò)通信：用tcpview觀察wcmoye.exe會不定時連接一公網(wǎng)ip的9999端口
同時會有一些注冊表及文件系統(tǒng)上的行為，確定wcmoye躲在C:\windows\syswow64目錄下
初步排查得出的結(jié)論是：wcmoye進(jìn)程依賴于名叫Stuvwx Abcdefg Jkl系統(tǒng)服務(wù)，去syn鏈接公網(wǎng)ip的9999端口，是個木馬程序。
在對wcmoye有了一定認(rèn)識之后，小Z想它是從哪里來的，這時，小Z之前搭建的日志分析系統(tǒng)派上了用場。
0×4 日志排查
這個問題得從wcmoye.exe在系統(tǒng)中產(chǎn)生的第一時間著手調(diào)查。于是打開splunk開始搜索：通過 wcmoye關(guān)鍵字的搜索，發(fā)現(xiàn)6月6日20：24發(fā)生如下可疑事件：
20：24：11 Tomcat目錄下有一個叫NewRat的可執(zhí)行文件生成wcmoye.exe，原來wcmoye是有一個叫NewRat的可執(zhí)行文件生成的，但是回到Tomcat目錄下查看，并沒有發(fā)現(xiàn)NewRat.exe這個文件.
不急，進(jìn)一步搜索NewRat，小Z發(fā)現(xiàn)了更大的信息量:在wcmoye被創(chuàng)建的前一秒 20：24：10，tomcat7.exe去調(diào)用cmd.exe執(zhí)行了一段比較長的腳本，
隨著時序跟蹤事件的發(fā)展，發(fā)現(xiàn)在20：24：12 調(diào)用cmd.exe刪除了NewRat.exe
同時還觀察到services.exe的執(zhí)行，系統(tǒng)服務(wù)創(chuàng)建
關(guān)注sysmon的EventCode 3 ，wcmoye的進(jìn)程會與下載NewRat的那個公網(wǎng)ip的9999端口有通信日志，
其實到這里，wcmoye是從哪里進(jìn)來的已經(jīng)基本搞清楚了，接下來的問題就是為什么會進(jìn)來？Tomcat為什么去執(zhí)行這些惡意命令？現(xiàn)在唯一的線索就是日志中的那個ftp登陸的ip以及賬號密碼了，繼續(xù)吧。
0×5 順藤摸瓜
小Z帶著好奇心，繼續(xù)探索過程，直接進(jìn)入了這個ftp服務(wù)器!
使用FileZilla進(jìn)入ftp服務(wù)器的目錄，以一目十行地速度快速掃了一遍，首先蹦入小Z眼簾的就是NewRat.exe，不錯，和前面的調(diào)查結(jié)果相吻合，NewRat就安靜地躺在這里。
還有個獨特專版st2-045 winlinux小組版文件夾，潛意識告訴小Z這個文件夾里面很可能有謎底的答案，先直接百度一下
好家伙，雙系統(tǒng)傳馬還Kill國內(nèi)外主流殺毒軟件，關(guān)鍵是st2-045這個就是遠(yuǎn)程代碼執(zhí)行（RCE）漏洞(S2-045,CVE-2017-5638)，小Z不禁一顫，之前居然沒想到測試這個高危的提權(quán)漏洞。
start.bat開始看吧
有一個叫wincmd.txt的文件，是winows平臺下的執(zhí)行腳本，紅框的內(nèi)容和前面splunk日志中的那段日志一模一樣，也就是幫小Z引導(dǎo)到這里的那段關(guān)鍵日志。
Linux平臺的腳本：關(guān)閉防火墻，下載一個叫tatada的ELF文件，把netstat等系統(tǒng)命令改名，清空日志等等
Result.txt文件，記錄著一些掃描到的ip的端口開放情況
Windows.txt和linux.txt里面貌似都是存在漏洞的網(wǎng)址。。。
而且其中有一個關(guān)鍵的發(fā)現(xiàn)，就是小Z所在公司的網(wǎng)站接口居然在一個叫http.txt的list里面
到這里，小Z已經(jīng)大致猜得出自己的公司網(wǎng)站是怎么被盯上的了。再看下幾個可執(zhí)行文件:
S.exe就是掃描器
IDA載入str045
看得出Str045.exe就是struts2-045的利用腳本程序，他會去讀取S.exe掃描出的ip及端口開放情況的文件，組合do，action等開啟多線程去exploit，然后根據(jù)被攻擊的系統(tǒng)版本，去執(zhí)行相應(yīng)的腳本，像小Z公司的這臺web服務(wù)器是windows的，就會去執(zhí)行wincmd.txt。
0×6 網(wǎng)絡(luò)架構(gòu)
目前調(diào)查到的種種跡象讓小Z堅信黑客是通過struts2-45漏洞進(jìn)來的！于是小Z去網(wǎng)上下載了一個最新的struts漏洞檢查工具，直接對網(wǎng)站的80端口進(jìn)行檢測，但結(jié)果出乎意料，居然沒有漏洞報警。
黑客服務(wù)器上只有針對strusts2-045的攻擊腳本，但是檢測又沒有發(fā)現(xiàn)漏洞。這個矛盾的問題不禁讓小Z思考更多的可能性。
在陷入迷茫的深思同時， 小Z不經(jīng)意的翻看著tomcat的localhost_access_log日志，突然一批ABAB型日志出現(xiàn)在他眼前，一個公網(wǎng)地址，一個內(nèi)網(wǎng)地址，時間就在NewRat出現(xiàn)的前幾分鐘20:20:36：
這串高度相關(guān)的日志 究竟隱藏著什么意義？會不會是解開謎團(tuán)的入口？帶著強烈的好奇心，小Z咨詢了網(wǎng)絡(luò)組的同事，什么情況下才會出現(xiàn)這樣的情況，網(wǎng)絡(luò)組給出了網(wǎng)站如下的網(wǎng)絡(luò)架構(gòu)，并說明了由于業(yè)務(wù)的臨時需求，新對網(wǎng)絡(luò)架構(gòu)做了新的調(diào)整。
服務(wù)器的內(nèi)網(wǎng)端口是7070，公網(wǎng)防火墻上開放了80，443和8090端口。公網(wǎng)端口8090作了NAT對應(yīng)內(nèi)網(wǎng)的7070端口，據(jù)說是因為業(yè)務(wù)新需求開放的；同時為了安全考慮，公網(wǎng)用戶如果只訪問了80后，F(xiàn)5會做強制443端口跳轉(zhuǎn)訪問F5的一個vip地址。
這種網(wǎng)絡(luò)架構(gòu)，當(dāng)有人在公網(wǎng)掃描到80和8090端口時，就會出現(xiàn)ABAB型日志，即A就是通過NAT進(jìn)來的，B是從vip地址過來的。所以才會出現(xiàn)上述奇怪日志的原因，那個時刻，是黑客服務(wù)器在掃描 80和8090端口。
0×7 水落石出
NewRat也是在那個奇怪的日志后產(chǎn)生的，這時一個念頭閃現(xiàn)在小Z腦海里，還是用struts漏洞利用工具，不過這次是去嘗試web的的8090端口！一串清晰的紅字,警告:存在Struts遠(yuǎn)程代碼執(zhí)行漏洞S2-045 ！
再試試443端口，也能檢測出：
獲取web系統(tǒng)內(nèi)網(wǎng)IP信息
而且通過搜索tomcat目錄找到 struts的版本為2.5.10，的確是存在S2-045漏洞的版本。
至此，這次入侵的來龍去脈，小Z已經(jīng)調(diào)查清楚了。由于網(wǎng)站使用了struts框架 版本為2.5.10，存在struts2-045漏洞，黑客通過公網(wǎng)掃描找到網(wǎng)站，進(jìn)而執(zhí)行exploit把病毒程序傳到服務(wù)器里面執(zhí)行，不停的病毒警告是因為不斷有人在公網(wǎng)利用漏洞入侵服務(wù)器。
0×8 題外話
但同時，小Z也注意到了另一個問題，為什么struts漏洞利用工具直接訪問80端口無法檢測出漏洞?
小Z于是想到了Wireshark，這個網(wǎng)絡(luò)放大鏡或許能給出點蛛絲馬跡。還是抓包對比一下吧。
抓一下未檢測出漏洞的80端口的包，
第一次get請求，F(xiàn)5返回了一個https的302重定向后，由于connection:close，F(xiàn)5直接做出了FIN ACK
第二次，軟件請求的還是與80端口，而且get請求是帶完整https url路徑的,這種請求格式導(dǎo)致F5返回一個奇怪的重定向https://WWW.XXX.COMhttps://WWW.XXX.COM/test/test.do.導(dǎo)致漏洞驗證失敗。
再來對比一下瀏覽器頁面訪問80端口測試：經(jīng)過tcp三次握手，瀏覽器發(fā)出get請求之后，F(xiàn)5返回一個302重定向，瀏覽器于是向443端口開始了三次握手，接下來就是https的通信過程，
通過對比實驗分析，發(fā)現(xiàn)在漏洞利用工具在測試80端口時，如果網(wǎng)站做了80轉(zhuǎn)443端口的強制跳轉(zhuǎn)，瀏覽器在得到302重定向后就開始向443端口開始3次握手，而測試軟件的數(shù)據(jù)包處理過程就有問題，這時候直接測試80端口軟件就會存在誤報。
小Z之前由于粗心，只測試網(wǎng)站的80端口，得出錯誤的結(jié)論，原因也找到了。
0×9 結(jié)尾
到此為止，所有的謎團(tuán)一一解開，小Z結(jié)束了這次曲折的入侵取證之路。
