【應急響應】Windows應急響應入門手冊
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 //www.cnblogs.com/fox-yu/
