2021 年 4 月，研究人員深入分析了 Cobalt Strike滲透測試技術，以及它的一些簽名規避技術是如何在檢測技術下失效的。在本文中，我們將深入討論Metasploit，這是一個可以與Cobalt Strike互操作的常用框架。

在本文中，我們將討論以下主題：

shellcode的導入解析——Metasploit shellcode如何定位來自其他DLL的函數，以及我們如何預先計算這些值來解析來自其他有效載荷變體的任何導入；

逆向shell的執行流程——該過程非常簡單；

破壞 Metasploit 導入解析——一種非侵入性欺騙技術(不涉及鉤子)，讓 Metasploit 以高可信度通知防病毒軟件 (AV)。

對于這個分析，研究人員在 v6.0.30-dev 版本下使用 Metasploit 生成了研究人員自己的 shellcode。使用以下命令生成的惡意樣本的結果為 3792f355d1266459ed7c5615dac62c3a5aa63cf9e2c3c0f4ba036e6728763903 的 SHA256 哈希值，并且可以在 VirusTotal 上找到，供愿意自己嘗試的讀者使用。

msfvenom -p windows/shell_reverse_tcp -a x86 > shellcode.vir

在整個分析過程中，我們重新命名了函數、變量和偏移量，以反映它們的作用并提高清晰度。

初步分析

在本節中，研究人員將概述確定下一步分析（導入解析和執行流分析）所遵循的初始邏輯。

雖然典型的可執行文件包含一個或多個入口點（導出的函數、TLS 回調等），但 shellcode 可以被視為最原始的代碼格式，其中初始執行從第一個字節開始。

從初始字節分析生成的 shellcode 概述了兩個操作：

從分析的角度來看，①處的第一條指令可以忽略。cld操作清除方向標志，確保字符串數據是向前讀取而不是向后讀取(例如:cmd與dmc的區別)。② 處的第二個調用操作將執行轉移到研究人員命名為 Main 的函數中，該函數將包含 shellcode 的主要邏輯。

調用 Main 函數的反匯編 shellcode

在Main函數中，我們觀察到額外的調用，比如下圖中突出顯示的四個調用(③、④、⑤和⑥)。這些調用針對一個尚未識別的函數，其地址存儲在ebp寄存器中。要理解這個函數的位置，我們需要退后一步并了解調用指令的操作方式。

Main 函數的反匯編

調用指令通過執行兩個操作將執行轉移到目標目的地：

它將返回地址(位于調用指令之后的指令的內存地址)壓入堆棧。該地址稍后可以被 ret 指令用于將執行從被調用函數（被調用者）返回到調用函數（調用者）；

它將執行轉移到目標目的地（被調用者），就像 jmp 指令一樣；

因此，來自Main函數③的第一個pop指令將調用者的返回地址存儲到ebp寄存器中。這個返回地址隨后被作為函數調用，在偏移量0x99、0xA9和0xB8(④、⑤和⑥)處調用。這種模式，在每次調用之前出現類似的推送，往往表明存儲在 ebp 中的返回地址是動態導入解析函數。

“普通”可執行文件(例如：Windows上的可移植可執行文件)包含必要的信息，因此，一旦被操作系統(OS)加載程序加載，代碼就可以調用導入的例程，比如那些來自Windows API的例程(例如：LoadLibraryA)。為了實現此默認行為，可執行文件應具有操作系統可以解釋的特定結構。由于shellcode是代碼的一個基本版本(它沒有預期的結構)，操作系統加載程序無法幫助它解析這些導入的函數，更嚴重的是，操作系統加載程序將無法“執行”shellcode文件。為了解析這個問題，shellcode 通常會執行“動態導入解析”。

執行“動態導入解析”的最常見技術之一是對每個可用的導出函數進行哈希，并將其與所需導入的哈希進行比較。由于shellcode開發者不能總是預測一個特定的DLL(例如:ws3_32.dll for Windows Sockets)及其導出是否已經加載，觀察shellcode加載DLL并不罕見，首先調用LoadLibraryA函數(或它的一個替代方法)。在調用其他dll的導出之前依賴于LoadLibraryA(或替代)是一種穩定的方法，因為這些庫加載函數是kernel32.dll的一部分，是少數幾個可以加載到每個進程中的 DLL 之一。

