某雲用戶網站入侵應急響應

新聞 05-17

*本文原創作者：feiniao，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

1、情況概述

該案例是前期應急處置的一起因安全問題導致的內網不穩定的情況。寫下來，和大家一起討論應急響應的一些思路及其中間遇到的一些坑，歡迎大牛指點、討論。

情況是這樣的：

某用戶發現在網路經常出現內網中斷的情況，經其內部分析，初步判定可能為其在雲上的一台虛擬伺服器(Linux)異常導致，但是前期對這台虛擬主機進行常規的安全檢查與數據包分析，並沒有發現其有異常情況。但是用戶發現只要這台虛擬主機接入網路就會不定期出現內網中斷。該伺服器對外只開放 ssh和80。用戶為保證其他伺服器的安全及可用性，把這台虛擬主機給下線了，但是這台虛擬主機是否存在異常？為什麼接入網路會導致中斷？在初步分析沒有結論的情況下，我方介入協助分析。

2、整體分析

2.1 數據包分析

與183.61.171.154異常交互

我方介入後，根據實際情況，將這台異常虛擬主機全部拷備放到一台暫時沒有使用的伺服器中，前期考慮可能是發送惡意報文導致某用戶內網伺服器中斷，所以前期採用的方法是對這台虛擬機的流量進行抓取分析，但是在抓取一段時間後，並沒發現異常。考慮到可能是不定期發包，因此決定進行長期抓包與系統全面分析的方法進行分析。下面是我方進行抓包分析情況：

抓了近兩天的數據包，總共包大小為75.3M，從數量上看，包的數量相對較少，應該沒有進行大流量攻擊行為。繼續深入分析數據包:

從數據包中發現有一處報文交互存在可疑，對其深入分析，發現在2016年10月27日13:55:50時這台虛擬主機主動外連183.61.171.154這台主機的5896埠，並下載了一下bc.pl的文件，其源埠為37568，但是由於分析時，該埠已無會話信息，所以無法分析當時是哪個進程。下面是這個過程的情況：

報文交互過程

交互信息

文件存放路徑

對bc.pl文件查看，其源碼如下：

bc.pl源碼

根據源碼分析，其使用有socket函數，並定義一些remoet_ip,remote_port等關鍵字，初步判定其為一個進行遠程控制用的惡意遠控程序的部分文件。

對183.61.171.154這個目的IP進行分析，發現其存在被殭屍網路控制等情況，這台主機可能並不是真正的原始攻擊者，攻擊者通過這台主機作為跳板來攻擊其他主機。但是我們對這個 IP的分析，可以證明上面的會話的確存在異常。

對其反向DNS解析，分析曾經有哪些域名掛在這個IP上，可以看出這個IP。

頻繁的更換其對應域名，說明這個IP對應的主機可能早已被黑客控制，用來進行黑客行為。下面是其反向DNS信息匯總：

繼續深入分析，看看183.61.171.154這台主機上是否存在惡意文件，通過下圖可以看出183.61.171.154這台主機存在較多惡意腳本。

183.61.171.154存在惡意樣本分析

通過上面分析，可以看出183.61.171.154這台存在惡意腳本，判斷為被黑客控制的機器，黑客使用這台作為跳板來入侵其他設備，因此某用戶外連這台主機並下載bc.pl 這個文件，通過各方面綜合分析，判定 bc.pl是一個用來進行遠程控制的惡意文件。

與65.118.123.162異常交互

直接分析HTTP數據包，發現除了上面介紹下載的bc.pl文件以外，還有大量的 HTTP 請求，請求的內容都為外連一個pl文件。

異常交互情況

提取相關信息，匯總如下：

上圖可以看出65.118.123.162這個IP存在被殭屍網路及威脅流量的情況。和上方一樣，這個 IP 可能也不是黑客真實的IP，黑客控制這台主機，然後再通過 65.118.123.162這台作為跳板，再入侵其他設備。

繼續對65.118.123.162深入分析，反向DNS查看一下，可以看出這台主機位於美國，並且其域名在不斷變更。

通過上文，我們可以看出某用戶的這台伺服器不定期與65.118.123.162這個存在被殭屍網路控制的主機進行交互，並且都是Get 其一個 pl文件。通過對目標主機進行分析，判斷該會話為惡意交互，但是因為抓包時，沒有及時分析該埠所對應的進程，所以暫時沒有辦法分析是哪個程序導致。後期如果需要分析，可以進行實時抓包，找到該埠號所對應的進程，然後把該進程殺掉即可。

2.2 可疑文件分析

根據上面的分析，發現在

