由於作業系統內部日益增加的安全標準和惡意軟體檢測技術的快速改進，現如今的惡意軟體作者開始利用由記憶體執行。PE的記憶體執行或者無檔案執行可以被定義為在記憶體中執行一個編譯的PE檔案，手動執行OS載入程式在正常PE檔案載入時應有的操作。惡意軟體的記憶體執行有助於混淆和反模擬技術。另外，正在使用這種方法的惡意軟體在系統上留下的痕跡更少，因為記憶體執行沒必要在硬碟上佔有一個檔案。記憶體執行方法和多階段注入模型組合，可以使用及其小的程式載入器將惡意軟體注入系統。載入程式的唯一目的是通過連結到遠端系統來載入和執行實際的惡意軟體程式碼。使用小型載入器的程式碼很難被安全產品檢測，因為載入器的程式碼片段在合法應用程式中也普遍使用。使用這種方法的惡意軟體仍然可以通過掃描記憶體並檢查程式的行為來檢測，但是在安全性方面，這些操作難以實施，因為資源使用量較高而且代價昂貴。(Ramilli,2010[1])

目前普遍增長的趨勢是使用機器學習機制自動檢測惡意軟體，給系統提供巨大的資料集，如所有的機器學習程式一樣，這種機制可以更快更準確的吸收更多的惡意軟體樣本。這些機制可以提供大量的人類惡意軟體分析師無法處理的級別的樣本。Malware Detection Using Machine Learning[2]由BitDefender Romania Labs的 Gavriluţ Dragoş發表的這篇論文廣泛的闡述了機器學習在惡意軟體檢測中的使用的內部原理。根據Konrad Rieck的論文Automatic Analysis of Malware Behavior using Machine Learning[3]，只要有足夠的資料和時間，假陽性的結果將趨近於0，並且惡意軟體的檢測將在新的惡意軟體樣本上產生顯著效果。

這項工作的主要目的是為PE檔案開發一種新的加殼方法，可以改變將惡意軟體傳送到系統的方式。取代試圖找到新的反檢測技術來提供機器學習的資料集，通過無檔案程式碼注入將payload載入到系統中從而繞過絕大多數的安全機制。通過這種新的加殼方法，可以將PE檔案轉化為可用於常見軟體漏洞（如緩衝區溢位）的多階段注入的payload。

已知方法

以下的技術是我們殼的靈感來源：

反射式DLL注入[4]是一個非常好的由Stephen Fewer 開發的庫注入技術，該方法是開發這個名為琥珀的殼的主要啟發點。這種技術允許在記憶體執行中用反射程式設計的方法編寫特定的DLL。由於採用了反射程式設計方法，這種技術允許多階段payload的部署。除了這種技術的諸多優點之外幾乎沒有限制。第一個限制是所需的檔案格式，該技術期望將惡意軟體作為DLL檔案進行開發或重新編譯，不幸的是在大多數情況下，將已編譯的EXE檔案轉換為DLL是不可能的，或者需要對二進位制檔案進行大量工作。第二個限制是需要重定位資料。反射型DLL注入技術需要重定位資料來調整記憶體中DLL的基址。同時，這種方法已經存在了一段時間了，這意味著最新的安全產品可以很容易的檢測到反射型DLL注入的使用。我們的新工具，琥珀將為這些限制提供解決方案。

Process Hollowing[5]是另一種廣為人知的記憶體執行方法，使用公開的WindowsAPI建立新的程式然後將PE檔案對映進該程式。這種旨在降低惡意軟體檢測率的加密器和殼中很受歡迎。但是這個方法也有幾個缺點。由於最新的Windows作業系統中的地址空間佈局隨機化（ASLR）安全措施，建立新程式時記憶體區域是隨機的，因為process

hollowing同樣也需要實現在最新的Windows作業系統上的映象基址重定位。如上所述，基址重定位需要PE檔案內的重定位資料。另一個缺點是由於特定檔案的對映和程式建立API函式的使用有特定的順序，這種方法很容易被安全產品識別。

Hyperion[6] 是一款PE加密器，由Christian Amman 於 2012開發併發布。它解釋了執行時加密器的理論知識以及實現原理。在開發Hyperion是使用的PE解析方法和設計視角對我們的POC殼很有幫助。

技術細節

通過模仿OS的PE載入器，可以在OS記憶體中執行編譯的二進位制檔案是該殼的基本原理。在Windows上，PE載入器執行許多重要的事情，諸如將問價對映到記憶體並解析匯入函式的地址是執行PE檔案最重要的步驟。目前用於在記憶體中執行EXE檔案的方法是使用特定的WindowsAPI函式來模擬WindowsPE載入器。通常的方法是使用NtMapViewOfSection,MapViewOfFile和CreateFileMapping函式。這些函式的使用通常會造成可疑行為，增加惡意軟體檢測的可能性。開發這款殼的關鍵方面之一就是儘量減少API函式。為了避免使用可疑檔案對映API函式，我們的殼使用預先封裝的PE映像，此外，惡意軟體的執行發生在目標程式內部，不使用WindowsAPICreateProcess函式。目標程式內執行的惡意軟體以相同的程式許可權執行，因為它們共享了包含程式特權資訊和配置的TEB塊。琥珀有兩種你型別的stub，其中一個用於支援ASLR，另一個用於被剝離或不具有任何重定位資料的EXE檔案。ASLR

