基于Volatility的內存分析技術Part 1如何理解

這期內容當中小編將會給大家?guī)碛嘘P基于Volatility的內存分析技術Part 1如何理解，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

內存取證(有時稱為內存分析)是指對計算機內存轉儲中易失性數(shù)據(jù)進行的一種分析。信息安全專業(yè)人員可以通過內存取證，來調查和識別那些不會在硬盤驅動器數(shù)據(jù)中留下痕跡的攻擊或惡意行為。

通過內存取證，安全人員可以了解運行時的各種系統(tǒng)活動，例如開放的網(wǎng)絡連接或最近執(zhí)行的命令和進程等。

程序在計算機上運行之前，首先需要被加載到內存中，這使得內存取證變得非常重要——這意味著所有被創(chuàng)建、檢查或刪除的程序或數(shù)據(jù)都將被保存到RAM中。這其中包括圖像、所有Web瀏覽活動、加密密鑰、網(wǎng)絡連接或注入的代碼片段。在許多情況下，某些證據(jù)只能在RAM中找到，例如在崩潰期間存在的開放網(wǎng)絡連接。由于攻擊者可以開發(fā)只駐留在內存中而不在硬盤落地的惡意軟件，從而使標準的計算機取證方法幾乎看不到它。這使得內存取證工具變得愈發(fā)重要。

Volatility是一個先進的內存取證框架。它為調查人員提供了許多自動工具，人們可以利用其先進的內存分析技術揭示主機上的惡意活動。需要指出的是，該框架是用python實現(xiàn)的，而且是開源的。該框架的下載地址為https://github.com/volatilityfoundation/volatility，相關的文檔地址為https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal。

我們將以Coreflood木馬為例，來介紹相關的內存取證方法。

Coreflood是由一群俄羅斯黑客創(chuàng)建并在2010年發(fā)布的木馬和僵尸網(wǎng)絡。FBI已經將“大約17個州或地方政府機構，包括1個警察局;3個機場;2個國防承包商;5個銀行或金融機構;大約30個學院或大學;大約20個醫(yī)院或醫(yī)療公司;以及數(shù)百家企業(yè)”[1]列入受感染系統(tǒng)的名單中。截至2011年5月。它已經感染了世界各地230多萬臺計算機;到目前為止，它仍然是一個巨大的威脅。——維基百科

對于該樣本軟件，可以通過下面的地址進行下載(.vmem文件)：

https://github.com/mgoffin/malwarecookbook/blob/master/16/6/coreflood.vmem.zip

這個文章系列的目標是借助于volatility來了解這個惡意軟件的行為，以及相應的內存取證方法。我將嘗試發(fā)掘所有關于Coreflood的取證工具，以了解這個惡意軟件背后的動機到底是什么。我希望能從這次取證分析中學到一些新的東西，并教給大家一些新的東西!

為了開始調查，我想先搞清楚主機上運行的進程。為此，我們只需借助于pslist命令，就能查看是否有明顯可疑的進程在運行。

Windows使用一個循環(huán)的雙鏈接列表_EPROCESS結構體來跟蹤所有的活動進程;并且，這個列表位于內核中。而Volatility就是利用了這個事實：首先，它會尋找PsActiveProcessHead指針，因為該指針指向內核的_EPROCESS結構體列表的起始位置;之后，Volatility會遍歷這個列表，從而找出正在運行的所有進程。

 主機上正在運行的所有進程：volatility -f coreflood.exe pslist命令的輸出結果

我們可以看到，似乎一切都很正常，不過有幾件事引起了我們的注意。當前，IE瀏覽器在運行，同時cmd也在運行，看來正確的做法是檢查出站連接，因為惡意軟件可能偽裝成Internet  Explorer瀏覽器，以隱藏自己與C&C的通信流量。

此外，我們也可以檢查一下cmd在那邊做什么，這一點將在后面討論。

一個最簡單的操作就是查看出站連接。如果IE出站連接沒有找到可疑之處，我們就需要從其他地方尋找惡意活動的蹤跡。

下面，我們將使用connscan命令來檢查之前終止的和當前活動的連接：

“要想使用池標簽掃描功能查找_TCPT_OBJECT結構體，請使用connscan命令。這樣做的好處是，我們不僅可以從活動的連接中查找證據(jù)，還可以從之前被終止的連接中搜索證據(jù)?！?amp;mdash;—摘自Volatility的官方文檔

實際上，這種工作方式就是先通過掃描物理內存，找到4個字節(jié)的簽名0x54455054(“TCPT”)，然后，解析出接下來的28個字節(jié)，并將其作為完整的_TCPT_OBJECT結構體。

 volatility -f coreflood.vmem connscan命令的輸出結果

從上面的輸出結果來看，主機好像正在進行正常的通信，所有的通信都是由pid  2044進程(IEXPLORE.EXE)創(chuàng)建的。我查了一下這些IP的地理位置，它們都是注冊在一些大公司的名下，比如微軟、AT&T等公司。當然，關于這些IP的數(shù)據(jù)可能已經改變了，因為當前考察的vmem文件已經有些陳舊了;此外，這些也可能是黑客為了欺騙調查人員而對這些IP地址數(shù)據(jù)做了手腳。

為了確保的確沒有惡意通信，我們應該檢查入站連接是否安全。為此，我們可以使用sockscan命令，該命令將掃描內存中的_ADDRESS_OBJECT結構體。通過掃描內存中的這個內存結構，我們可以深入了解以前打開的套接字和當前打開的套接字。

 volatility -f coreflood.vmem sockscan命令的輸出結果

正如我們所看到的，進程pid  2044(即IEXPLORE.EXE)中有一些非常奇怪的入站連接。這看起來非?？梢?，所以，是時候拿出我們的內存取證神器Volatility，檢查一下該進程中是否隱藏著惡意軟件了。