bc.pl存放在/tmp目錄下，對這個目錄下的分析進行分析，發現幾個可疑文件：

直接cat這個文件，可以發現一些很有意思的事情：

1. 直接把主機防火牆關閉

2. 從123.249.7.198:8831上下載 123這個文件

3. 賦予123這個文件 777 的許可權

4. 執行123這個文件

這裡面可以看到黑客通過這個腳本下載並執行123這個文件，如果存在123這個文件，可以說明 cmd.n 這個文件是有執行的許可權的，但是通過上文我們可以看到cmd.n這個文件並沒有執行的許可權，這可能是黑客相對聰明的地方，執行完以後把這個文件降點許可權。一方面可以迷惑分析者，另一方面不會被其他黑客來控制。我們接著來分析，既然黑客下載並執行了 123 這個文件，那麼在系統中肯定存在這個文件，我們來查找一下：

查找找到123這個文件，在根目錄中，直接進根目錄中查找分析，發現除了123這個文件，還有 1 、123123、 1253這三個文件名非常類似，但是 123這個文件 cat不了，直接下載下來，丟到分析平台中分析。

可疑文件

通過殺軟平台分析，基本上判定該文檔存在病毒：

殺毒分析情況

同樣，對其他文件進行查殺，結果如下：

運行進程分析

對10月17號這段時間上傳的文件進行導出分析，發現另外一個文件 conf.n ，通過上傳時間分析，其也是10月 17日 1點 25分上傳上去的。在這段時間上傳有兩個文件，一個為cmd.n，另一個為 conf.n ，已分析 cmd.n為一個異常文件，那麼我們推斷conf.n這個文件肯定也為惡意文件。

這個文件位於/usr/bin/bsd-port/目錄下，直接查看這個文件，發現文件做過特殊處理，無法直接查看。直接google 一下，看是否有相關資料，果然有被這個馬搞過的案例。至此，我們已經沒有必要繼續分析了，基本上可以判定 conf.n 是一個惡意文件。

Linux conf.n木馬

繼續看看其他目錄是否還有conf.n這個文件，一共找到四處存在，其中兩處我們已經分析過了，另外兩處做了初步分析，基本上判定也為異常文件，建議直接殺掉。

那麼黑客是如何上傳這幾個惡意腳本的呢？目前根據某用戶具體情況，要麼是系統，要麼是網站。下面我們來對系統和網站進行全面分析。

2.3 用戶系統分析

對系統用戶進行分析，某用戶這台伺服器一共存在

39個賬號，對其賬號、許可權、組等進行分析，初步判定沒有賬號異常情況。

/etc/passwd文件分析

/etc/shadow文件分析

2.4 webshell分析

系統層面沒有問題，那麼最大的可能性是網站了。針對網站最大的攻擊，主要是通過

webshell來上傳惡意文件。我們首先對webshell來進行分析：

使用webshell專殺工具對某用戶web伺服器的內容進行掃描，中間並沒有發現存在 webshell, 但是並不能說明某用戶的網站沒有存在過webshell，有的webshell具有自毀功能，並且通過上面分析，我們可以看到這台伺服器已經下載了 bc.pl 這個遠程控制腳本，通過這個腳本，黑客已經可以遠程控制這台伺服器了，根本不需要webshell了，這只是我們的推論，我們需要通過日誌分析來驗證我們的推論。

2.5 日誌分析

下面我們來對日誌進行分析，日誌包括兩部分，一部分為系統日誌，另一部分為網站日誌：

2.5.1 系統日誌

分析/var/log/secure文件，發現其系統日誌無異常。

2.5.2 對網站掃描

對weblogic的日誌進行分析，發現在8月31 號的時候172.17.4.179對這台伺服器的web服務進行漏洞掃描。但是因為做了 NAT ，分析到的源IP為內網IP，無法追溯到真實 IP地址。

2.5.3 10月17日日誌部分被清除

由於黑客上傳那幾個惡意文件的時間為10月17日，我們過濾這天的日誌來進行全面分析，看看是否從中可以找到蛛絲馬跡，但是當我們把時間定格在 1:25分左右的時候我們發現17號的日誌很大一部分被清除了。為什麼這段時間的日誌會被清除？我們不禁想到，黑客已經在這台伺服器上下載了用來進行遠程控制的腳本，已經不再需要webshell了，同時為了更好的隱藏及保護後續持續控制，黑客把webshell給清除。

另外，我們再輔助對系統會話，主機hosts、歷史命令進行分析，看看是否還有其他發現。

2.6 系統會話分析

對其正在建立的會話進行分析，我們主要分析基於

TCP的會話，發現目前存在三組TCP會話：

