由于操作系統(tǒng)內(nèi)部日益增加的安全標(biāo)準(zhǔn)和惡意軟件檢測(cè)技術(shù)的快速改進(jìn)，現(xiàn)如今的惡意軟件作者開始利用由內(nèi)存執(zhí)行。PE的內(nèi)存執(zhí)行或者無文件執(zhí)行可以被定義為在內(nèi)存中執(zhí)行一個(gè)編譯的PE文件，手動(dòng)運(yùn)行OS加載程序在正常PE文件加載時(shí)應(yīng)有的操作。惡意軟件的內(nèi)存執(zhí)行有助于混淆和反模擬技術(shù)。另外，正在使用這種方法的惡意軟件在系統(tǒng)上留下的痕跡更少，因?yàn)閮?nèi)存執(zhí)行沒必要在硬盤上占有一個(gè)文件。內(nèi)存執(zhí)行方法和多階段注入模型組合，可以使用及其小的程序加載器將惡意軟件注入系統(tǒng)。加載程序的唯一目的是通過鏈接到遠(yuǎn)程系統(tǒng)來加載和執(zhí)行實(shí)際的惡意軟件代碼。使用小型加載器的代碼很難被安全產(chǎn)品檢測(cè)，因?yàn)榧虞d器的代碼片段在合法應(yīng)用程序中也普遍使用。使用這種方法的惡意軟件仍然可以通過掃描內(nèi)存并檢查進(jìn)程的行為來檢測(cè)，但是在安全性方面，這些操作難以實(shí)施，因?yàn)橘Y源使用量較高而且代價(jià)昂貴。(Ramilli, 2010[1])

目前普遍增長(zhǎng)的趨勢(shì)是使用機(jī)器學(xué)習(xí)機(jī)制自動(dòng)檢測(cè)惡意軟件，給系統(tǒng)提供巨大的數(shù)據(jù)集，如所有的機(jī)器學(xué)習(xí)程序一樣，這種機(jī)制可以更快更準(zhǔn)確的吸收更多的惡意軟件樣本。這些機(jī)制可以提供大量的人類惡意軟件分析師無法處理的級(jí)別的樣本。Malware Detection Using Machine Learning[2]由BitDefender Romania Labs的 Gavrilu? Drago?發(fā)表的這篇論文廣泛的闡述了機(jī)器學(xué)習(xí)在惡意軟件檢測(cè)中的使用的內(nèi)部原理。根據(jù)Konrad Rieck的論文 Automatic Analysis of Malware Behavior using Machine Learning[3]，只要有足夠的數(shù)據(jù)和時(shí)間，假陽性的結(jié)果將趨近于0，并且惡意軟件的檢測(cè)將在新的惡意軟件樣本上產(chǎn)生顯著效果。

這項(xiàng)工作的主要目的是為PE文件開發(fā)一種新的加殼方法，可以改變將惡意軟件傳送到系統(tǒng)的方式。取代試圖找到新的反檢測(cè)技術(shù)來提供機(jī)器學(xué)習(xí)的數(shù)據(jù)集，通過無文件代碼注入將payload加載到系統(tǒng)中從而繞過絕大多數(shù)的安全機(jī)制。通過這種新的加殼方法，可以將PE文件轉(zhuǎn)化為可用于常見軟件漏洞（如緩沖區(qū)溢出）的多階段注入的payload。

以下的技術(shù)是我們殼的靈感來源：

反射式DLL注入[4]是一個(gè)非常好的由 Stephen Fewer 開發(fā)的庫注入技術(shù)，該方法是開發(fā)這個(gè)名為琥珀的殼的主要啟發(fā)點(diǎn)。這種技術(shù)允許在內(nèi)存執(zhí)行中用反射編程的方法編寫特定的DLL。由于采用了反射編程方法，這種技術(shù)允許多階段payload的部署。除了這種技術(shù)的諸多優(yōu)點(diǎn)之外幾乎沒有限制。

第一個(gè)限制是所需的文件格式，該技術(shù)期望將惡意軟件作為DLL文件進(jìn)行開發(fā)或重新編譯，不幸的是在大多數(shù)情況下，將已編譯的EXE文件轉(zhuǎn)換為DLL是不可能的，或者需要對(duì)二進(jìn)制文件進(jìn)行大量工作。

第二個(gè)限制是需要重定位數(shù)據(jù)。反射型DLL注入技術(shù)需要重定位數(shù)據(jù)來調(diào)整內(nèi)存中DLL的基址。同時(shí)，這種方法已經(jīng)存在了一段時(shí)間了，這意味著最新的安全產(chǎn)品可以很容易的檢測(cè)到反射型DLL注入的使用。我們的新工具，琥珀將為這些限制提供解決方案。