我們之所以說Volatility是一個內存取證神器，是因為它提供了許多功能強大的惡意軟件分析工具。

我們經常用到的第一個分析工具就是malfind命令。這個命令可用于尋找進程內存中的注入代碼。它是通過尋找已分配內存的段(通過查看VAD樹數(shù)據(jù)結構)，并檢查它們是否有未映射到磁盤上任何文件的可執(zhí)行代碼的線索來實現(xiàn)這一點的。

“VAD節(jié)點還引用了一些其他的內核結構體，這些結構體可能對調查人員非常有用……因此，如果該內存區(qū)被用于已映射的文件(如加載的DLL)，則可以引用相應的_FILE_OBJECT結構體，并提取文件的名稱。這可以為調查人員提供一種替代的方法來列出進程加載的模塊，然后可以與其他方法找到的模塊進行比較，從而找到庫注入和隱藏模塊的相關證據(jù)?！?amp;mdash;—Science  Direct

用于檢查一段內存是否包含注入代碼的方法是檢查VAD的頁面權限，例如EXECUTE權限等。如果內存中的某一段具有執(zhí)行權限，并且它沒有映射到磁盤上的任何可執(zhí)行文件的話，就說明這里很可能存在注入的代碼。

 volatility -f coreflood.vmem malfind命令的輸出結果，這里似乎存在誤報

正如我們在上圖中看到的，該命令的輸出結果好像并沒有帶來太多真正有價值的信息。

這可能是該惡意軟件沒有加載任何顯式PE(可移植可執(zhí)行文件)代碼到內存中，而只是注入了一些shellcode所致，又或者映像的頭部被分頁了所致。此外，還有一種可能——惡意軟件通過調用注入的DLL的ImageBase上的VirtualFree，從內存中清除PE的頭部，以避免檢測到。當然，也可能是由于某些原因，這部分內存被分頁或無法訪問。無論如何，我們還不能確定這里存在惡意活動，因為我們沒有找到確切的證據(jù)。

接下來我們可以使用的命令是apihooks。

“它可以用來查找IAT、EAT、Inline式hook，以及幾種特殊類型的hook。對于Inline  hook，它可以檢測直接和間接位置的CALL和JMP指令……以及對內核內存中未知代碼頁的調用?！?amp;mdash;—Volatility官方文檔

為了理解這里到底發(fā)生了什么，我們需要快速回顧一下IAT和EAT。

當可執(zhí)行文件第一次被加載時，Windows加載器將負責讀取文件的PE結構，并將可執(zhí)行文件的映像加載到內存中。其中一步，就是加載應用程序使用的所有dll，并將它們映射到進程地址空間。

此外，可執(zhí)行文件還會指出在每個dll中需要的所有函數(shù)。不過，由于函數(shù)地址不是靜態(tài)的，所以，我們必須開發(fā)一種機制，以允許修改這些變量，這樣就不必在運行時修改所有已編譯的代碼了。

這一點是通過導入地址表(IAT)實現(xiàn)的;而IAT，實際上就是由windows加載器在加載dll時所填寫的函數(shù)指針表。

EAT的工作方式和IAT基本一致，只不過它是供代碼庫用于將函數(shù)導出到映像可執(zhí)行文件中的，以便供程序從其中將函數(shù)地址導入到IAT中(具體細節(jié)我就不多說了)。

惡意軟件可以通過操縱這兩個內存結構體，使得可執(zhí)行文件調用其他函數(shù)，而非原本要調用的函數(shù)。

我之所以要在IEXPLORE.EXE上使用apihooks參數(shù)，是因為根據(jù)sockscan的輸出結果，我已經懷疑它可能被篡改了。

 我們將使用apihooks參數(shù)并將輸出結果保存在一個文本文件中

難以置信! Internet Explorer已經被鉤取了十幾次以調用同一個函數(shù)。

上圖內容摘自保存apihooks命令輸出結果的文本文件。實際上，這只是十幾個不同函數(shù)的hook中的一個而已;它們都調用同一個地址0x7ff82a6e。

我們可以看到，在這個例子中，惡意軟件在WINHTTP.dll中“掛鉤”了LoadLibrary。

LoadLibrary可用于將庫模塊加載到進程的地址空間中，并返回一個句柄，該句柄可用于GetProcAddress以獲取DLL函數(shù)的地址。因此，LoadLibrary是一個非常顯而易見的鉤取對象，因為我們知道很多PE都會使用其他dll，并導入這些庫中的相關函數(shù)。

我們需要搞清楚惡意軟件在這里試圖達到什么目的。為了做到這一點，我們需要嘗試深入到惡意軟件試圖執(zhí)行的那段代碼中。因此，我們要使用Volatility的volshell工具。Volshell是一個非常強大的工具，可以用來瀏覽內存的內容。我們可以跳轉到內存的各個部分，之后，我們不僅可以查看其中的內容，還可以反匯編或讀取其中的內容。

 輸入volshell命令，然后按照流程操作即可。

在輸入volshell命令后，我使用cc(

上面高亮顯示的文字(從上到下)向我們展示了被鉤住的地址，在它的下面，還高亮顯示了惡意軟件希望我們的代碼要跳轉到的地址。

如上圖所示，為了弄清楚該惡意軟件的意圖，我們需要反匯編相關的地址。為此，我將這個地址作為參數(shù)復制到volshell命令dis(

我們最終得到的輸出結果，就是惡意注入的代碼。

關于這個惡意代碼的作用，我們將在后面的文章中加以介紹。心急的讀者，也可以自己動手嘗試一下。

上述就是小編為大家分享的基于Volatility的內存分析技術Part 1如何理解了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業(yè)資訊頻道。