對這三組會話進行分析：

123.57.150.237

可以看出其程序為123這個程序調用，上文我們已經分析出123為一個病毒文件，因此該會話一定為異常交互。

208.185.115.120

165.254.12.197

後面這兩組都為clock-applet這個程序發起的，clocl-applet這個程序存在於 /usr/libexec 這個文件夾下面。

對後面兩組會話抓包分析，其交互過程如下所示，可以看出它們都是和weather.noaa.gov/cgi-bin/mgetmetar.pl這個文件交互，上文我們已經分析到和這個域名的交互情況，可以判斷該交互為異常交互。建議把 clock-applet 文件清除。

2.7 主機hosts文件分析

主機hosts文件用來靜態保存主機/域名對應的 IP 情況，默認情況下DNS解析時首先查DNS 緩存，然後再查本地 hosts文件，最後最進行 DNS解析。如果Hosts文件被篡改，很容易進行 DNS欺騙攻擊。對某用戶這台伺服器進行分析，並沒有發現 hosts文件存在異常。

2.8 歷史命令分析

History

命令集可以反映出當時黑客執行的命令情況，如果history從全部保存，可以很好的對入侵進行痕迹分析，對某用戶的歷史history命令進行分析，由於數據被覆蓋，所有並沒有發現黑客操作的痕迹。

部分History歷史命令集

3、入侵過程

經過近兩周的搭建環境、抓包與分析，基本上梳理清楚此次事件的來龍去脈。對此次事件的整個分析過程如下：

1、2016年10月 17日1點25，黑客上傳 conf.n 和cmd.n兩個惡意文件

2、黑客執行cmd.n並且下載123這個文件並且執行

3、123創建惡意進程，不斷連接一個mgtermetar.pl 文件，但是沒有連接成功。

4、本機主動外連並且下載bc.pl文件，這個文件為一個用來進行遠程控制的惡意文件。基本上判定該伺服器已被黑客控制

但是，黑客是通過什麼途徑上傳cmd.n和conf.n這兩個文件的？

上傳的途徑要麼通過系統，要麼通過網站。通過對系統日誌和系統用戶的初步分析，並沒有發現異常的情況。我們推斷為通過webshell來上傳這兩個文件的。雖然我們並沒有查殺出網站存在 webshell ，但是通過以下證據可以在側面驗證我們的推論：

? 對外只有兩個途徑可以上傳，系統和網站

? 系統分析，並沒發現異常

? 發現上傳這兩個文件當時的web日誌被清除

? 通過前期日誌分析發現存在很多針對網站的掃描行為

? 系統已經下載了可用來進行遠程控制的腳本，黑客無需再利用webshell，為了更好的隱藏及維持後期控制，把 webshell清除了。

那麼，分析至此，但是還存在一個問題：用戶反饋的是其內網經常中斷，似乎與分析的結論並不吻合。但是考慮到用戶的環境為雲環境，其帶寬、性能資源非常豐富，加上正常情況下，黑客入侵某一台伺服器後，大都會進行內網滲透，內網滲透的話可以中間人、掃描等方式，如果人間人或者掃描的話很大可能會導致其內網不穩定。當用戶把這台伺服器下線後，內網一直正常，正好吻合我們的猜測。

4、總結

1、處理此次事件中間遇到好多坑，如網站日誌被黑客刪除、沒有發現webshell、用戶的內網中斷現象偶爾出現等都是分析的難點。在應急的過程中經常會遇到這類問題，最多的就是 web 日誌只放在伺服器上，但是被黑客刪除了，這樣的話就為我們的分析取證帶來很多的難點。在遇到這類問題時，需要想方設法利用現有的資源去分析。

2、嚴謹推理、大膽猜測。在分析過程中遇到的各個斷點的情況，需要根據現有的資源進行大膽猜測。

3、連點成線，我們在分析時可能遇到最多的情況就是解決了一個一個的點，如發現存在webshell、存在可疑賬號、存在可疑IP 等，我們需要把這些一個一個的點連成一條線。

4、應急響應不是滲透測試，需要根據現有的信息分析黑客是利用什麼漏洞入侵的、入侵的IP、時間、並且入侵之後做了什麼等。因此我們在應急響應時不要搞反主次，把應急響應當成滲透測試。

5、應急響應分析不僅僅局限於web這一塊，系統這一塊同樣需要分析。如其賬號、連接、進程、安裝程序、自啟動程序等。

6、善用外部資源，如威脅情報、社工庫、開放的沙盒，用好外部資源可能會有意想不到的收穫。

7、歡迎大牛指點、討論。

*本文原創作者：feiniao，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載