為了證實研究人員的上述理論，研究人員可以搜索所有調用指令，如下圖所示（例如：在搜索菜單下使用 IDA 的文本等選項）。除了第一次調用 Main 函數外，所有實例都引用 ebp 寄存器。這一觀察結果與研究人員將在下一節中觀察到的眾所周知的常量一起，支持了研究人員的理論，即存儲在 ebp 中的地址持有一個指向執行動態導入解析的函數的指針。

shellcode中的所有調用指令

對ebp寄存器的大量調用表明它確實持有一個指向導入解析函數的指針，我們現在知道該函數位于對Main的第一次調用之后。

導入解析方案分析

到目前為止，我們注意到在最初調用Main之后的指令起到了至關重要的作用，因為我們希望它成為導入解析例程。在分析shellcode的邏輯之前，讓我們先分析這個解析例程，因為它將簡化對其余調用的理解。

從導入哈希到函數

直接位于Main初始調用之后的代碼是導入解析開始的地方，要解析這些導入，例程首先定位加載到內存中的模塊列表，因為這些模塊包含它們可用的導出函數。

為了找到這些模塊，一種常用的shellcode技術便是與Process Environment Block(簡稱PEB)進行交互。

在計算過程中，進程環境塊（縮寫為 PEB）是 Windows NT 操作系統家族中的一種數據結構。它是操作系統內部使用的不透明數據結構，其大部分字段不供操作系統以外的任何其他使用。PEB包含應用于整個進程的數據結構，包括全局上下文、啟動參數、程序映像加載程序的數據結構、程序映像基地址，以及用于為整個進程的數據結構提供互斥的同步對象。

如下圖所示，為了訪問PEB, shellcode訪問線程環境塊(TEB)，它可以通過寄存器(⑦)立即訪問。TEB結構本身包含指向PEB(⑦)的指針。在PEB中, shellcode可以定位PEB_LDR_DATA結構(⑧)，它反過來包含對多個雙鏈接模塊列表的引用。正如在(⑨)中所觀察到的，Metasploit shellcode利用這些雙鏈列表(InMemoryOrderModuleList)中的一個來隨后遍歷包含已加載模塊信息的LDR_DATA_TABLE_ENTRY結構。

一旦識別出第一個模塊，shellcode 在⑩ 處檢索模塊的名稱（BaseDllName.Buffer）和在? 處的緩沖區的最大長度（BaseDllName.MaximumLength），這是必需的，因為緩沖區不能保證以 NULL 結尾。

初始模塊檢索的反匯編

值得強調的一點是，與通常的指針（TEB.ProcessEnvironmentBlock、PEB.Ldr 等）相反，雙鏈表指向下一項的列表條目。這意味著列表中的指針將指向非零偏移量，而不是指向結構的起始位置。因此，雖然在下圖中 LDR_DATA_TABLE_ENTRY 在偏移量為 0x2C 處具有 BaseDllName 屬性，但從列表條目的角度來看，偏移量為 0x24 (0x2C-0x08)。這可以在上圖中觀察到，其中必須減去 8 的偏移量才能訪問 ⑩ 和 ? 處的兩個 BaseDllName 屬性。

從TEB到BaseDllName

恢復了DLL名稱的緩沖區和最大長度后，shellcode繼續生成一個哈希。為此，shellcode對最大名稱長度內的每個ASCII字符執行一組如下操作：

如果字符是小寫的，它會被修改為大寫。該操作是根據字符的ASCII表示來執行的，這意味著如果值是0x61或更高(a或更高)，就會減去0x20以進入大寫范圍；

生成的哈希(最初為0)向右旋轉13位(ROR) (0x0D)；

大寫字符被添加到現有哈希中；

描述KERNEL32.DLL的第一個字符(K)的哈希循環的模式