Process Hollowing[5]是另一種廣為人知的內(nèi)存執(zhí)行方法，使用公開的WindowsAPI創(chuàng)建新的進(jìn)程然后將PE文件映射進(jìn)該進(jìn)程。這種旨在降低惡意軟件檢測(cè)率的加密器和殼中很受歡迎。但是這個(gè)方法也有幾個(gè)缺點(diǎn)。由于最新的Windows操作系統(tǒng)中的地址空間布局隨機(jī)化（ASLR）安全措施，創(chuàng)建新進(jìn)程時(shí)內(nèi)存區(qū)域是隨機(jī)的，因?yàn)閜rocess hollowing同樣也需要實(shí)現(xiàn)在最新的Windows操作系統(tǒng)上的鏡像基址重定位。如上所述，基址重定位需要PE文件內(nèi)的重定位數(shù)據(jù)。另一個(gè)缺點(diǎn)是由于特定文件的映射和進(jìn)程創(chuàng)建API函數(shù)的使用有特定的順序，這種方法很容易被安全產(chǎn)品識(shí)別。

Hyperion[6] 是一款PE加密器，由Christian Amman 于 2012開發(fā)并發(fā)布。它解釋了運(yùn)行時(shí)加密器的理論知識(shí)以及實(shí)現(xiàn)原理。在開發(fā)Hyperion是使用的PE解析方法和設(shè)計(jì)視角對(duì)我們的POC殼很有幫助。

通過模仿OS的PE加載器，可以在OS內(nèi)存中執(zhí)行編譯的二進(jìn)制文件是該殼的基本原理。在Windows上，PE加載器執(zhí)行許多重要的事情，諸如將問價(jià)映射到內(nèi)存并解析導(dǎo)入函數(shù)的地址是執(zhí)行PE文件最重要的步驟。目前用于在內(nèi)存中執(zhí)行EXE文件的方法是使用特定的WindowsAPI函數(shù)來模擬WindowsPE加載器。通常的方法是使用NtMapViewOfSection,MapViewOfFile和CreateFileMapping函數(shù)。這些函數(shù)的使用通常會(huì)造成可疑行為，增加惡意軟件檢測(cè)的可能性。

開發(fā)這款殼的關(guān)鍵方面之一就是盡量減少API函數(shù)。為了避免使用可疑文件映射API函數(shù)，我們的殼使用預(yù)先封裝的PE映像，此外，惡意軟件的執(zhí)行發(fā)生在目標(biāo)進(jìn)程內(nèi)部，不使用WindowsAPICreateProcess函數(shù)。目標(biāo)進(jìn)程內(nèi)執(zhí)行的惡意軟件以相同的進(jìn)程權(quán)限運(yùn)行，因?yàn)樗鼈児蚕砹税M(jìn)程特權(quán)信息和配置的TEB塊。琥珀有兩種你類型的stub，其中一個(gè)用于支持ASLR，另一個(gè)用于被剝離或不具有任何重定位數(shù)據(jù)的EXE文件。ASLR stub僅使用4個(gè)Windows API，其他的stub僅使用3個(gè)大多數(shù)合法應(yīng)用程序廣泛使用的API。

ASLR stub：

VirtualAlloc

CreateThread

LoadLibraryA

GetProcAddress

非ASLR stub：

VirtualProtect

LoadLibraryA

GetProcAddress

為了在運(yùn)行時(shí)調(diào)用這些API，琥珀使用了Stephen Fewer的反射式DLL注入[4]方法所使用的公開的EAT解析技術(shù)。該技術(shù)簡(jiǎn)單在內(nèi)存中通過PEB來定位InMemoryOrderModulesList結(jié)構(gòu)。定位該結(jié)構(gòu)后，可以讀取所有加載的DLL導(dǎo)出表，讀取由InMemoryOrderModuleList指向的每個(gè)_LDR_DATA_TABLE_ENTRY結(jié)構(gòu)。在訪問到DLL的導(dǎo)出表之后，將先前計(jì)算出的每個(gè)導(dǎo)出函數(shù)名的ROR(右移)13散列值進(jìn)行比較，直到匹配。

琥珀的加殼方法還提供了集中替代的WindowsAPI使用方法，其中之一是使用固定的API地址，如果使用者熟知承載琥珀的遠(yuǎn)程進(jìn)程的相關(guān)信息的話。使用固定API地址將直接繞過最新的操作系統(tǒng)級(jí)漏洞利用，檢查導(dǎo)出表地址刪除API地址查找代碼將減少總體的payload大小。另一種替代技術(shù)可用于定位所需功能的地址，例如 Josh Pitts 在 “Teaching Old Shellcode New Tricks”[7]中展示的技巧。當(dāng)前版本的琥珀加殼器僅支持固定API地址和EAT解析技術(shù)，但I(xiàn)AT解析將在下一個(gè)版本中添加。

