0x00 前言
在我們日常運維中，難免有幾個網站或者主機被入侵，這時就出現應急響應需求。那麼我們應該怎樣着手分析暱？本文將爲你細細道來，其中由於都是文字描述思路，所以各位要有耐心讀完全文。但是這個思路分析講解得非常詳細，按部就班，一步一步描述了整個取證分析過程。
0x01 Webshell入侵的取證
1取證的環境
①被其他第三方通知，AA網站被種植了後門
②管理員提供了打包後的源碼及日誌
2 調查的工作
①清除掉網站上所有的webshell
②查找攻擊者的入侵途徑，並找到攻擊者的ip地址
③分析網站存在的安全問題，並且提供加固建議
3 取證思路
1 查看各種配置文件
2 確定受到攻擊的ipABCD所屬的主機是內外網的Linux/windows主機，運行什麼業務等
3 收集該ABCD服務器上有 Web服務，例如Apache、strut2、spring；jboss，WebLogic、WebSphere等
4 抽取server.xml文件 查看jboss的應用程序訪問日誌記錄、server.log
5 查看jboss/server/default/tmp 文件夾 看看是否有XX.war 之類的文件，如果有，該文件就是webshell
6 查看jboss/server/default//work/JBoss-web/localhost 文件夾，查看是否有Java寫的webshell會留有相對應的.java、.class文件
7 查看jboss/server/default//deploy/upload 和其他文件夾是否有 webshell
8 注意事項
一些webshell的名字 和 真正的文件名 非常相似，注意識別webshell的迷惑手段
一些webshell是XX.jar格式的，這是一個可以逃避很多殺軟的反射型webshell。
一些webshell是以jboss匿名訪問漏洞直接上傳的war包，所以重啓是不會自動刪除的
9 我們查看其他文件夾裏的文件，發現ls-sl，目測這是攻擊者遺留的linux後門.
10 於是放在kali虛擬機裏運行，netstat -an進行監控，看到了一個異常的ip，估計是攻擊者的ip
0x02 webshell 取證總結
1、在沒有日誌的情況下，本文可以通過其它手段查到攻擊者的蛛絲馬跡的。例如攻擊者遺留的webshell
2、畢竟不同的攻擊者有不同的入侵思路，所使用的webshell也有很大差別，故常見的.jsp和.war格式，甚至一個反射型後門。
3、有時當網站遭受入侵時，請告知管理員不要急於刪除後門，
4、應該及時聯繫網絡安全人員到場協助處理。
0x03 主機入侵取證
1 取證的環境
①某主機cpu佔用至100%並出現可疑進程或者不斷向外發送大流量。
②主機未限制端口訪問，ssh端口暴露外網，可以訪問
③外部大量ip在特定時間對主機進行暴力破解，並且有些成功登錄記錄
2 調查的工作
①清除掉主機上的後門
②找出攻擊者成功安裝後門的原因
③分析主機存在的安全問題，並且提供加固建議
3 取證思路
1 登入主機後，找到可疑進程PID
2 進入proc/進程目錄找到對應文件絕對路徑在/usr/bin目錄下，stat /usr/bin/malicious_file
3 找出該文件的執行時間和權限
4 通過strings查看文件內容發現遠程ip及其他信息
5 搜索ip發現爲某個地方主機，通過google、whois等信息收集工具，進行信息收集
6 首先要判斷攻擊者通過什麼途徑入侵
一、服務器運行了web、ftp服務，但非root權限
二、last並未發現異常登錄信息、history未發現可疑操作、且默認ssh端口禁止對外開放，故忽視了ssh入侵的判斷
三、服務器存在bash漏洞，導致懷疑是bash漏洞+提權、但未發現可疑的accesslog
四、此前stat文件判斷時間有誤，事後發現管理員之前有kill程序進程操作，進程結束後會刪除自身並生成新的文件，所以stat到的時間信息其實是管理員kill進程的時間
7ddos後門通過ssh暴力破解方式傳播， 排查secure日誌，攻擊者使用一臺主機進行暴力破解，破解成功後，再使用其他主機進行SSH登錄
8 查看cron日誌發現每隔一段時間，系統會執行兩個惡意腳本
9 查看cron.sh文件內容
我們發現 其中/lib/libgcc.so通過文件大小及strings部分內容基本確定與/usr/bin下的惡意程序ohzxttdhqk相同；其中/lib/libgcc4.so通過文件大小及strings部分內容基本確定與/usr/bin下的惡意程序faksiubbri相同。
10 查看暴力破解的時間 和contab 執行任務的時間
查看secure日誌，取之前發現ip成功驗證ssh至斷開連接時間差
11 其他疑點
驗證發現通過scp遠程拷貝文件至主機與ssh登錄後退出都會產生Received disconnect的日誌
如果通過ssh自動化部署，last爲何會看不到記錄？
是否單獨清除了相關記錄？
如果是scp遠程拷貝，是通過什麼方式執行程序的？
目前暫不知曉通過何種方式可以僅將文件放入機器後可以讓程序自動執行，是否還有其他部署方式？
0x04 主機修復建議
1 排查其他主機是否有重要端口對外
2 排查其他主機是否存在惡意文件，重點注意以下幾點：
①/etc/init.d/目錄下是否存在10位隨機字母文件名的文件
②/etc/rc%d.d/S90+10位隨機字母文件名的文件（%d爲0-5數字）
③是否存在/etc/cron.hourly/udev.sh
④是否存在/etc/ cron.hourly/cron.sh
⑤/etc/crontab中是否存在可疑計劃任務
⑥/usr/bin目錄下是否存在10位隨機字母文件名的文件
3 修復主機bash漏洞
4 增加主機密碼複雜度（包括重要端口不對外主機）
5 針對異常情況主機，安全人員排查前儘量不要有操作，如果需要對文件有操作，一定要先保存stat信息結果，備份文件內容，修改密碼/新建賬戶/刪除賬戶前一定要先stat /etc/passwd與stat /etc/shadow並保存執行結果
0x05 入侵總結
在分析過程陷入瓶頸的時候，應該以多看各類日誌爲主。
一 web類入侵事件
1、記錄後門文件stat信息，判斷入侵發生時間，另外需要與accesslog做對比，判斷是否爲第一個後門。
2、查找入侵者放置的其他後門可通過已知後門文件的mtime、文件內容等可作爲特徵查找，也可以與svn、此前備份文件做比對或者打包web目錄文件使用一些webshell查殺軟件。
3、查找一天內修改過的文件命令#find /home/work –mtime -1 –type f
4、查找系統中包含指定字符的所有文件（可以拿已知shell密碼及特定字符作爲關鍵字）
#find /|xargs grep -ri "Bot1234" -l 2>/dev/null（執行後會改變所有文件的atime)
5、查看較大的日誌文件時，先通過grep指定字符篩選，比如已知shell文件爲conf.PHP,可使用命令
#fgrep –a ‘conf.php’ accesslog > conf_access
來篩選conf.php的訪問記錄.如果爲一些高危漏洞，也可根據漏洞利用的關鍵字來篩選，通過第一步篩選結果後可找出入侵者ip等信息，可繼續通過這些信息在accesslog中找到攻擊者的所有訪問記錄以便進一步排查
6、判斷影響時，當webshell操作爲post且無流量鏡像時，判斷一些敏感文件如源碼打包文件、包含密碼信息文件是否被讀取可通過文件atime信息來判斷，此外對webshell的請求條數以及返回的字節數都可以作爲定損的大概依據
二、非web方式入侵
主要通過其他高危服，主要結合syslog判斷
1、判斷服務器是否支持訪問外網，如支持，通過netstat –an查看是否已與外部可疑服務器建立連接，如已建立需及時斷開
2、記錄後門文件stat信息，根據mtime查找其他後門文件，同時根據文件屬組與屬組對應運行服務判斷入侵方式
3、如果權限組爲root，需要檢測是否被種rootkit，rootkit檢測可使用rkhunter：http://rkhunter.sourceforge.NET/
4、非web類後門，大部分人習慣把惡意文件放置在/tmp目錄下，此外可通過可疑進程名與cpu佔用率排查，有些後門會僞裝正常進程名，但是top命令可通過cpu佔用率找出後門進程，獲取進程pid後可cd到/proc/對應pid目錄，ls –al查看exe對應值可得知文件路徑，另外可查看計劃任務，後門程序爲保證自啓動往往會添加新的計劃任務。
歡迎大家補充各種案例和分享各種思路 ^^_^^