stub僅使用4個Windows API，其他的stub僅使用3個大多數合法應用程式廣泛使用的API。

ASLR stub：

VirtualAlloc

CreateThread

LoadLibraryA

GetProcAddress

非ASLR stub：

VirtualProtect

LoadLibraryA

GetProcAddress

為了在執行時呼叫這些API，琥珀使用了Stephen Fewer的反射式DLL注入[4]方法所使用的公開的EAT解析技術。該技術簡單在記憶體中通過PEB來定位InMemoryOrderModulesList結構。定位該結構後，可以讀取所有載入的DLL匯出表，讀取由InMemoryOrderModuleList指向的每個_LDR_DATA_TABLE_ENTRY結構。在訪問到DLL的匯出表之後，將先前計算出的每個匯出函式名的ROR(右移)13雜湊值進行比較，直到匹配。琥珀的加殼方法還提供了集中替代的WindowsAPI使用方法，其中之一是使用固定的API地址，如果使用者熟知承載琥珀的遠端程式的相關資訊的話。使用固定API地址將直接繞過最新的作業系統級漏洞利用，檢查匯出表地址刪除API地址查詢程式碼將減少總體的payload大小。另一種替代技術可用於定位所需功能的地址，例如Josh Pitts 在 “Teaching Old Shellcode New Tricks”[7]中展示的技巧。當前版本的琥珀加殼器僅支援固定API地址和EAT解析技術，但IAT解析將在下一個版本中新增。

生成payload

為了生成實際的琥珀payload，首先加殼器建立一個惡意軟體的記憶體映像，生成的記憶體對映檔案包含PE的所有部分，PE header和未使用的區段空間使用0填充。

獲取惡意軟體的對映之後，加殼器將檢查所提供的EXE的ASLR的相容性，如果EXE是ASLR相容加殼器將新增相關的stub，如果PE使用固定基址就不新增。此刻，琥珀的payload就完成了：

ASLR Stub的執行

執行ASLR stub需要5個步驟：

——申請記憶體

——修復匯入函式

——重定位

——FileMapping替換

——執行

在記憶體申請階段，stub通過呼叫VirtualAlloc函式來分配惡意軟體映像大小相同的RWE記憶體空間，

這個記憶體空間將是重定位過程後惡意軟體新的基址。第二階段，琥珀的stub將解析匯入函式的地址，並將地址寫入惡意軟體的匯入表。

地址戒心階段與WindowsPE載入程式使用的方法非常類似，琥珀的stub將解析對映的惡意軟體映像的匯入表，並通過LoadLibraryA函式載入惡意軟體的IMAGE_IMPORT_DESCRIPTOR中使用的每個DLL。

在載入完所需的DLL後，stub會儲存每個DLL的控制程式碼，並在GetProcAddressAPI的幫助下，從載入的DLL中查詢匯入函式的地址。IMAGE_IMPORT_DESCRIPTOR還包含一個指向名為import name表的結構指標，該結構的匯入函式名與匯入地址表(IAT)順序相同，在呼叫GetProcAddress時，stub以前載入的DLL控制程式碼和匯入函式的名稱為引數。每個返回的函式地址都將寫入（IAT），每個IAT之間由4位元組填充。此過程持續到匯入表解析結束，載入完所需的DLL和解析完匯入表之後，第二階段完成。

在第三階段，stub將根據VirtualAlloc返回的地址開始重定位過程，這幾乎和Windows本身的PE載入器完全相同，stub首先計算當前載入基址和原始載入基址之間的偏移delta，然後將delta加上重定位白的每一個條目。在第四階段，stub將檔案對映到先前分配的空間中，採用單位元組移動的方式來移動記憶體。

最後階段，stub將通過呼叫CreateThread從惡意軟體的入口處建立一個新的執行緒。建立新執行緒的原因是為惡意軟體建立一個新的可擴充套件棧，另外在新執行緒中執行惡意軟體並不會映像目標程式的執行狀態。建立惡意軟體後，執行緒將恢復執行，返回到第一個呼叫者或stub，然後跳轉到一個死迴圈，阻塞防線執行緒，惡意軟體執行緒成功執行。

非ASLR Stub的執行

非ASLR Stub的執行需要4個步驟：

——記憶體申請

——解析IAT

——檔案對映替換

——執行