為了生成實(shí)際的琥珀payload，首先加殼器創(chuàng)建一個(gè)惡意軟件的內(nèi)存映像，生成的內(nèi)存映射文件包含PE的所有部分，PE header和未使用的區(qū)段空間使用0填充。

獲取惡意軟件的映射之后，加殼器將檢查所提供的EXE的ASLR的兼容性，如果EXE是ASLR兼容加殼器將添加相關(guān)的stub，如果PE使用固定基址就不添加。此刻，琥珀的payload就完成了：

執(zhí)行ASLR stub需要5個(gè)步驟：

1. 申請(qǐng)內(nèi)存

2. 修復(fù)導(dǎo)入函數(shù)

3. 重定位

4. FileMapping替換

5. 執(zhí)行

在內(nèi)存申請(qǐng)階段，stub通過調(diào)用VirtualAlloc函數(shù)來分配惡意軟件映像大小相同的RWE內(nèi)存空間，

這個(gè)內(nèi)存空間將是重定位過程后惡意軟件新的基址。第二階段，琥珀的stub將解析導(dǎo)入函數(shù)的地址，并將地址寫入惡意軟件的導(dǎo)入表。

地址戒心階段與WindowsPE加載程序使用的方法非常類似，琥珀的stub將解析映射的惡意軟件映像的導(dǎo)入表，并通過LoadLibraryA函數(shù)加載惡意軟件的IMAGE_IMPORT_DESCRIPTOR中使用的每個(gè)DLL。

在加載完所需的DLL后，stub會(huì)保存每個(gè)DLL的句柄，并在GetProcAddressAPI的幫助下，從加載的DLL中查找導(dǎo)入函數(shù)的地址。IMAGE_IMPORT_DESCRIPTOR還包含一個(gè)指向名為import name表的結(jié)構(gòu)指針，該結(jié)構(gòu)的導(dǎo)入函數(shù)名與導(dǎo)入地址表(IAT)順序相同，在調(diào)用GetProcAddress時(shí)，stub以前加載的DLL句柄和導(dǎo)入函數(shù)的名稱為參數(shù)。

每個(gè)返回的函數(shù)地址都將寫入（IAT），每個(gè)IAT之間由4字節(jié)填充。此過程持續(xù)到導(dǎo)入表解析結(jié)束，加載完所需的DLL和解析完導(dǎo)入表之后，第二階段完成。

在第三階段，stub將根據(jù)VirtualAlloc返回的地址開始重定位過程，這幾乎和Windows本身的PE加載器完全相同，stub首先計(jì)算當(dāng)前加載基址和原始加載基址之間的偏移delta，然后將delta加上重定位白的每一個(gè)條目。在第四階段，stub將文件映射到先前分配的空間中，采用單字節(jié)移動(dòng)的方式來移動(dòng)內(nèi)存。

最后階段，stub將通過調(diào)用CreateThread從惡意軟件的入口處創(chuàng)建一個(gè)新的線程。創(chuàng)建新線程的原因是為惡意軟件創(chuàng)建一個(gè)新的可擴(kuò)展棧，另外在新線程中執(zhí)行惡意軟件并不會(huì)映像目標(biāo)進(jìn)程的執(zhí)行狀態(tài)。創(chuàng)建惡意軟件后，線程將恢復(fù)執(zhí)行，返回到第一個(gè)調(diào)用者或stub，然后跳轉(zhuǎn)到一個(gè)死循環(huán)，阻塞防線線程，惡意軟件線程成功運(yùn)行。

非ASLR Stub的執(zhí)行需要4個(gè)步驟：

1. 內(nèi)存申請(qǐng)

2. 解析IAT

3. 文件映射替換

4. 執(zhí)行

如果惡意軟件被剝離或者沒有重定位信息，則無法將其放到首選基地址。在這種情況下，stub嘗試通過調(diào)用VirtualPtotect函數(shù)來更改目標(biāo)進(jìn)程的內(nèi)存訪問權(quán)限，大小為惡意軟件的大小。如果出現(xiàn)這種情況，首選極其之和目標(biāo)進(jìn)程代碼段可能由重疊，并且目標(biāo)進(jìn)程在執(zhí)行payload后將無法執(zhí)行。

stub可能無法更改指定區(qū)域的訪問權(quán)限，這又多個(gè)原因，如執(zhí)行的內(nèi)存返回不在當(dāng)前進(jìn)程頁邊界內(nèi)（原因最可能是ASLR），或執(zhí)行的地址與stack guard重合。這是stub的主要限制，如果提供的惡意軟件沒有ASLR支持（內(nèi)部沒有重定位數(shù)據(jù)），并且stub不能更改目標(biāo)進(jìn)程訪問權(quán)限，則無法繼續(xù)。在某些情況下，stub成功更改內(nèi)存區(qū)域權(quán)限，但立即崩潰，這是由于覆蓋部分中運(yùn)行著多個(gè)線程引起的。

