0x01 應急響應概述
首先我們來了解一下兩個概念：應急響應和安全建設，這兩者的區別就是應急響應是被動響應、安全建設是主動防禦。
所謂有因才有果，既然是被動的，那麼我們在應急響應的時候就得先了解本次安全事件的起因，常見的有：
安全裝置告警、資料被勒索加密、資料洩露在網上販賣、網頁被篡改、伺服器CPU爆滿卡死等。
在應急響應的時候，你會發現一個非常有用的經驗技巧，就是：一旦你能夠確定本次安全事件的型別，猜測出攻擊者或者惡意程式碼的攻擊思路，然後去驗證排查這些猜想，就會加速你的分析過程，而這些從事件起因中就能夠獲取到一些資訊。
0x02 應急響應目的
我們在應急響應時大致有以下幾個目的：
遏制事件發酵、找到惡意程式碼、分析入侵路徑、整理入侵時間線、分析惡意程式碼行為以及追蹤溯源。
而一般中間的四個為安全人員需要解決的主要任務：
- 找到惡意程式碼：通過各種動靜態分析找到惡意程式碼、感染檔案，進行取樣然後清除。
- 分析入侵路徑、入侵時間線：結合各類日誌以及惡意程式碼本身，將有關證據進行關聯分析，構造證據鏈，重現攻擊過程。
- 分析惡意程式碼：找到惡意程式的特徵，包括行為、釋放的檔案、網路通訊等，從而得到識別、防禦和刪除該病毒的方法，使得我們的其他機器能夠防得住該惡意程式的攻擊。
- 解決問題，根除隱患，分析導致事故發生的系統脆弱點，並採取補救措施，恢復系統，使系統正常執行
追蹤溯源不太現實，一般只追溯到攻擊IP，這部分更多的是根據前面四個部分刻畫出來的攻擊者畫像去搜尋相關的威脅情
報。
0x03 應急響應流程
應急事件處理流程一般包括：安全事件報警、安全事件確認、啟動應急預案、安全事件處理、撰寫安全事件報告、應急工作總結等步驟。
這個是完整的應急流程，如果是甲方安全人員，一般就是按照這個流程進行應急。而乙方的應急響應，主要是在安全事件處理階段，也就是應急響應，以及最後的撰寫安全事件報告，應急響應第一步要先遏制影響，這個根據安全事件造成的影響大致有以下幾種方式：
- 網站下線（篡改、掛反標）
- 斷網隔離（遠控後門、APT）
- 流量清洗（DOS的進行）
- 聯絡運營商（劫持類）
注意：斷網隔離不是關機重啟，電腦重啟將會使記憶體丟失。
當然遏制影響一般在我們之前運維人員就會採取相關的措施了，我們負責的是之後進行的安全事件處理以及撰寫安全事件報告。我是屬於乙方的應急，所以後面都是以乙方安全人員的應急響應來講，主要的兩個階段：一個是安全事件處理，也就是應急響應：主要工作就是取證、溯源，這個我們後面詳細講。另外一個就是撰寫安全事件報告，一般的安全事件報告包括如下內容：
安全事件發生的日期時間
參加人員
事件發現的途徑
事件型別
事件涉及的範圍
現場記錄
事件導致的損失和影響
事件處理的過程
從本次事故中應該吸取的經驗和教訓
0x04 應急響應思路
整個應急響應都是建立在惡意程式碼的基礎上的，那麼我們第一步就是找到惡意程式碼，針對常見的安全事件，結合工作中應急響應事件分析和解決的方法，總結了常規的入侵排查的檢查思路。
檢查思路：
惡意程式需要進行網路通訊，記憶體中必然有其二進位制程式碼，它要麼是程式的 DLL /so模組，通常為了保活，它極可能還有自己的啟動項，網路心跳包。
總之，可以歸結為如下 4 點要素：網路連線，程式，啟動項，記憶體再加上外部資訊，如威脅情報，就可以形成比較完整的證據鏈。
檢查方向：
找到各種可疑的IP、程式、域名、URL，搜尋相關的IOC，然後排查相關特徵。
- 網路連線
- 程式資訊
- 系統啟動項
- 賬號情況
- 日誌資訊
- 其他
現場分析：
當發生安全事件時，我們去到現場首先需要先了解一些外部資訊：
問題主機/伺服器使用人員有誰？
一般使用時間段是什麼時候？
是否重啟過
檢視防毒軟體、防護軟體的查殺、隔離、告警日誌。（如果有）
各種服務應用如：FTP、SSH、資料庫、RDP，是否攻擊者開啟及是否存在弱口令。
網路中是否有防火牆、行為管理器等防禦裝置，檢視相應告警。
一些安全人員去到現場後就直奔問題主機去了，然後各種分析，忽略了這些資訊，因此列出來做個記錄。
0x05 取證溯源
前面分析完思路以及記錄需要了解到的一些外部資訊，都是為了我們的關鍵環節取證溯源做準備。當然思路歸思路，由於安全漏洞不是存在於特定的場景或應用，Web應用可能存在漏洞、軟體程式可能存在漏洞、我們使用的作業系統也可能存在漏洞，因此實際的安全事件，我們需要儘可能的檢查到每一個薄弱點。而不是網頁篡改就只檢查web應用、挖礦木馬就只排查惡意程式。
檢查得越多（做好記錄），後面整理報告的時候越有用，經常遇到的是應急只有幾個小時的，然後沒有做好記錄回去無法寫報告，只能再找客戶聯絡。
5.1 網路連線
網路連線一般適用於遠控後門類的應急事件，這類事件的相同點就是有持續或半持續性的網路連接。一般是找境外IP或不常見埠。有時也會是惡意域名。常用工具：TCPview、火絨劍、DNSquerysniffer、apateDNS、Wireshark
舉例：
異常埠（圖中工具-TCPview）
異常路徑（圖中工具-火絨劍）
Dll發起網路連線，本身沒有什麼異常，但是從這個dll檔案的路徑，我們還是可以判斷出這個dll是有問題的。
域名解析
網路連線還有一種情況，就是域名解析記錄，有時候我們在安全裝置上發現的告警，是某一臺裝置請求了某個域名，而這個域名是已經沒有在用的了，也就是說不會解析成功，這個時候我們是看不到又任何的網路連線情況的，那麼我們就需要檢視本地的域名解析記錄，這裡我們使用DNSQuerySniffer來檢視。
PS：結合火絨劍或者PChunter即可定位到具體程式。
5.2 程式資訊
病毒檔案在系統中執行必定依賴於可執行程式，主要有三種模式在系統中執行：
- 病毒本身是exe程式
- 注入到系統程式
- 其他方式
思路：重點檢查沒有廠商名字、沒有簽名驗證資訊、沒有描述資訊、CPU 或記憶體資源佔用長時間過高的程式。檢查可疑程式的屬主、路徑、引數是否合法。常規的使用命令tasklist
工具：Process Explorer、火絨劍、PChunter
下面是我之前做的一個測試，用MSF生成的一個後門程式：yu.exe，可以看到，這個程式與正常的程式，少了廠商資訊、沒有簽名、也沒有描述資訊。通過這些對比，我們就可以快速的篩選出一些的程式，然後再分析這些程式載入了什麼dll、使用了什麼模組，分析是否存在異常，從而判斷該程式是否為一個惡意的程式。
下面就用這幾個工具，來講一下應急響應中我們如何排除一個程式是否是惡意程式。
- 5.2.1 Process Explorer
程式瀏覽器，列出所有當前活躍的程式、被程式載入的DLL、各種程式屬性和整體系統資訊。
主要用於：檢視程式的簽名資訊、程式的字串資訊、搜尋載入惡意DLL的程式、分析惡意文件、通過屬性視窗中的映象（Image）標籤來定位惡意程式碼在磁碟上的位置。
1. 檢視程式載入的dll檔案：
然後有個可以快速判斷載入的dll檔案是否正常的辦法，就是路徑。正常的dll檔案都是在C:\Windows\System32目錄下，當然還有其他幾個系統目錄，我們要找的就是路徑不對，名稱可疑的。路徑不對可以很直觀的看出來，但是有時候路徑沒錯，然後名稱是不對的，比如正常的是Kernel32.dll。然後惡意程式把自己的dll檔案命名為Kerne132.dll。
2. 檢視程式中的字串資訊：
有時候程式的網路通訊是間歇性的，所以有可能在我們檢視的時候他是正常的，而到了特定的時間他才會執行相應的網路請求。這個時候我們可以看一下這個程式的字串資訊，在字串資訊中，我們有時候可以看到程式呼叫的Windows API函式和一些IP、URL，或者一些命令列的提示資訊，通過看到的一些api函式，來猜測這個程式的功能：比如寫入登錄檔、遍歷檔案目錄、建立程式等。
- 5.2.2 PChunter
這個是一個比較底層的工具，可以看到程式啟動的引數。
用得比較多的是用於查詢隱藏的檔案和目錄。
- 5.2.3 火絨劍
這裡利用火絨劍檢視這個svchost載入的dll檔案，可以看到有兩個異常的dll檔案，雖然有公司名和描述，但是這個描述額、、有點隨意，而且查這兩個dll檔案的路徑，在Windows的tmep資料夾下，那麼我們也可以猜測這兩個dll檔案是惡意的dll檔案。
實驗測試：程式注入
以MSF生成的後門程式為例，使用MSF程式注入功能，利用migrate命令將後門注入到其他程式：
TCPView檢測網路連線，根據可疑程式名和可疑網路連線可以定位到meterpreter後門程式：
但是查詢對應的PID找不到相應的程式：
這個時候可以使用PCHunter，這個比較底層的工具。查詢對應網路連線可以直接查到對應程式路徑：
載入後，你可以開始搜尋Meterpreter使用的關鍵指標，如ws2_32.dll和metsrv.dll。ws2_32.dll是用於處理網路連線的Window Sockets Library，而metsrv.dll是預設的Meterpreter服務。這兩個dll是用於網路連線的，而everything這個程式是沒有網路連線的，但是卻呼叫了這兩個dll檔案，那麼就有問題了。
針對MSF的後門，這裡再推薦一款工具：Meterpreter_Payload_Detection.exe，可自行在GitHub上搜尋下載。
利用Meterpreter_Payload_Detection.exe檢測工具，通過掃描記憶體檢測Meterpreter無法檢測的有效負載。缺點就是執行時間比較久。
5.3 啟動項
思路：檢查啟動項、計劃任務、服務
這個我一般就檢查三個地方：
1.【開始】>【所有程式】>【啟動】:
2. 計算機管理:
3. gpedit.msc:
檢查啟動項這裡推薦使用Autorun這款工具，上面的檢查項都可以用這個工具檢視到，只是一些啟動項的路徑還是需要大家熟悉一下，因此還是講一遍：
可以看到，利用這個工具，我們能直觀的看到啟動項執行的命令、啟動的指令碼、引數等。
0x06 需要取證的點
1、系統日誌、網站訪問日誌（搜尋log檔案）、本地使用者情況（是否有隱藏、克隆使用者）。
2、儲存系統當前資訊：
systeminfo >c:\Temp\sysinfo.txt
netstat -ano >c:\Temp\net.txt
tasklist >c:\Temp\task.txt
net user >c:\Temp\user.txt
xcopy %systemroot%\system32\winevt\logs\* C:\Temp\eventlog
3、使用Process Monitor、Autorun、Tcpview等工具，儲存記錄檔案。PClog和Process Explorer選擇性儲存。
可在現場簡單檢查，把可疑的程式打包回來分析。
4、檢查webshell結果（最好能把網站整個資料夾拷貝回來）。
因為jsp後門刪除了還會有.class快取保留，命名方式為_xx__jsp.class，可恢復。
5、系統記憶體、映象
Readline、DumpIt（這兩個都是適用於低記憶體系統）,電腦重啟將會使記憶體丟失。
將以上幾個需要取證的資料打包回來事後分析。
☆注意：所有軟體都必須以管理員身份執行。
最終，我們在一次應急響應中需要拷貝回來取證的有如下檔案（包括但不限於）：
日誌如果被刪，建議整個資料夾拷貝回來。
笨鳥先飛早入林，笨人勤學早成材。
轉載請註明出處：
撰寫人：fox-yu http://www.cnblogs.com/fox-yu/