在固定的注冊表大小(在edi的情況下是32位)上重復旋轉和添加，字符最終將開始重疊。這些重復和重疊的組合使操作不可逆，因此產生給定名稱的32位哈希/校驗和。

一個有趣的發現是，雖然LDR_DATA_TABLE_ENTRY中的BaseDllName是unicode編碼的(每個字符2個字節)，但代碼通過使用 lodsb（見?）將其視為 ASCII 編碼（每個字符 1 個字節）。

模塊名稱哈希例程的反匯編

哈希生成算法可以在Python中實現，如下面的代碼片段所示。雖然我們前面提到過，根據 Microsoft 文檔，BaseDllName 的緩沖區不需要以 NULL 終止，但大量測試表明，NULL 終止總是如此，并且通常可以假設。這個假設是使 MaximumLength 屬性成為有效邊界的原因，類似于 Length 屬性。因此，以下代碼片段期望傳遞給 get_hash 的數據是一個由以null結尾的Unicode字符串生成的Python 字節對象。

上述函數可用于計算 KERNEL32.DLL 的哈希值，如下所示。

生成 DLL 名稱的哈希后，shellcode 繼續識別所有導出的函數。為此，shellcode 首先檢索 LDR_DATA_TABLE_ENTRY 的 DllBase 屬性（?），該屬性指向 DLL 的內存地址。此時，IMAGE_EXPORT_DIRECTORY 結構通過遍歷可移植可執行文件的結構（? 和 ?）并將相對偏移量添加到 DLL 的內存中基地址來識別。最后一個結構包含導出函數名稱的數量（?）以及指向這些名稱的指針表（?）。

導出檢索的反匯編

上述操作的架構如下，其中虛線表示從相對偏移量計算出的地址，該偏移量增加了 DLL 的內存基地址。

從LDR_DATA_TABLE_ENTRY到IMAGE_EXPORT_DIRECTORY

一旦確定了導出名稱的數量及其指針，shellcode 就會按降序枚舉該表。具體就是，名稱的數量用作?處的遞減計數器。對于每個導出函數的名稱并且沒有匹配，shellcode 執行一個哈希例程（?上的hash_export_name），與研究人員之前觀察到的類似，唯一的區別是保留了字符大小寫（hash_export_character）。

最后的哈希是通過將最近計算的函數哈希(ExportHash)添加到?處之前獲得的模塊哈希(DllHash)中獲得的。這是在尋求哈希和?之間的區別,除非他們匹配，否則操作重新開始下一個函數。

導出名稱哈希的反匯編

如果導出的函數都不匹配，例程將在InMemoryOrderLinks雙鏈表中檢索下一個模塊，并再次執行上述操作，直到找到匹配項。

反匯編到下一個模塊的循環過程

上面的遍歷雙鏈表的架構如下圖所示：

遍歷InMemoryOrderModuleList

如果找到匹配，shellcode將繼續調用導出的函數。從前面確認IMAGE_EXPORT_DIRECTORY檢索其地址,代碼將首先需要映射函數的名字的順序(?),順序導出數量。一旦順序從AddressOfNameOrdinals表中恢復過來,地址可以通過使用序數AddressOfFunctions表中的索引(?)。

導入“調用”的反匯編

最后，一旦導出的地址被恢復，shellcode通過確保返回地址首先在堆棧上（刪除它正在在?搜索的哈希）來模擬調用行為，其次是所有參數根據默認的Win32 API __stdcall調用協定(?)。然后代碼在 ? 處執行 jmp 操作，將執行轉移到動態解析的導入，在返回時，將從初始調用 ebp 操作發生的位置恢復。

總的來說，可以將動態導入解析架構為嵌套循環。主循環按照內存中的順序遍歷模塊(下圖中的藍色)，而對于每個模塊，第二個循環遍歷導出函數，在所需的導入和可用的導出之間尋找匹配的哈希(下圖中的紅色)。

導入解析流

【網絡安全學習資料獲取方式】

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的【网络安全】Metasploit 生成的 Shellcode 的导入函数解析以及执行流程分析（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。