如果目標(biāo)進(jìn)程在fix stub執(zhí)行時(shí)有多個(gè)線程，則可能會(huì)由于更改內(nèi)存權(quán)限或覆蓋到正在運(yùn)行的部分崩潰。然而，如果不使用具有fix stub的多級(jí)payload，則這些限制無關(guān)緊要，當(dāng)前的POC封裝器可以相應(yīng)的調(diào)整生成EXE文件的基址和stub payload的位置。如果內(nèi)存分配結(jié)束，第一階段就完成了。第二階段與上邊ASLR stub方法相同。完成后同樣使用memcpy移動(dòng)內(nèi)存到先前修改的內(nèi)存區(qū)域。

在最后階段，stub跳轉(zhuǎn)到惡意軟件的入口點(diǎn)并執(zhí)行，不創(chuàng)建新線程。不幸的是使用非ASLR stub的程序不能繼續(xù)之前的運(yùn)行狀態(tài)。

在不久的將來，操作系統(tǒng)將會(huì)采取的安全措施將會(huì)減少惡意軟件的攻擊面。微軟已經(jīng)在2017年5月2日發(fā)布了Windows 10 S[8]，這個(gè)操作系統(tǒng)基本上是Windows10的配置了更高安全性的版本。這個(gè)操作系統(tǒng)采取的主要預(yù)防措施之一是不允許安裝除WindowsStore以外的程序。這種操作系統(tǒng)采用的白名單方法將對(duì)通過可執(zhí)行文件感染系統(tǒng)的惡意軟件產(chǎn)生巨大影響。

在這種情況下，多級(jí)內(nèi)存執(zhí)行payload將成為最有效的攻擊方法之一。由于stub位置的獨(dú)立性，它允許多階段攻擊模型，當(dāng)前的POC加殼器能夠從復(fù)雜的PE文件中生成一個(gè)payload，可以從內(nèi)存加載和執(zhí)行，如常規(guī)的shell code注入攻擊。在這種過度限制的系統(tǒng)用中，琥珀的多階段兼容性允許利用基于內(nèi)存的常見軟件漏洞，例如棧和堆的緩沖區(qū)溢出。

然而由于fix stub的限制，建議在執(zhí)行多級(jí)感染攻擊時(shí)使用ASLR支持的EXE文件。由POC加殼器生成的階段payload與從Metasploit Framework [9]生成的小型加載器shellcode和有效載荷兼容，這也就意味著琥珀可以用于Metasploit Framework 中多級(jí)meterpreter shell code。

源碼如下，歡迎fork以及contribute！

 https://github.com/EgeBalci/Amber

當(dāng)前版本（2017.10.19）檢測(cè)率令人相當(dāng)滿意，但由于這是一個(gè)公共項(xiàng)目，目前的檢測(cè)分?jǐn)?shù)不可避免的會(huì)上升。

當(dāng)沒有額外的參數(shù)傳遞（只有文件名）加殼器生成的多級(jí)載荷使用多字節(jié)隨機(jī)密鑰執(zhí)行基本的XOR加密，然后將其編譯成EXE文件，并加入少量額外的防檢測(cè)功能。生成的EXE文件在解密payload并執(zhí)行所需的環(huán)境檢查之后，像常規(guī)的shell code一樣執(zhí)行payload。這個(gè)特殊的例子時(shí)用12字節(jié)XOR key（./amber mimikatz.exe -ks 12）打包的mimikatz.exe（sha256- 9369b34df04a2795de083401dda4201a2da2784d1384a6ada2d773b3a81f8dad）文件。在VirusTotal上，加殼前的mimikatz.exe文件的檢測(cè)率為51/66。在這個(gè)特殊的示例中，加殼程序使用默認(rèn)方式來查找使用哈希API的Windows API地址，避免使用hash API會(huì)降低檢測(cè)率。目前加殼器支持IAT偏移的固定地址的使用，下一個(gè)版本將包括IAT解析器shellcode以獲得更多的替代API地址查找方法。

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

http:///id/1ikb99sNVrOM

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

這項(xiàng)工作為PE文件引入了新一代的加殼方法，但不支持.NET可執(zhí)行文件，未來的工作可能包括對(duì)64位PE文件和.NET文件的支持。另外，這種方法的隱秘性方面可以有更多的改進(jìn)。在使用RWE權(quán)限完成內(nèi)存分配之后，根據(jù)映像對(duì)應(yīng)的區(qū)段權(quán)限修改該區(qū)段對(duì)應(yīng)內(nèi)存的權(quán)限可能會(huì)降低檢測(cè)率。在地址解析完成后擦除PE頭可以更難檢測(cè)。該項(xiàng)目在未來將繼續(xù)保持開源。