如果惡意軟體被剝離或者沒有重定位資訊，則無法將其放到首選基地址。在這種情況下，stub嘗試通過呼叫VirtualPtotect函式來更改目標程式的記憶體訪問許可權，大小為惡意軟體的大小。如果出現這種情況，首選極其之和目標程式程式碼段可能由重疊，並且目標程式在執行payload後將無法執行。

stub可能無法更改指定區域的訪問許可權，這又多個原因，如執行的記憶體返回不在當前程式頁邊界內（原因最可能是ASLR），或執行的地址與stack

guard重合。這是stub的主要限制，如果提供的惡意軟體沒有ASLR支援（內部沒有重定位資料），並且stub不能更改目標程式訪問許可權，則無法繼續。在某些情況下，stub成功更改記憶體區域許可權，但立即崩潰，這是由於覆蓋部分中執行著多個執行緒引起的。如果目標程式在fix

stub執行時有多個執行緒，則可能會由於更改記憶體許可權或覆蓋到正在執行的部分崩潰。然而，如果不使用具有fix

stub的多級payload，則這些限制無關緊要，當前的POC封裝器可以相應的調整生成EXE檔案的基址和stub

payload的位置。如果記憶體分配結束，第一階段就完成了。第二階段與上邊ASLR

stub方法相同。完成後同樣使用memcpy移動記憶體到先前修改的記憶體區域。

在最後階段，stub跳轉到惡意軟體的入口點並執行，不建立新執行緒。不幸的是使用非ASLR stub的程式不能繼續之前的執行狀態。

多階段程式

在不久的將來，作業系統將會採取的安全措施將會減少惡意軟體的攻擊面。微軟已經在2017年5月2日釋出了Windows10 S[8]，這個作業系統基本上是Windows10的配置了更高安全性的版本。這個作業系統採取的主要預防措施之一是不允許安裝除WindowsStore以外的程式。這種作業系統採用的白名單方法將對通過可執行檔案感染系統的惡意軟體產生巨大影響。在這種情況下，多級記憶體執行payload將成為最有效的攻擊方法之一。由於stub位置的獨立性，它允許多階段攻擊模型，當前的POC加殼器能夠從複雜的PE檔案中生成一個payload，可以從記憶體載入和執行，如常規的shellcode注入攻擊。在這種過度限制的系統用中，琥珀的多階段相容性允許利用基於記憶體的常見軟體漏洞，例如棧和堆的緩衝區溢位。

然而由於fix stub的限制，建議在執行多級感染攻擊時使用ASLR支援的EXE檔案。由POC加殼器生成的階段payload與從Metasploit Framework [9]生成的小型載入器shellcode和有效載荷相容，這也就意味著琥珀可以用於Metasploit Framework中多級meterpreter shell code。

原始碼如下，歡迎fork以及contribute！

https://github.com/EgeBalci/Amber

被檢出率

當前版本（2017.10.19）檢測率令人相當滿意，但由於這是一個公共專案，目前的檢測分數不可避免的會上升。

當沒有額外的引數傳遞（只有檔名）加殼器生成的多級載荷使用多位元組隨機金鑰執行基本的XOR加密，然後將其編譯成EXE檔案，並加入少量額外的防檢測功能。生成的EXE檔案在解密payload並執行所需的環境檢查之後，像常規的shell

code一樣執行payload。這個特殊的例子時用12位元組XOR key（./amber mimikatz.exe -ks 12）打包的mimikatz.exe（sha256-

9369b34df04a2795de083401dda4201a2da2784d1384a6ada2d773b3a81f8dad）檔案。在VirusTotal上，加殼前的mimikatz.exe檔案的檢測率為51/66。在這個特殊的示例中，加殼程式使用預設方式來查詢使用雜湊API的Windows

API地址，避免使用hash API會降低檢測率。目前加殼器支援IAT偏移的固定地址的使用，下一個版本將包括IAT解析器shellcode以獲得更多的替代API地址查詢方法。

VirusTotal檢測

https://www.virustotal.com/#/file/3330d02404c56c1793f19f5d18fd5865cadfc4bd015af2e38ed0671f5e737d8a/detection

VirusCheckmate Result

http://viruscheckmate.com/id/1ikb99sNVrOM

NoDistribute

https://nodistribute.com/result/image/7uMa96SNOY13rtmTpW5ckBqzAv.png

未來工作

這項工作為PE檔案引入了新一代的加殼方法，但不支援.NET可執行檔案，未來的工作可能包括對64位PE檔案和.NET檔案的支援。另外，這種方法的隱祕性方面可以有更多的改進。在使用RWE許可權完成記憶體分配之後，根據映像對應的區段許可權修改該區段對應記憶體的許可權可能會降低檢測率。在地址解析完成後擦除PE頭可以更難檢測。該專案在未來將繼續保持開源。

本文由看雪翻譯小組 zplusplus 編譯，來源pentest's blog@Ege Balci