Free Dropbox Forensics Tool
2011/07/05
標籤：
鑑識工具
Dropbox Reader is a set of Python scripts for forensic investigators. The scripts provide investigators with information about a particular Dropbox user's account and activities, such as the registration e-mail, Dropbox identifier and most recently changed files.
Dropbox Reader was created by Cybermarshal, the computer forensics wing of ATC-NY.
Here's a list and description of the tools from the product website:
轉自 http://www.readwriteweb.com/enterprise/2011/06/free-dropbox-forensics-tool.php
Dropbox Reader was created by Cybermarshal, the computer forensics wing of ATC-NY.
Here's a list and description of the tools from the product website:
- read_config script outputs the contents of the Dropbox config.db file in human-readable form. This includes the user's registered e-mail address and Dropbox identifier, software version information, and a list of the most-recently-changed files.
- read_filecache_config script outputs configuration information from the Dropbox filecache.db file. This includes information about shared directories that are attached to the user's Dropbox account.
- read_filejournal script outputs information about Dropbox synchronized files stored in the filecache.db file. This includes local and server-side metadata and a list of block hashes for each Dropbox-synchronized file.
- read_sigstore script outputs information from the Dropbox sigstore.db file, which is an additional source of block hashes.
- hash_blocks script produces a block hash list for any file. This block hash list can be compared to the block hashes from read_filejournal or read_sigstore.
- dropbox_contains_file script hashes one or more files (as per hash_blocks) and compares the resulting block hash list to the files listed in filecache.db (as per read_filejournal) and reports whether the files are partially or exactly the same as any Dropbox-synchronized files.
轉自 http://www.readwriteweb.com/enterprise/2011/06/free-dropbox-forensics-tool.php
Windows平台下的安全事件處理
引用來源：Windows平台下的安全事件處理
作者：沈志昌／林敬皇
摘要
當 我們使用的 Windows 系統環境中遭遇安全性事件時，我們如何準備事件回應及保留相關證據。本文將逐一說明在 Windows 系統環境中如何準備事件的處理、證據的蒐集與保留及保護等，並以 Guideline 的方式引導您了解 Windows 平台下的安全事件如何處理。
當 我們使用的 Windows 系統環境中遭遇安全性事件時，我們如何準備事件回應及保留相關證據。本文將逐一說明在 Windows 系統環境中如何準備事件的處理、證據的蒐集與保留及保護等，並以 Guideline 的方式引導您了解 Windows 平台下的安全事件如何處理。
一、前言隨 著網際網路的逐漸普遍，為人類帶來許多生活上的改變，相對的網路入侵事件日益頻繁，無論您的使用平台為何，都免除不了遭受入侵的威脅，從電腦安全的觀點 來看，完整的建築保護電腦的工事，是第一要務，然而，在資安界流傳「最安全的網路環境，是不接上網路的單機作業」，這說明了，不論怎樣維護安全的網路環 境，還是難免有漏洞，除了完整的防護措施外，如何有效發現及發現入侵後如何應變，也是相當需要重視的一環。因此，本文的重點在於，如何在充滿威脅的環境 下，能夠有效的發現異常情況且能進一步蒐集與提出相關證據，以利於安全人員作有效的處理，甚至涉及相關法律處理程序時，作為協助辦案的佐證。
當 您發現系統遭受入侵且可能有資料被盜失，大多數人的反應是希望儘快恢復成原先的正常運作狀況，且進一步找出破壞 者，但在處理這些事件時，最常見的處理方法就是直接拔除網路線，接著系統重新安裝系統，這樣的動作似乎可以順利完成問題的排除，然而，在電腦犯罪日漸囂張 的今日，除了恢復系統外，更需將您的重點放置於入侵軌跡及犯罪證據的蒐集。因此，無論是個人、企業組織都應在處理資安問題時，將此列入資安政策（ policy ）內。
瞭解蒐證的必要性後，如何有效的蒐集及回報資訊，也是的另一重點。不同的入侵行為會產生不同的記錄及影響，資安事件回報機制就是在此背景下產生的，國內常見的資安事件回報機制，政府等公務單位有國家資通安全技術服務中心（簡稱 ICST ）的資訊安全事件回報系統，而民間單位則有台灣電腦網路危機處理暨協調中心（簡稱 TWCERT/CC ）的安全事件回報機制，透過這些回報機制及單位，可以將您所遭受的入侵行為或是攻擊行為透過這些組織來幫您與對方的 ISP 進行反應，若判定為惡意行為，也可依據通報的紀錄，考量將處理的層級提升至相關的法律行動。因此，如何有效的保留資訊及通知問題處理單位，就成了處理資安 問題的首要任務。本文的目的即在提供資安事件蒐證工具建議，並且說明如何有效的使用這些工具來取得 MS-Windows 系統安全事件相關證據，，提供相關安全事件回報機制及單位的處理者最詳細的資訊，以順利解決您的資安事件。
二、入侵應變
入 侵應變階段是在發現異常情形時，從有限的主機資訊中提存有關資訊安全事件的行動，內容包含可能所發生的損害或是影響程度，這是所有處理資安事件的第一階 段，接著即是應變的實行，依照組織內的資安策略，決定是否繼續監控，或是需要離線修復之工作。在入侵應變階段，通常需要注意 5W1H 原則：
入 侵應變階段是在發現異常情形時，從有限的主機資訊中提存有關資訊安全事件的行動，內容包含可能所發生的損害或是影響程度，這是所有處理資安事件的第一階 段，接著即是應變的實行，依照組織內的資安策略，決定是否繼續監控，或是需要離線修復之工作。在入侵應變階段，通常需要注意 5W1H 原則：
- Who ：誰發現入侵行為？
- How ：如何發現？
- When ：何時發現？
- What ：受損害的程度為何？
- Where ：攻擊從何開始？
- What techniques ：怎樣的技術造成系統的損害？及需要什麼技術來進行處理？
根據以上幾點，您可以依據不同的入侵型態來設計應對策略以及需要的通報資訊，要成功的處理入侵事件並不單只是仰賴快速的回復系統狀態，而是還要兼顧入侵資訊的蒐集和證據的取得。
當 系統可能發生遭受入侵的情形時，最常被問到的問題通常是， ” 是否要立即將系統離線 ” 、 ” 是不是要將系統關機 ” 、 ” 要不要馬上將系統重安裝 ”，但這些都不是最好的解決方式，而是必須考量您先前所設計的資訊安全策略。舉例來說，若入侵者還潛伏在您的系統中，也許您不應該立即斷線而驚動對方，反之 您可以進行安全通報後，藉由監控程式追蹤出對方的來源。但倘若您的資料屬於重要的機密資料，這時您可能就須以保護資料為優先，立即斷線以防止更嚴重的損害 發生。
三、取得證據數 位證據是相當容易建立，也是容易修改，通報者必須十分注意取得的證據，重要的是必須注意每一個蒐集的程序及所蒐集到的資訊種類。在資安事件上，入侵行為 未必會立即提昇至需要法律行動，但對於企業組織來說這些相關資訊的取得，都可能在將來資安事件等級提昇時，轉變為有力的證據，因此，對於蒐集的時間點、技 術等，都應該利用可信任及可驗證的方式進行。對於記錄的方式、時間、媒體以及如何整合這些證據的方式，都應要事先建立標準程序，以因應問題發生時之處理， 在記錄這些證據時，您必須注意底下事項，確保蒐集的資訊是有效的。
- 避免寫入原來的媒體
- 避免直接刪除所有執行程序
- 避免干預系統時間
- 避免使用非信任的軟體
- 避免干預系統狀況（包含重開機、更新檔、修正檔、或是重新修改系統組態）
四、保護容易消失的資訊
當 資安處理程序進入鑑識（ forensic ）分析程序時，有可能會採用系統關機或是離線調查的方式。然而電腦系統有許多的資訊是容易消失（或揮發）的（例如：記憶體資料、時間、內容、連線狀況 等），因此，在系統存活時（ live system ）即時保存甚至是保護這些容易消失的資訊，對於數位證據的蒐集上，是相當重要的步驟。底下列舉這些容易消失的儲存設備種類，這些是蒐集及保存系統現況資訊 重要的處理標的：
當 資安處理程序進入鑑識（ forensic ）分析程序時，有可能會採用系統關機或是離線調查的方式。然而電腦系統有許多的資訊是容易消失（或揮發）的（例如：記憶體資料、時間、內容、連線狀況 等），因此，在系統存活時（ live system ）即時保存甚至是保護這些容易消失的資訊，對於數位證據的蒐集上，是相當重要的步驟。底下列舉這些容易消失的儲存設備種類，這些是蒐集及保存系統現況資訊 重要的處理標的：
- Registers, cache 內容
- 記憶體內容
- 網路連線狀態
- 正在執行的程序（ running processes ）
- 正在使用的檔案內容及磁碟裝置
- 可攜式裝置或是備份媒體內容（光碟機、磁帶機、 flash 碟等 … ）
而在動手取得這些易消失證據時，底下幾項是需要注意的事項：
- 系統時間及日期
- 正在執行和運行的程序（ process ）
- 目前的網路連線狀態
- 應用程式所開啟的通訊埠（ sockets ）
- 系統上登入的使用者
取得以上這些容易消失的資訊，對於蒐證來說是相當重要的一環，在某些案例中，入侵者（如： hacker ）常會利用駭客工具來達成目的，此時所使用的工具程式就會常駐在記憶體、網路連線中，完整的取得這些資訊，對於成功的處理資安事件有絕對必要性。
五、建立蒐證工具集(Toolkits)
取 得資安事故證據及確定其正確無誤的是重要的，因此，可信的蒐證程式與工具將是蒐證的第一步驟，建議將這些工具建立在 CD-ROM 中攜帶至受入侵系統或是事件現場將會是個不錯的處理方式，管理者需要經常更新蒐證工具且定期蒐集系統內資訊，才能確保所取得的資訊能最接近於事發時間。
取 得資安事故證據及確定其正確無誤的是重要的，因此，可信的蒐證程式與工具將是蒐證的第一步驟，建議將這些工具建立在 CD-ROM 中攜帶至受入侵系統或是事件現場將會是個不錯的處理方式，管理者需要經常更新蒐證工具且定期蒐集系統內資訊，才能確保所取得的資訊能最接近於事發時間。
下提供有關於 Window 底下蒐集系統安全資訊的工具，您可以依照您的所需要取得資訊多寡程度，來決定所使用的數量及使用的等級，依此建立您的處理工具集（ Toolkits ），並測試及確認在蒐集資安事件資訊時，這些工具不會改變任何系統的狀態，這對於將來進行鑑識 (forensic) 時，將會有很大影響。
表 1 ： Window-base 蒐集系統安全資訊的工具
| 工 具 | 描 述 | 來 源 |
| ipconfig | 用來確認系統上 ip 位址。 | 可信任的系統 |
| netstat | 用來確認系統上 ip 位址。 | 可信任的系統 |
| nbstat | 用以顯示 NetBIOS 至 TCP/IP （ NetBT ）協定狀態，本機端到遠端電腦的 NetBIOS table 狀態。 | 可信任的系統 |
| date | 確認系統日期。 | 可信任的系統 |
| time | 確認系統時間。 | 可信任的系統 |
| psuptime | 用來確認 win NT/2k 系統已開機執行的時間。 | www.sysinternals.com |
| net | 用來確認 NetBIOS 連線、使用者帳號、分享資料夾及啟動服務等功能。 | 可信任的系統 |
| psloggedon | 用來顯示本地端使用者帳號連結至遠端的情形。 | www.sysinternals.com |
| pulist | 命令模式工具，用來顯示本機上所有執行中的程序，並且可以擷取使用者正在執行的程序。 | www.sysinternals.com |
| pslist | 命令模式，顯示所有執行程序使用 CPU 的資訊，包含時間、負載百分比、核心或是使用者模式及記憶體使用量，可選擇即時監控或是直接擷取方式。 | www.sysinternals.com |
| listdlls | 列出本機上所有使用的 DLLs ，包含版本、放置位置。 | www.sysinternals.com |
| fport | 用來顯示系統上目前執行程序，及該程序所使用之 PID 、 PORT 狀態。 | www.sysinternals.com |
| psservice | 用來顯示系統狀態、組態、服務的 service 並可以進行管理系統服務。 | www.sysinternals.com |
| ps-info | 顯示 windows NT/2K 上 OS 及所有人的狀態、及主機上的所有資訊。 | www.sysinternals.com |
| arp | 系統上將 IP 位址與 MAC 位址做對應之工具。 | 可信任的系統 |
| ntlast | 監控登入的狀況（失敗或成功）。 | www.sysinternals.com |
| reg | 系統上用來編輯、管理 registry 工具。 | NT resource Kit |
| auditpol | 用來決定系統所使用的 audit policy 。 | NT resource Kit |
| regdmp | 將系統 registry 轉換成文字檔輸出。 | NT resource Kit |
| md5sum | 用來產生檔案的 hash 值，確保輸出的檔案不被修改。 | unxutils.sourceforge.net |
| netcat(cryptcat) | 用來將資訊寫入或讀取網路連結當中， Cryptcat 與 netcat 相同，不過還可以建立加密的通訊管道。 | www.atstake.com |
| filemon | 監控系統上檔案系統活動情形，並且可觀察應用程式所使用的 DLLs 狀態。 | www.sysinternals.com |
| windump | 用來擷取分析系統 TCP 連線內容工具。 | www.dump.polito.it |
| process explorer | Windows 下套裝軟體，可以用來監控系統程序狀況及使用 DLLs 的情形。（包含位置、版本資訊等）。 | www.sysinternals.com |
| cmd.exe | 用來啟動命令列工具。 | 可信任的系統 |
六、取得Windows平台證據
6.1 Step by Step當然，我們並不能確保每個管理者都能夠在第一時間就發覺入侵行為，通常發現問題時，系統可能已經重新啟動，喪失之前的原始狀況，即使發生上述情形，對於蒐證來說，儘早進行蒐證的程序，仍是正面積極的行動，底下將一步一步告訴您該如何進行資訊的蒐集工作。
6.1.1 ：開啟信任的工具列工具 ( 從您的 Toolkits)將您所建立好的蒐證工具集放置於受入侵之機器的 CD-ROM ，並且啟動您系統上的開始選單，在執行的選項上執行 "cmd.exe" 啟動命令列視窗。
6.1.2 ：準備好蒐證系統記 得先前您已經將您的蒐證工具集放置於受害機器上，接下來步驟就是開始要利用這張光 碟來進行資訊的蒐集，並且把蒐集的證據存放到儲存媒體。在此之前，您可以利用網路方式來進行證據的存放，因此，您需要在遠端啟動蒐證系統，以 netcat 為例（您也可使用加密的方式，如 cryptcat ，可以避免遭受竊聽），首先您必須在您的蒐證機器上，啟動 netcat 並給於此服務一個聆聽埠（ listen port ），準備接收來自受害主機的資訊。
蒐證機器上執行： nc –l –p 12345 >> d:\collect.txt
在此， -l 為開啟 listen port ， -p 則是指定您的 listen port ，最後轉向到您所欲儲存的位置上，在設置好蒐證系統的準備工作後，接著就是回到受害主機上進行蒐證的工作。在受害主機上，您必須建立與蒐證系統的連線工作。
受害主機上： nc < 蒐證系統 ip 位址 > -e
舉例來說，若您欲將受害主機目錄下檔案結構傳遞至蒐證主機，您可以在命令欄位上使用 dir 這個指令，
如下：
nc 192.168.1.9 12345 -e dir 或是 dir | nc 192.168.1.9 12345
6.1.3 ：蒐集易消失證據在蒐證的第一要務為蒐集系統上容易消失的重要資訊，包含了：
- 系統中基本資訊
- 執行中的程序
- 開啟的通訊埠
- 網路連線狀態
- 網路分享狀況
- 網路使用者
底下是此一階段需要執行的指令，而系統時間及日期是在執行所有程序的前需要先蒐集的資訊（請記住，以下步驟皆是在受害主機端進行）
| 指 令 | 說 明 |
| date /ttime/t | 蒐集主機上之系統時間，在執行此一動作同時，需先檢查系統時間與實際時間是否有所差別，若有，也請詳細記錄差異的數值，這對將來比對網路設備端之記錄是相當重要的。 |
| ipconfig /all | 記錄目前主機所使用的網路連線基本資訊。 |
| psinfo | 記錄系統資訊，包含修正檔的版本、修正的次數。 |
| psuptime | 紀錄系統啟動的時間。 |
| psloggedon | 記錄遠端與本機端使用者的連線狀態。 |
| ntlast –r -f | 記錄系統中使用者登入的狀況。（包含成功與失敗） |
| net < 參數 > | 檢 測系統中網路選項資訊，參數種類包含 |
| nbtstat –n nbtstat –c nbtstat -s | 存取遠端 NetBIOS 名稱、目前 NetBIOS 的連線狀態、及最後連線狀態。 取得本機端與遠端的 NetBIOS table 狀態。分辨登入的使用者。 |
| pclip | 取得 clipborad 的資訊。 |
| pslist pulist psservice | 取得系統執行程序的資訊。 列出正在執行的程序； 列出正在活動（ active ）的程序。列出目前服務的狀態。 |
| listdlls | 記錄目前所使用的 DLLs ，包含放置位置、版本及數量。在此也可以發現是否有木馬程式或其他惡意程式存在。 |
| fport | 記錄目前所使用的程序、 PID 、及所使用的通訊 port 。參考： http://isc.sans.org/port_detial.html |
| netstat -an | 記錄目前 listening 的服務（ service ）、目前系統開啟的 port 。 |
| netstat –rn | 記錄 routing table 。 |
| arp -a | IP address 與 MAC address 表。 |
| dir /t:a /a /s /o:d c: | 取得最後存取時間。 |
| dir /t:w /a /s /o:d c: | 取得修改時間。 |
| dir /t:c /a /s /o:d c: | 取得最後建立時間。（若有多部磁碟機，請自行改變磁碟機代號）利用 dir 可以建立在蒐證時，磁碟機內檔案、時間資訊、連結等資訊。 |
| hfind c: | 紀錄磁碟機內所有屬性為隱藏（ hidden ）的檔案。用來區分隱藏與一般屬性的檔案。 |
| md5sum | 給予檔案 hash 值，用來確保蒐集的檔案不被竄改。 |
註：上述指令詳細功能，請自行參考指令說明檔。 ( 程式範例請參照附錄 )
上述所有蒐集動作，看似繁雜且枯燥，但當所有資訊都蒐集齊全時，將會成為系統的縮影，資安處理單位可以根據上述資訊進一步還原系統原貌，連線、檔案結構。
6.1.4 ：蒐集系統 logs完 成受測系統環境資訊蒐集後，接著就要針對此部機器的歷史資訊進行蒐集，所謂歷史資 訊指的是本機的記錄檔 (logs) ，藉由取得 log 檔，在電腦鑑識 (computer forensic) 階段時，將可以根據歷史資訊來分析該機器特定時間點發生何事，提供了怎樣的服務，可以更接近於當時系統狀態，若蒐集環境資訊是屬於靜態分析， log 分析則是屬於動態的部份。當然，前提是您在安裝設定您系統時，您已經知道啟動歷史紀錄檔的必要性，在此階段所蒐集的 log 有：
- Registry
- Events logs
- Relevant application logs
| 指 令 | 說 明 |
| auditpol | 用來設定系統所使用的策略。 |
| reg query | 取得 registry 下 ”Run”, 下列是需要檢查的 registry, 目的用來確認是否有木馬程式常駐在系統中。 |
| HKLM\Software\Microsoft\Windows\Current Version\Run /s | 檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。 |
| HKLM\Software\Microsoft\Windows\Current Version\RunOnce /s | 檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。 |
| HKLM\Software\Microsoft\Windows\Current Version\RunServices /sc | 檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。 |
| HKLM\Software\Microsoft\Windows\Current Version\RunServicesOnce /s | 檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。 |
| HKCU\Software\Microsoft\Windows\Current Version\Explorer\ | 追蹤曾經安裝過的程式檔案。用來判別過去使用過程式及是否有遭受木馬程式攻擊。 |
| Streams –s c: | 檢查磁碟機中 NTFS 檔案結構 |
註：有多部磁碟機時，請自行改變磁碟機代號
接著繼續蒐集事件（ Event ） Logs 及其他應用程式記錄檔。
接著繼續蒐集事件（ Event ） Logs 及其他應用程式記錄檔。
| Logs | 存放位置 |
| Event logs APP | c:\WINNT\system32\config\AppEvent.Evt |
| Event logs SEC | c:\WINNT\system32\config\SecEvent.Evt |
| Event logs SYS | c:\WINNT\system32\config\SysEvent.Evt |
| IIS Web Log ( 若有安裝 ) | c:\WINNT\system32\logfiles\W3SVC1\ |
| Mail logs( 若有安裝 ) | c:\WINNT\system32\logfiles\SMTPSVC1\ |
| DNS logs( 若有安裝 ) | c:\WINNT\system32\config\DNSEvent.Evt |
註：若您使用其餘服務，請自行尋找該服務程式之記錄檔
在您尋找到該 log 檔後，請利用 md5sum 將其加上 hash 碼，以確保資訊在傳輸時不會遭受竄改，並將這些記錄檔存放置蒐證主機上。
6.1.5 ：網路連線封包內容蒐集本 階段為蒐集網路連線目前的動作，若情況允許的話，您可以利用網路工具進行監控主機 的動作，利用 sniffer （監聽）工具可以監控網路及封包狀況，藉此瞭解傳輸內容，以及預防入侵者再次返回系統進行破壞（當然，設下陷阱也是可以採行的方案，一切原則以組織中的安 全策略為依歸）。
| 工具 | 目的 |
| WinDump/Snort/ 其他監控軟體 | 網路狀況監控，分析目前網路流量、內容，進一步更可監控入侵者是否返回。 |
6.2 蒐證步驟自動化上 述所使用之指令，您可以利用批次檔方式撰寫，可以增加蒐證的效率與速度，您也可以 根據不同的蒐證環境建立您不同的蒐證批次檔，如下 Windows Forensic Script ，之後就可以利用這個批次檔還進行自動化地蒐證，並利用『 > 』重導的方式寫入檔案或送至遠端的鑑識主機即可。
如： wfs.bat > 2004-08-11-ip-forensic.txt
6.3 Identification of footprints （辨識足跡）綜合上述，您目前已經蒐集了：
- 系統基本資訊
- 執行中程序（ processes ）
- 開啟的通訊埠
- 網路連線狀態
- 網路分享狀況
- 使用者狀況
- 相關的系統記錄檔（ logs ）
接下來的步驟就是要尋跡，藉由比對及檢查我們所蒐集的資訊，去發現異常之處，底下則檢查的重點：
- 檢查異常的程序與開啟的 port （如平常不常見的通訊埠，或是常駐程式）
- 檢查異常的應用程式要求（包含連線、分享資源等）
- 驗證正在執行的工作（ jobs ），可與正常無誤的系統做比對
- 分析信任關係（比方來自於沒見過的 user 或是遠端）
- 檢測可疑的使用者帳號
- 決定系統內修正檔階層（注意修正的紀錄檔）
透 過檢測以上各點，您將會發現不少可疑之處，將其記錄下來，並且與 event logs 及時間記錄（之前所做的檔案時間記錄）相互比對，尋找該時間點有所關連的檔案、連線、使用狀態、與系統的關係。利用時間點切割方式，可以有助於分析事件發 生的起源及影響的範圍，進一步的，可以再利用外部諸如防火牆、網路設備的系統記錄進行分析，經由比對可以尋找出更多關於事件的證據。
特 別需要補充說明的是，當您分析 IIS 下的紀錄時，請記住 IIS 是使用 UTC 時間，原因在於其設計用來提供在全球 www 服務 ( 即使用 multiple time zone) ，因此，分析時您必須根據時差進行系統時間的比對，當您分析此類 log 時，這是需要注意的事項。最後，您可以藉由檢測系統 Registry 來發現：
- 軟體安裝的歷程（包含以前）及目前安裝的軟體
- 判斷系統之安全狀態
- 判斷常駐、開機時啟動的程式即可能會出現的木馬程式
- 判斷曾經使用過的（ Most Recently Used, MRU ）檔案資訊
七、後續處理
藉由入侵蒐證程序，將可以發現系統中異常之處，判斷出問題的發生點以及影響範圍，當完成這些程序後，接下來您必須思考：
藉由入侵蒐證程序，將可以發現系統中異常之處，判斷出問題的發生點以及影響範圍，當完成這些程序後，接下來您必須思考：
- 是否需要將整個系統經由備份工具進行整體的調查（或直接將硬碟當作證據）。
- 是否提升處理等級並採取法律行動。
- 或是恢復系統至正常狀態（ reinstall,patch 或是提升系統安全防護程度）。
當 您完成可疑事件判斷後，將會發現入侵者資訊將不是那麼容易能追溯，此時您可以透過 ISP 進行反應，或是至您所處地的網路危機處理中心進行申訴，以台灣來說，台灣網路危機處理暨協調中心 (TWCERT/CC) ，負責國內及國外入侵事件的回報處理，您可以至該中心入侵回報系統中進行通報，該中心技術人員將會義務為您處理（ https://www.cert.org.tw/service/ir_form.php ），若能附上您所蒐集到的資訊及處理的過程，想必一定能順利解決資安問題，並且經由對方 ISP 防堵該入侵者再度侵害您的系統。
八、結論
所 謂防範未然，入侵應變處理計畫及程序的建立，對於個人或是組織資訊安全是不可或缺的部份，沒有人能保證自己的系統絕對安全，也因此，在不安全的環境下， 防護體系的存在是為了將危險性降至最低，而事發處理計畫，則是為了將傷害降低之最低，其重要性與防衛體系是同等的。建立一套標準程序及完整蒐集工具，能有 助於第一時間保存容易損害的電腦資訊，確保所蒐證之資訊可以最接近於事發當時情況，也有助於恢復至原始環境。
所 謂防範未然，入侵應變處理計畫及程序的建立，對於個人或是組織資訊安全是不可或缺的部份，沒有人能保證自己的系統絕對安全，也因此，在不安全的環境下， 防護體系的存在是為了將危險性降至最低，而事發處理計畫，則是為了將傷害降低之最低，其重要性與防衛體系是同等的。建立一套標準程序及完整蒐集工具，能有 助於第一時間保存容易損害的電腦資訊，確保所蒐證之資訊可以最接近於事發當時情況，也有助於恢復至原始環境。
所建立的處理程序，亦可 設計為定期檢測計畫，系統安全檢測與備份系統也是同等重要，若能於日常工 作同時，落實回應計畫的實施，想必對於解決資安事件，將不會再是難事，也可以降低因為關鍵性資訊的流失，造成日後證據上不足，影響處理甚至進一步判案上的 困擾，因此，在閱讀本文後，您應開始思考您的資訊安全策略是否有缺失，並立即建立您的入侵應變計畫，別讓惡意的入侵者造成你的損害。
惡意程式分析書籍及譯本
- Assembly Language for Intel-Based Computers，作者Kip R. Irvine（中譯本《Intel彙編語言程序設計》 ）。一本學習CPU、寄存器、彙編語言的參考書。
- The IDA Pro Book，作者Chris Eagle（中譯本《IDA Pro權威指南》 ）。學習使用IDA Pro和學習做靜態分析的指南。
- Gray Hat Python，作者Justin Seitz。學習如何使用Python完成調試、鉤掛（hooking）、模糊測試等多種任務。
- Secrets of Reverse Engineering，作者Eldad Eilam（中譯本《Reversing:逆向工程揭密》 ）。對一些逆向技巧和工具做了不錯的總結。
- Malware: Fighting Malicious Code，作者Ed Skoudis、Lenny Zeltser（中譯本《決戰惡意代碼》 ）。學習惡意代碼是什麼、從何而來、有何危害、如何清除（包括Windows下和Unix下）。
- The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System，作者Bill Blunden。對用戶模式和內核模式Rootkit作了深入描述，包含大量C代碼示例（全書接近900頁）。
- Rootkits: Subverting the Windows Kernel，作者Greg Hoglund、Jamie Butler（中譯本《Rootkits——Windows內核的安全防護》 ）。從攻擊和防禦兩個角度介紹了Windows Rootkit。
- Windows Forensic Analysis DVD Toolkit，作者Harlan Carvey（中譯本《Windows取證分析(含DVD光盤)》 ）。大量實踐性取證知識、Harlan自己寫的小工具，以及一些手把手的實例。需要防止或調查計算機入侵的人都應該讀一讀這本書。
- Advanced Windows Debugging，作者Mario Hewardt、Daniel Pravat（中譯本《Windows高級調試》 ）。學習如何使用微軟調試器找到資源洩漏、內存腐爛、安全事件的發生源頭。這本書不是關於惡意代碼的，但顯然你可以使用其中的知識來調試惡意代碼。
- Practical Crypography，作者Niels Ferguson、Bruce Schneier。對安全從業人員應該瞭解的密碼學算法做了很好的總結。
- Forensic Discovery，作者Dan Farmer、Wietse Venema（中譯本《計算機取證》 ）。這是我最早讀過的取證書籍之一。現在這本書有些古老了，但其中的一些概念永遠不會過時。就算到了2030年，我還要推薦這本書。
- Malware Forensics: Investigating and Analyzing Malicious Code，作者Cameron H. Malin， Eoghan Casey，James M. Aquilina（中譯本《惡意代碼取證》 ）。一本圍繞著工具展開的書，對惡意代碼感興趣的人都會喜歡。
- The Shellcoder's Handbook，作者Jack Koziol等；The Shellcoder's Handbook 2nd Edition，作者Chris Anley等。無論是學習如何閱讀和寫shellcode，還是分析惡意代碼利用的漏洞，或者僅僅是想對用於靜態分析的彙編語言有更好的瞭解，這都是一本極好的書。
- File System Forensic Analysis，作者Brian Carrier。使用The Sleuth Kit和Autospy工具來研究文件系統的寶典。我通過它學會了如何對付基於MFT數據、NTFS流等技術的惡意代碼。這本書還包含了其他很多文件系統。
- The Art of Computer Virus Research and Defense，作者Peter Szor（中譯本《計算機病毒防範藝術》 ）。一本偉大的書，囊括了病毒如何工作、如何檢測病毒的各種技術性和非技術性知識。
- Windows NT/2000 Native API Reference，作者Gary Nebbett（中譯本《Windows NT/2000本機API參考手冊》 ）。這本書類似於MSDN，它介紹了微軟未文檔化的API函數。當編寫需要用到原生API的工具，或者逆向用了原生API的惡意代碼時，應該把它放在手頭。
- Windows Internals: Including Windows Server 2003 and Windows Vista, 5th Edition，作者Mark Russinovich，David A. Solomon和Alex Ionescu（中譯本《深入解析Windows操作系統》 ）。包含了很多理解Windows是如何工作的技術性知識。
- Real Digital Forensics: Computer Security and Incident Response，作者Keith J. Jones，Richard Bejtlich和Curtis W. Rose。通過實例，介紹如何在Unix或Windows系統的機器上檢測入侵（隨書DVD上包含了取證文件）。
- Windows via C/C++，作者Jeffrey M. Richter、Christophe Nasarre（中譯本《Windows核心編程》 ）。Windows Internals僅僅介紹了系統的工作原理，而這本書則介紹了如何使用Windows API來編寫程序。當然，它不能取代Windows Internals，你可以把這兩本都讀一讀。
- 轉自 http://blog.claudxiao.net/2011/04/malware_analysis_books/
UserInfo (Windows)
Author Name
Corey Harrell
Artifact Name
UserInfo
Artifact/Program Version
Windows Registry
Description
Microsoft Office documents contain metadata that show when a file was
created, modified, and user names. The user names in Microsoft Office
documents’ metadata is pulled from the UserInfo registry key of the
user account’s registry hive performing the actions. The values
responsible in the UserInfo registry are the UserName and Company
values.
The population of the data in the UserName and Company registry values
varies. The values are populated in the user account that installed
Microsoft Office with the user name and company entered during
installation. For the user accounts that are using Microsoft Office
but didn’t install it, the values are populated a little different.
The first time the user launches an Office application a dialog box
appears asking for the user name and initials. The information entered
in the dialog box is what results in the UserName value in the user’s
UserInfo registry key. The location of the UserInfo registry key
varies depending on the version of Microsoft Office installed on the
system.
Registry Keys
Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003:
HCU\Software\Microsoft\Office\11.0\Common\UserInfo
Research Links
http://support.microsoft.com/kb/821550
http://journeyintoir.blogspot.com/2011/06/why-is-it-what-it-is.html
Forensic Programs of Use
Registry viewer such as the free MiTeC Windows Registry Recovery
轉自 http://forensicartifacts.com/2011/06/userinfo-windows/
Corey Harrell
Artifact Name
UserInfo
Artifact/Program Version
Windows Registry
Description
Microsoft Office documents contain metadata that show when a file was
created, modified, and user names. The user names in Microsoft Office
documents’ metadata is pulled from the UserInfo registry key of the
user account’s registry hive performing the actions. The values
responsible in the UserInfo registry are the UserName and Company
values.
The population of the data in the UserName and Company registry values
varies. The values are populated in the user account that installed
Microsoft Office with the user name and company entered during
installation. For the user accounts that are using Microsoft Office
but didn’t install it, the values are populated a little different.
The first time the user launches an Office application a dialog box
appears asking for the user name and initials. The information entered
in the dialog box is what results in the UserName value in the user’s
UserInfo registry key. The location of the UserInfo registry key
varies depending on the version of Microsoft Office installed on the
system.
Registry Keys
Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003:
HCU\Software\Microsoft\Office\11.0\Common\UserInfo
Research Links
http://support.microsoft.com/kb/821550
http://journeyintoir.blogspot.com/2011/06/why-is-it-what-it-is.html
Forensic Programs of Use
Registry viewer such as the free MiTeC Windows Registry Recovery
轉自 http://forensicartifacts.com/2011/06/userinfo-windows/
Microsoft Office documents metadata
Microsoft Office documents contain metadata that may be relevant to a digital forensic examination. The metadata may show when a file was created, modified, printed, or what user accounts were used to perform those actions. Others have already researched the metadata in Microsoft Office 2003 and 2007 documents including providing programs to parse the metadata. A few of the write-ups are: Kristinn Gudjonsson’s Office 2007 metadata post, and Lance Muller’s Office Metadata EnScript & Updated Office 2007 Metadata EnScript posts. I was interested in understanding how different actions taken against a Microsoft Office document affect its metadata.
To help show the relevance of Office documents’ metadata I included the metadata from one of my test Word 2007 documents. Usually I manual examine the information in metadata on an as needed basis but I thought for this post it would be cleaner to show the information in report format. The text below is the output from Kristinn’s read_open_xml_win.pl script ran against a test Word document. The File Metadata section shows when the file was created, modified, printed, and what user accounts were used to perform those actions. Did you notice the last print date/time (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? I’ll touch on this later in the post which is why I pointed it out.
Document name: E:\office metadata testing\word 2007\Xp-2007-1sp.docx
Date:
--------------------------------------------------------------------------
Application Metadata
--------------------------------------------------------------------------
Template = Normal.dotm
TotalTime = 2
Pages = 1
Words = 1
Characters = 9
Application = Microsoft Office Word
DocSecurity = 0
Lines = 1
Paragraphs = 1
ScaleCrop = false
Company = Test-lab
LinksUpToDate = false
CharactersWithSpaces = 9
SharedDoc = false
HyperlinksChanged = false
AppVersion = 12.0000
--------------------------------------------------------------------------
File Metadata
--------------------------------------------------------------------------
title =
subject =
creator = test-2007
keywords =
description =
lastModifiedBy = test-2007
revision = 2
lastPrinted = 2011-05-27T19:09:00Z
created = 2011-05-27T19:10:00Z
modified = 2011-05-27T19:10:00Z
Usernames in Microsoft Office Metadata
Before looking into how different actions against a Microsoft Office document affect its metadata I think it is useful to know more about the usernames reflected in the creator and modifiedby attributes. The usernames are not populated with the name of the user account that performed the action since there is a value in the Windows registry containing the name to use.
When Office 2003 and 2007 is installed there is prompt asking for a user name and company. Those fields are already prepopulated with the information entered when the operating system is installed which is located in the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion (thanks Greg Kelly for this info). The prompt gives the user an opportunity to either change the user name or company or to leave the fields with the information entered during OS installation.
There is a registry key containing what user name and company was used when Microsoft Office was installed. To locate the registry key the Office program’s GUID must first be determined and this Microsoft article explains how to locate the GUID. The GUID of Microsoft Office programs I tested were 9040110900063D11C8EF10054038389C for Microsoft Office Professional Edition 2003 and 00002109110000000000000000F01FEC for Microsoft Office Professional Plus 2007. The registry key containing the information about the Office installation is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{GUID}\InstallProperties. The regowner and regcompany values in the registry key contain the user name and company entered during the Office installation.
The usernames and company information reflected in Microsoft Office documents’ metadata are pulled from the UserInfo registry key of the user account’s NTUSER.DAT hive performing the actions. The names of the two values containing the data in the registry key are UserName and Company. The location of the registry key varies depending on the version of Microsoft Office but the paths below show where the key is located for Office 2007 and 2003.
Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003: HCU\Software\Microsoft\Office\11.0\Common\UserInfo
Now the question I found myself asking is how are the UserName and Company values initially populated in the UserInfo key? I previously explained the user name and company during Office installation because the entered information is used to populate the UserInfo registry key of the user account that installed Microsoft Office. For the user accounts on the system that are using Microsoft Office but didn’t install it, the values are populated a little different. The first time the user launches an Office application a dialog box appears asking for the user name and initials. The dialog box is prepopulated with the name of the currently logged on user. The information entered in the dialog box is what results in the username value in the user's UserInfo key while the company value comes from the information entered when the Office was installed.
The metadata shown above now has a little more meaning. The username test-2007 is not the name of the user account that created and modified the document but is the name listed in the UserInfo registry key. The name in the UserInfo registry key can be changed at any point but any changes will alter the last write time on the registry key. This means the last write time of the user account’s UserInfo key should be taken into consideration when examining metadata. If the registry key last write time is before the dates/times in the metadata (create, modify, or print) then the metadata reflects what is currently in the user account’s NTUSER.DAT hive. On the other hand, if the registry key last write time is after the metadata timestamps then what is currently in the user account’s NTUSER.DAT hive may not be what was there when the action was taken against the Office document (did I just hear someone whisper check the restore points or volume shadow copies for registry files).
How Actions Change Microsoft Office Metadata
The testing I conducted consisted of creating one document then performing different actions against copies of the document to see how the metadata changed. I only ran the tests against documents created by the following programs: Word 2007, Word 2003, Excel 2007, and Excel 2003. If I test other Office Programs in the future then I’ll update the post to reflect it. The observed changes in the documents’ metadata were consistent across all of the different versions of Office but there were some minor differences between the different file types. The Excel metadata differed from Word in the following ways: there was no revision number, some timestamps contained seconds, and the Save As function didn’t change the documents’ creation date.
I’m providing charts of how the metadata was affected by the different actions taken against the documents. The chart has information in the parenthesis to show what the metadata values were for one set of documents (the timestamps don’t include the date since it was the same for all of the documents).
Here’s the Microsoft Office Word Metadata Changes chart and Microsoft Office Excel Metadata Changes chart. The PDF versions can be downloaded from the jIIr site.
The charts show how different actions against a Microsoft Office document affect its metadata. There are quite a few takeaways but I’m only going to highlight a few.
* The metadata create date/time reflects when the Office program was opened as opposed to the first time the document was saved
* Copying an Office document doesn’t changed the metadata
* The metadata print date/time only changes when the document is saved after it is printed
* The Save As function results in the Word metadata create and modification date/times being the same while the modification date/time only changes in Excel metadata
Now let’s go back to the metadata I posted above. Do you remember that the last print date (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? There was one action taken against a Microsoft Word document that produced this pattern in the metadata. The action was printing a document then using the Save As function to create a new document. The metadata shown above is from the newly created document.
To help show the relevance of Office documents’ metadata I included the metadata from one of my test Word 2007 documents. Usually I manual examine the information in metadata on an as needed basis but I thought for this post it would be cleaner to show the information in report format. The text below is the output from Kristinn’s read_open_xml_win.pl script ran against a test Word document. The File Metadata section shows when the file was created, modified, printed, and what user accounts were used to perform those actions. Did you notice the last print date/time (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? I’ll touch on this later in the post which is why I pointed it out.
Document name: E:\office metadata testing\word 2007\Xp-2007-1sp.docx
Date:
--------------------------------------------------------------------------
Application Metadata
--------------------------------------------------------------------------
Template = Normal.dotm
TotalTime = 2
Pages = 1
Words = 1
Characters = 9
Application = Microsoft Office Word
DocSecurity = 0
Lines = 1
Paragraphs = 1
ScaleCrop = false
Company = Test-lab
LinksUpToDate = false
CharactersWithSpaces = 9
SharedDoc = false
HyperlinksChanged = false
AppVersion = 12.0000
--------------------------------------------------------------------------
File Metadata
--------------------------------------------------------------------------
title =
subject =
creator = test-2007
keywords =
description =
lastModifiedBy = test-2007
revision = 2
lastPrinted = 2011-05-27T19:09:00Z
created = 2011-05-27T19:10:00Z
modified = 2011-05-27T19:10:00Z
Usernames in Microsoft Office Metadata
Before looking into how different actions against a Microsoft Office document affect its metadata I think it is useful to know more about the usernames reflected in the creator and modifiedby attributes. The usernames are not populated with the name of the user account that performed the action since there is a value in the Windows registry containing the name to use.
When Office 2003 and 2007 is installed there is prompt asking for a user name and company. Those fields are already prepopulated with the information entered when the operating system is installed which is located in the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion (thanks Greg Kelly for this info). The prompt gives the user an opportunity to either change the user name or company or to leave the fields with the information entered during OS installation.
There is a registry key containing what user name and company was used when Microsoft Office was installed. To locate the registry key the Office program’s GUID must first be determined and this Microsoft article explains how to locate the GUID. The GUID of Microsoft Office programs I tested were 9040110900063D11C8EF10054038389C for Microsoft Office Professional Edition 2003 and 00002109110000000000000000F01FEC for Microsoft Office Professional Plus 2007. The registry key containing the information about the Office installation is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{GUID}\InstallProperties. The regowner and regcompany values in the registry key contain the user name and company entered during the Office installation.
The usernames and company information reflected in Microsoft Office documents’ metadata are pulled from the UserInfo registry key of the user account’s NTUSER.DAT hive performing the actions. The names of the two values containing the data in the registry key are UserName and Company. The location of the registry key varies depending on the version of Microsoft Office but the paths below show where the key is located for Office 2007 and 2003.
Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003: HCU\Software\Microsoft\Office\11.0\Common\UserInfo
Now the question I found myself asking is how are the UserName and Company values initially populated in the UserInfo key? I previously explained the user name and company during Office installation because the entered information is used to populate the UserInfo registry key of the user account that installed Microsoft Office. For the user accounts on the system that are using Microsoft Office but didn’t install it, the values are populated a little different. The first time the user launches an Office application a dialog box appears asking for the user name and initials. The dialog box is prepopulated with the name of the currently logged on user. The information entered in the dialog box is what results in the username value in the user's UserInfo key while the company value comes from the information entered when the Office was installed.
The metadata shown above now has a little more meaning. The username test-2007 is not the name of the user account that created and modified the document but is the name listed in the UserInfo registry key. The name in the UserInfo registry key can be changed at any point but any changes will alter the last write time on the registry key. This means the last write time of the user account’s UserInfo key should be taken into consideration when examining metadata. If the registry key last write time is before the dates/times in the metadata (create, modify, or print) then the metadata reflects what is currently in the user account’s NTUSER.DAT hive. On the other hand, if the registry key last write time is after the metadata timestamps then what is currently in the user account’s NTUSER.DAT hive may not be what was there when the action was taken against the Office document (did I just hear someone whisper check the restore points or volume shadow copies for registry files).
How Actions Change Microsoft Office Metadata
The testing I conducted consisted of creating one document then performing different actions against copies of the document to see how the metadata changed. I only ran the tests against documents created by the following programs: Word 2007, Word 2003, Excel 2007, and Excel 2003. If I test other Office Programs in the future then I’ll update the post to reflect it. The observed changes in the documents’ metadata were consistent across all of the different versions of Office but there were some minor differences between the different file types. The Excel metadata differed from Word in the following ways: there was no revision number, some timestamps contained seconds, and the Save As function didn’t change the documents’ creation date.
I’m providing charts of how the metadata was affected by the different actions taken against the documents. The chart has information in the parenthesis to show what the metadata values were for one set of documents (the timestamps don’t include the date since it was the same for all of the documents).
Here’s the Microsoft Office Word Metadata Changes chart and Microsoft Office Excel Metadata Changes chart. The PDF versions can be downloaded from the jIIr site.
The charts show how different actions against a Microsoft Office document affect its metadata. There are quite a few takeaways but I’m only going to highlight a few.
* The metadata create date/time reflects when the Office program was opened as opposed to the first time the document was saved
* Copying an Office document doesn’t changed the metadata
* The metadata print date/time only changes when the document is saved after it is printed
* The Save As function results in the Word metadata create and modification date/times being the same while the modification date/time only changes in Excel metadata
Now let’s go back to the metadata I posted above. Do you remember that the last print date (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? There was one action taken against a Microsoft Word document that produced this pattern in the metadata. The action was printing a document then using the Save As function to create a new document. The metadata shown above is from the newly created document.
轉自 http://windowsir.blogspot.com/2011/06/updates-links-etc.html
NetworkList (Vista/Windows 7)
2011/06/25
標籤：
系統常識
Author Name
H. Carvey
Artifact Name
NetworkList
Artifact/Program Version
RegRipper w/ networklist.pl plugin v.20090812
Description
Vista and Windows 7 maintain a Registry key named
“NetworkList”:
HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList
This key appears to contain profiles regarding managed and
unmanaged networks, including wireless networks that the system has
connected to, including SSID, the date the profile was created, the
date last connected, the MAC address of the WAP, etc. This MAC can be
looked up in the SkyHook database, and possibly converted to a Google
Map.
Registry Keys
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList (Updated 6/3- Thanks to Troy)
File Locations
Software Hive
Forensic Programs of Use
RegRipper w/ networklist.pl plugin
轉自 http://forensicartifacts.com/2011/06/networklist-vistawindows-7/
H. Carvey
Artifact Name
NetworkList
Artifact/Program Version
RegRipper w/ networklist.pl plugin v.20090812
Description
Vista and Windows 7 maintain a Registry key named
“NetworkList”:
HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList
This key appears to contain profiles regarding managed and
unmanaged networks, including wireless networks that the system has
connected to, including SSID, the date the profile was created, the
date last connected, the MAC address of the WAP, etc. This MAC can be
looked up in the SkyHook database, and possibly converted to a Google
Map.
Registry Keys
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList (Updated 6/3- Thanks to Troy)
File Locations
Software Hive
Forensic Programs of Use
RegRipper w/ networklist.pl plugin
轉自 http://forensicartifacts.com/2011/06/networklist-vistawindows-7/
Virtual Machine Files Essential to Forensic Investigations
By: JD Durick
If you are responsible for collecting and analyzing digital evidence, you are already aware of how platform and desktop virtualization are changing the way organizations, corporations, and government agencies deliver, store, and manage digital content.
Virtualization adds an enormous level of complexity to an already complex field. As forensic practitioners tasked with performing examinations on enterprise virtual environments, they are confronted with the challenge of understanding what VM-related files are of significant importance. Should they acquire the Virtual Machine Disk (VMDK) related files of the Virtual machine in question? What about the snapshot, memory, swap, configuration, metadata, and log files? Each one of these files are essential in running the virtual machine and could assist forensic examiners in understanding the Virtual machine’s function and potential compromise. Below is a step-by-step listing of a virtual machine’s life cycle detailing six major specific states:
Virtual Machine life cycle in VMware ESXi 4 update 1:
Creation:
When a virtual machine is created, several important files are generated in the location specified by the user. These files include:
Figure 1: Pre-creation snapshot and corresponding files of the Virtual Machine.
Startup:
When the VM is started, several additional files are created including:
Figure 2: Files created after installation of the Virtual Machine.
Suspend:
Figure 3: Files that were created after VM suspension occurred.
Resume:
Figure 4: Files changed after a VM resume was executed.
Snapshot:
Figure 5: Changes to the files after a snapshot of the VM was created.
Shutdown:
Figure 6: Files that now exist after a clean
shutdown are executed on the VM.
轉自 http://crucialsecurityblog.harris.com/2011/05/23/virtual-machine-files-essential-to-forensic-investigations/
反封包側錄套件 - Sniffjoke 0.4.1
2011/06/21
標籤：
資安工具
SniffJoke實現了一系列反嗅探技術，但開始作為一個流行的框架。SniffJoke有一個完整的支持社區。SniffJoke是一個linux應 用程序，可以透明的處理TCP連接，對數據包進行延遲、修改和注入偽造。經過處理後數據包幾乎不能被被動竊聽技術截獲（IDS或sniffer）。目前，Sniffjoke更新至0.4.1版
工具下載：http://www.delirandom.net/sniffjoke/sniffjoke-howto-usage/
System Version (Mac)
2011/06/19
標籤：
系統常識
Author Name
Douglas Brush
Artifact Name
SystemVersion.plist
Artifact/Program Version
OS X 10.x (Client)
Description
When you start your Macintosh investigation it is important to know
what version of the operating system is installed on the computer. The
version of OS X (10.4, 10.5, 10.6) can shape and direct the analysis
as each version has certain unique characteristics for other artifacts
as well as their locations on the disk.
Macintosh operating systems use plist files (.plist) as repositories
for system and program settings/information. Plist files can wither be
in a binary-encoded format (bplist file header) or as XML.
To get the operating system version the first plist files you will
want to examine is the “SystemVersion.plist” located in
“/System/Library/CoreServices/” folder. With this knowledge you
can be aware of other plists and system artifacts that are unique to
the OS under inspection.
File Locations
/System/Library/CoreServices/SystemVersion.plist
Research Links
Forensic Programs of Use
plist Edit Pro (Mac):
plist Editor Pro (Win):
轉自 http://forensicartifacts.com/2011/06/system-version-mac/
Douglas Brush
Artifact Name
SystemVersion.plist
Artifact/Program Version
OS X 10.x (Client)
Description
When you start your Macintosh investigation it is important to know
what version of the operating system is installed on the computer. The
version of OS X (10.4, 10.5, 10.6) can shape and direct the analysis
as each version has certain unique characteristics for other artifacts
as well as their locations on the disk.
Macintosh operating systems use plist files (.plist) as repositories
for system and program settings/information. Plist files can wither be
in a binary-encoded format (bplist file header) or as XML.
To get the operating system version the first plist files you will
want to examine is the “SystemVersion.plist” located in
“/System/Library/CoreServices/” folder. With this knowledge you
can be aware of other plists and system artifacts that are unique to
the OS under inspection.
File Locations
/System/Library/CoreServices/SystemVersion.plist
Research Links
Forensic Programs of Use
plist Edit Pro (Mac):
plist Editor Pro (Win):
轉自 http://forensicartifacts.com/2011/06/system-version-mac/
Evernote note storage
Author Name
Joseph W Shaw II
Artifact Name
Evernote note storage
Program Version
Evernote 4.3.1.4479
Description
Evernote is a tool used to capture, store, and share ideas and
information in the form of multimedia notes mixing text, images, pdfs,
and other document types into searchable “notes.” These notes are
stored in an SQLite database format. Records are appended to the end
of the database. As records are deleted, they are overwritten by new
records. However, data records can be retained inside of the database
when the SQLIite database is viewed in Text or Hex view.
File Locations
On Windows 7: C:\Users\\AppData\Local\Evernote\Evernote\Database\.exb
Forensic Programs of Use
SQLite Database Browser
EnCase 6.18.1.3 64bit
Joseph W Shaw II
Artifact Name
Evernote note storage
Program Version
Evernote 4.3.1.4479
Description
Evernote is a tool used to capture, store, and share ideas and
information in the form of multimedia notes mixing text, images, pdfs,
and other document types into searchable “notes.” These notes are
stored in an SQLite database format. Records are appended to the end
of the database. As records are deleted, they are overwritten by new
records. However, data records can be retained inside of the database
when the SQLIite database is viewed in Text or Hex view.
File Locations
On Windows 7: C:\Users\\AppData\Local\Evernote\Evernote\Database\.exb
Forensic Programs of Use
SQLite Database Browser
EnCase 6.18.1.3 64bit
Old Record Search Hit
轉自 http://forensicartifacts.com/2011/06/evernote-note-storage/
轉自 http://forensicartifacts.com/2011/06/evernote-note-storage/
Salvaging Digital Video Fragments
Posted By Eoghan Casey
Digital video is becoming a more common form of digital evidence with the increasing prevalence of video in computers, mobile devices and cameras. Digital cameras can create high quality videos, most smart phones can create videos, and the iPad2 has two cameras that can create videos. The videos created by such digital devices can be stored on removable storage media and on the devices themselves. Frequent creation and deletion of videos on these kinds of devices can result in fragments of deleted video clips that most file carving tools cannot salvage. In addition, when dealing with Flash memory dumps acquired from mobile devices, data at the physical level is often fragmented. Specialized methods and tools are needed to salvage deleted video fragments as demonstrated in this article using the contents of Flash memory acquired from a Motorola V3 (RAZR) mobile device.
Hex view of 3gp header in the Motorola V3 Flash memory dump
If the file is fragmented or the header is missing, the file carving approach will not salvage the deleted video successfully. In this example, a file carving tool that searched the Motorola V3 memory dump for several 3gp header signatures found two files in as shown in the audit log:
However, the salvaged files were invalid because the original files were fragmented. Furthermore, the names and directory paths of these files were not obtained using this method, demonstrating a further limitation of file carving.
When video files are fragmented, it is necessary to consider the video file format in more detail. Fortunately, many digital video formats have a structure that can be used to find and salvage individual frames. A frame is a discrete section of the video that can have a timecode or sequence number and other characteristics that can be useful for salvaging digital video clips.
The defraser tool can be used to identify frames for several video formats in a forensic duplicate of any piece of storage media, including a removable storage card, computer hard drive and Flash dump from a mobile device. The following screenshot shows defraser used to detect video related data in the Motorola V3 memory dump.
Defraser showing video related data in the Motorola V3 memory dump
Although the defraser tool does not automatically piece together the frames into a video that can be played, it does make the frames available for manual reconstruction. With some effort, defraser may be used to combine fragmented frames into a valid video file that can be played.
As with file carving methods that rely on header signatures, the carving methods employed by defraser do not provide the filenames and directory path of salvaged video data in the context of the original file system.
Ultimately, the most effective approach to extracting digital video files from acquired digital evidence such as a Flash memory dump from mobile device is to reconstruct the logical arrangement of data. On mobile devices, this logical structure involves the flash abstraction layer and file system. Using mobile device forensic tools such as Cellebrite Physical and XRY, it is possible to reconstruct and review logical file structure of a Flash memory dump as shown below with a 3gp video stored in an MMS related file in the Motorola V3 memory dump. Note that different tools may interpret the logical structure differently and show more files and folders, clearly demonstrating the importance of validating the results of forensic examination tools.
XRY/XACT showing the logical file system in the Motorola V3 memory dump
Cellebrite Physical showing the logical file system in the Motorola V3 memory dump
Extracting the MMS file using such a mobile device forensic tool and extracting the video content as discussed in the “Delving into Mobile Device File Systems” blog post results in a 3gp file that can be played using VLC media player.
Playing salvaged digital video using VLC Player
After salvaging digital video files it is important to review the resulting data closely for potential anomalies. For instance, using MediaInfo to extract metadata from video files shows details related to its creation and format. The following screenshot shows metadata from a 3gp video extracted from the Motorola V3 memory dump, revealing that the embedded date-time stamp was set to an incorrect date.
Metadata within a 3gp video displayed using MediaInfo
In addition, reviewing individual frames within a salvaged video file can reveal anomalies such as portions of two unrelated videos being combined into one salvage file. The following screenshot shows frames extracted from a 3gp file using DCCI Video Validator revealing footage from two unrelated video files.
Frames extracted from digital video using DCCI Video Validator
When a video file is fragmented or the header of a video file is overwritten, carving methods that rely on header signatures and contiguous files will not salvage video files successfully and may even incorrectly combine unrelated video fragments into a single file or fail to detect the presence of video content altogether. However, using specialized tools such as defraser, a digital investigator may be able to salvage fragments of video files and piece them together into a valid video file. This process of reconstructing video fragments is time consuming and error prone, particularly when dealing with numerous video files on a single piece of storage media or mobile device. Therefore, whenever feasible, it is preferable to reconstruct the logical arrangement of data to extract the complete content of video files. Whichever method is most effective for salvaging digital video, it is important to examine the results closely to ensure the accuracy and completeness of the resulting videos. Such a review includes inspecting embedded metadata for anomalies and reviewing keyframes for possible fragments of unrelated video footage.
轉自 http://blog.cmdlabs.com/2011/05/30/salvaging-digital-video-fragments/
Digital video is becoming a more common form of digital evidence with the increasing prevalence of video in computers, mobile devices and cameras. Digital cameras can create high quality videos, most smart phones can create videos, and the iPad2 has two cameras that can create videos. The videos created by such digital devices can be stored on removable storage media and on the devices themselves. Frequent creation and deletion of videos on these kinds of devices can result in fragments of deleted video clips that most file carving tools cannot salvage. In addition, when dealing with Flash memory dumps acquired from mobile devices, data at the physical level is often fragmented. Specialized methods and tools are needed to salvage deleted video fragments as demonstrated in this article using the contents of Flash memory acquired from a Motorola V3 (RAZR) mobile device.
File Carving Limitations
Most file carving tools require a known file header in order to salvage deleted data. For instance, to recover a deleted 3gp file, most carving tools look for the file headers such as the following.Hex view of 3gp header in the Motorola V3 Flash memory dump
If the file is fragmented or the header is missing, the file carving approach will not salvage the deleted video successfully. In this example, a file carving tool that searched the Motorola V3 memory dump for several 3gp header signatures found two files in as shown in the audit log:
05/24/2011, 11:26:35
QuickTime 3GP (3gp), header: ftypisom
QuickTime 3GP (3gp), header: ftyp3gp
QuickTime 3GP (3gp), header: ftypmmp4
Default file size: 1024 KB
Maximum file size: 100 times (individual file type definition defaults sizes respected)
E:\Physical GSM Motorola V3 RAZR\Flex Partition 1140000-1fe0000.bin
Scope: 000000 - E9FFFF
Extensive byte-level search
9D0E80 - AD0E7F: 00001.3gp
B888F0 - C888EF: 00002.3gp
05/24/2011, 11:26:35
2 file headers were found. 2 files were retrieved.
However, the salvaged files were invalid because the original files were fragmented. Furthermore, the names and directory paths of these files were not obtained using this method, demonstrating a further limitation of file carving.
Salvaging Video Fragments
When video files are fragmented, it is necessary to consider the video file format in more detail. Fortunately, many digital video formats have a structure that can be used to find and salvage individual frames. A frame is a discrete section of the video that can have a timecode or sequence number and other characteristics that can be useful for salvaging digital video clips.
The defraser tool can be used to identify frames for several video formats in a forensic duplicate of any piece of storage media, including a removable storage card, computer hard drive and Flash dump from a mobile device. The following screenshot shows defraser used to detect video related data in the Motorola V3 memory dump.
Defraser showing video related data in the Motorola V3 memory dump
Although the defraser tool does not automatically piece together the frames into a video that can be played, it does make the frames available for manual reconstruction. With some effort, defraser may be used to combine fragmented frames into a valid video file that can be played.
As with file carving methods that rely on header signatures, the carving methods employed by defraser do not provide the filenames and directory path of salvaged video data in the context of the original file system.
File System Reconstruction
Ultimately, the most effective approach to extracting digital video files from acquired digital evidence such as a Flash memory dump from mobile device is to reconstruct the logical arrangement of data. On mobile devices, this logical structure involves the flash abstraction layer and file system. Using mobile device forensic tools such as Cellebrite Physical and XRY, it is possible to reconstruct and review logical file structure of a Flash memory dump as shown below with a 3gp video stored in an MMS related file in the Motorola V3 memory dump. Note that different tools may interpret the logical structure differently and show more files and folders, clearly demonstrating the importance of validating the results of forensic examination tools.
XRY/XACT showing the logical file system in the Motorola V3 memory dump
Cellebrite Physical showing the logical file system in the Motorola V3 memory dump
Extracting the MMS file using such a mobile device forensic tool and extracting the video content as discussed in the “Delving into Mobile Device File Systems” blog post results in a 3gp file that can be played using VLC media player.
Playing salvaged digital video using VLC Player
Examination of Salvaged Video
After salvaging digital video files it is important to review the resulting data closely for potential anomalies. For instance, using MediaInfo to extract metadata from video files shows details related to its creation and format. The following screenshot shows metadata from a 3gp video extracted from the Motorola V3 memory dump, revealing that the embedded date-time stamp was set to an incorrect date.
Metadata within a 3gp video displayed using MediaInfo
In addition, reviewing individual frames within a salvaged video file can reveal anomalies such as portions of two unrelated videos being combined into one salvage file. The following screenshot shows frames extracted from a 3gp file using DCCI Video Validator revealing footage from two unrelated video files.
Frames extracted from digital video using DCCI Video Validator
Conclusions
When a video file is fragmented or the header of a video file is overwritten, carving methods that rely on header signatures and contiguous files will not salvage video files successfully and may even incorrectly combine unrelated video fragments into a single file or fail to detect the presence of video content altogether. However, using specialized tools such as defraser, a digital investigator may be able to salvage fragments of video files and piece them together into a valid video file. This process of reconstructing video fragments is time consuming and error prone, particularly when dealing with numerous video files on a single piece of storage media or mobile device. Therefore, whenever feasible, it is preferable to reconstruct the logical arrangement of data to extract the complete content of video files. Whichever method is most effective for salvaging digital video, it is important to examine the results closely to ensure the accuracy and completeness of the resulting videos. Such a review includes inspecting embedded metadata for anomalies and reviewing keyframes for possible fragments of unrelated video footage.
轉自 http://blog.cmdlabs.com/2011/05/30/salvaging-digital-video-fragments/
利用Format 指令執行簡單Wipe
2011/06/13
標籤：
資安工具
As versões mais recentes do Windows trazem um interessante recurso de sanitização utilizando o comando FORMAT do Windows. Já dei a dica no post Dados a venda no ML, e vou reforçar agora:
Nestas versões mais novas (Vista >), o bom e velho format ganhou um interessante parâmetro, o /p:passes , que realmente "zera" os setores do volume que se deseja formatar, "passes" vezes:
format e: /p:4
Com este comando, o drive E:\ foi sobrescrito 4 vezes com "zeros", e o resultado é o seguinte:
Todos os setores do disco literalmente "zerados"
轉自 http://forensics.luizrabelo.com.br/2011/05/wipe-no-format-do-windows-sem.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BrazilForensicsBlog+%28brazil+forensics+blog%29
訂閱：
文章 (Atom)
發表文章
