計算機病毒主要侵害的系統：電腦中病毒是怎麼產生的

網路安全

事件描述由於經常購買伺服器 ，某天，發現一台伺服器上面雖然安裝了 360 ，但是 ，仍然提示入侵提示 。讓我特別納悶，於是開始調查下原因

首先設想了三種可能性:1.存在系統漏洞2.由於前期運維在伺服器上裝了一些工具軟體，會不會工具軟體引入的病毒3.應用層漏洞。

首先，用更新庫的漏掃對系統層面的漏洞檢測，未發現任何異常；

由於會有開發連接進這台伺服器，去開發那裡收集工具軟體進行查毒處理，也沒發現異常，排除通過軟體帶入病毒的可能；那難道是通過應用層漏洞進來的？

因為系統上線前都會經過web滲透測試，文件上傳，SQL注入等常規漏洞已經修復，雖然這樣，還是重新驗證了一遍漏洞，沒有問題，又用D盾webshell檢測工具進行了掃面，未發現任何webshell。

那病毒是怎麼產生的？

溯源準備

由於病毒無法清乾淨，也不清楚黑客是已經在機器上做了哪些手腳，於是重新搭建一個乾淨的環境，給系統打好最新的補丁。

由於前期沒有在主機端做日誌收集類工具，缺乏主機端的攻擊溯源手段，於是臨時搭建了splunk日誌分析系統，並在新搭建的伺服器上安裝了sysmon日誌收集工具，對主機層面進行了日誌收集。

過了一星期左右，小Z發現系統進程裡面居然多了個叫wcmoye的進程，憑感覺這不是個正常程序，那就先從這個程序開始入手調查吧。

常規排查

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

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

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

進程依賴於StuvwxAbcdefgh Jkl這個服務

網路通信：用tcpview觀察wcmoye.exe會不定時連接一公網ip的9999埠

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

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

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

0×4 日誌排查

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

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

不急，進一步搜索NewRat，發現了更大的信息量:在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 順藤摸瓜

帶著好奇心，繼續探索過程，直接進入了這個ftp伺服器!

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

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

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

start.bat開始看吧

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

Linux平台的腳本：關閉防火牆，下載一個叫tatada的ELF文件，把netstat等系統命令改名，清空日誌等等

Result.txt文件，記錄著一些掃描到的ip的埠開放情況

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

而且其中有一個關鍵的發現，就是所在公司的網站介面居然在一個叫http.txt的list裡面

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

S.exe就是掃描器

IDA載入str045

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

0×6 網路架構

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

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

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

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

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

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

0×7 水落石出

NewRat也是在那個奇怪的日誌後產生的，這時一個念頭閃現在腦海里，還是用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 結尾

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