很不幸，你在自己的電腦里發現了一個惡意的可執行程序！那么問題來了：這個文件到底有沒有執行過?
在這篇文章中，我們會將注意力放在Windows操作系統的靜態取證分析之上，并跟大家討論一些能夠幫助你回答上面那個問題的方法以及證據源，其中涉及到的四大主要的證據源包括Windows Prefetch、注冊表、日志文件以及文件信息。
Windows Prefetch
Windows Prefetch（Windows 預讀取）是一個查找文件執行證據的好地方。根據微軟的設計方案，Windows Prefetch的功能就是允許那些經常需要使用到的程序打開得更加快。默認設置下，它會在預讀取文件（存儲路徑為”C:\WindowsPrefetch”）中存儲最近執行的128個文件的信息。一個預讀取文件的命名規則為”可執行文件名+文件路徑的哈希+后綴名.pf”，預讀取文件中會保存文件的第一次和最后一次運行日期、文件路徑和執行次數等信息。所以說，如果你的惡意軟件文件名或路徑哈希出現在了一個預讀取文件（例如” DABEARS.EXE-12F3B52A.pf”）之中，那就說明這個惡意文件曾在你的電腦中執行過了。
注：Windows Server默認禁用了預讀取功能。
注冊表
沒錯，Windows注冊表可是一個巨大的“寶藏”，注冊表可以算是Windows系統能夠正常運行的基石了。雖然注冊表非常“龐大”，但是我們接下來給出的表單卻并沒有那么復雜。因為如果要確定一個文件是否執行過，我們只需要檢查幾個重要的注冊表鍵即可：
1. ShimCache
微軟使用了ShimCache或“AppCompatCache”來識別應用程序的兼容性問題。緩存數據能夠追蹤文件路徑、大小、最后修改時間和最后一次運行的時間。如果一個文件以Windows進程的形式執行過，那么它的信息將會被記錄到ShimCache中，但是ShimCache中記錄的文件信息并不能100%證明一個文件執行過，因為它只能證明Windows曾與該文件交互過。下面這個注冊表鍵中包含了ShimCache數據：
HKLMSYSTEMCurrentControlSetControlSessionManagerAppCompatibilityAppCompatCache(for XP)
HKLMSYSTEMCurrentControlSetControlSessionManagerAppCompatCacheAppCompatCache(for Non-XP)
更多關于ShimCache的內容，請參考Andrew Davis的【這篇文章】以及Mandiants的【會議報告】。
2. MUICache
當一個文件通過Windows Explorer（資源管理器）運行，程序Shell會在MUICache中創建一個入口。Windows使用MUICache來存儲應用程序名以及其他相關信息，獲取來的信息主要存儲在下面的注冊表鍵中：
HKCUSoftwareMicrosoftWindowsShellNoRoamMUICache(for XP, 2000, 2003)
HKCUSoftwareClassesLocal SettingsSoftwareMicrosoftWindowsShellMuiCache(for Vista, 7, 2008)
關于MUICache的更多內容，請參考windowsir的【這篇文章】。
3. UserAssist
UserAssist可以追蹤可執行程序以及資源管理器中打開的鏈接，UserAssist鍵能夠追蹤文件的最后一次執行時間以及執行次數，并將信息存儲在下面這個注冊表鍵中：
HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist
UserAssist鍵的值對應了可執行程序的名稱以及文件路徑，并使用了ROT13加密。因此，如果你想直接通過搜索關鍵字來查找文件執行的證據的話，在不解碼的情況下是無法做到的。目前也有很多工具可以解密這個注冊表鍵，例如RegRipper userassist.pl插件【點我獲取】。
日志文件
為了確定一個文件是否執行過，我們還可以根據日志文件的分析結果來判斷。首先我們來看一看Windows System Event Log（系統事件日志），因為這個日志文件記錄了服務的啟動信息。下圖顯示的事件（Event ID=”7035″）信息表明，一個管理員（SID=”-500″）運行了PSEXECSVC遠程執行服務：
當一個服務啟動時，它通常會執行ImagePath中定義的文件或一個已加載的服務DLL。比如說，”Netman”服務在執行時使用了一個合法文件”netman.dll”。但是，如果注冊表中的ServiceDll（例如”tabcteng.dll”）包含一條指向后門的路徑，那么”Netman”服務將會執行”tabcteng.dll”。所以，你可以通過分析ImagePath和ServiceDll的有效性來判斷是否有惡意服務啟動過。
如果Windows Event Log（事件日志）的審計設置開啟了Audit Process Tracking（審計進程追蹤）功能，那么Windows Security Event Log（安全事件日志）中將會記錄大量關于進程的信息，而這些信息絕對能夠證明一個文件是否執行過。下面這兩張圖片顯示了惡意文件、相關進程ID、父進程ID和用戶名，這些信息可以幫助我們進行進一步分析：
XP EventID 592 – 進程創建：
Windows Vista+記錄下了類似的進程創建事件，EventID為4688：
在更新版本的Windows中，審計功能所能記錄的信息將更加精確化，并且微軟從Windows Server 2008 R2以及Windows 7中將這個功能整合到了Group Policy（組策略）中。關于審計策略設置的更多信息請參考微軟給出的【這份文檔】。
除此之外，基于主機的IPS或反病毒產品日志同樣可以表明一個文件是否執行過，或者曾經嘗試執行過。下圖給出的是McAfee Access Protection日志中記錄下的一次訪問事件樣本：
Windows Scheduled Task Log（計劃任務日志）可以幫助我們判斷攻擊者是否使用了Windows的計劃任務功能來運行惡意軟件。計劃任務的信息會被記錄在一個名叫”SchedLgU.txt”的日志文件中：
在Windows Vista+平臺中，計劃任務的執行信息還會記錄在”Microsoft-Windows-TaskScheduler/Operational”日志中：
最后，如果一個程序崩潰了，那么Dr.Watson日志可以記錄下惡意任務的運行信息：
文件功能
另一種判斷文件是否運行過的方法就是尋找可疑的輸出文件。當你在分析一個惡意文件時，它是否會創建任何的數據呢？比如說，如果你發現的這個惡意文件是一個鍵盤記錄器，然后你又在系統中發現了鍵盤記錄文件，則說明攻擊者已經執行過這個keylogger了。如果惡意軟件能夠與特定的域名進行鏈接，那么瀏覽器的歷史記錄中肯定也會記錄下相關域名。下表中顯示的是我們在瀏覽器歷史紀錄中捕捉到的樣本，這個后門樣本使用了兩種通訊機制：
想要判斷惡意文件是否執行過，我們可以分析文件的功能并在磁盤中尋找相應功能的運行結果/證據。分析惡意軟件的功能不僅可以幫助我們了解攻擊者的動機和最終目標，而且還有可能幫我們找出其他相關的惡意文件。
注：如果你在自己的系統中發現了惡意的可執行文件，別忘了先將當前系統內存中的數據導出，你可以使用MandiantRedline服務捕捉并分析內存數據。
| 
