Unit 42研究人員檢查了幾個包含 組件的惡意軟件樣本，并發現通過分析進程中關鍵執行工件可以捕獲這些樣本。
(簡稱CS)是一款團隊作戰滲透測試神器,分為客戶端及服務端，一個服務端可以對應多個客戶端，一個客戶端可以連接多個服務端。它不僅在紅隊中流行，而且也被用于惡意目的。
盡管該工具包只出售給受信任的組織進行安全測試，但由于源代碼泄露，它的各種組件不可避免地進入了攻擊者的武器庫，從勒索軟件組織到國家支持的攻擊組織。濫用 的惡意軟件甚至在2020年臭名昭著的供應鏈攻擊事件發揮了作用。
為什么是 ？
之所以被如此廣泛的利用，主要是因為 集成了端口轉發、掃描多模式端口、 exe程序生成、 dll動態鏈接庫生成、java程序生成、宏代碼生成，包括站點復制獲取瀏覽器的相關信息等。由于它的設計是從底層開始的，所以攻擊者會定期使用它引入新的規避技術。
的主要優點之一是，一旦初始加載程序被執行，它主要在內存中運行。當有效負載是靜態防護的、僅存在于內存中并且拒絕執行時，這種情況會給檢測帶來問題。這對許多安全軟件產品來說都是一個挑戰，因為掃描內存絕非易事。
在許多情況下， 是在目標網絡中獲得初始足跡的自然選擇。攻擊者可以使用具有大量部署和混淆選項的構建器，根據可定制的模板創建最終有效負載。
該有效負載通常以加密或編碼的形式嵌入到文件加載程序中。當受害者執行文件加載程序時，它將有效負載解密/解碼到內存中并運行它。由于有效負載以其原始形式存在于內存中，因此由于某些特定功能，可以很容易地檢測到它。
作為惡意軟件研究人員，我們經常看到潛在的有趣的惡意樣本，結果只是 的加載程序。通常也不清楚加載程序是由紅隊創建的還是真正的攻擊者創建的，因此使歸因更具挑戰性。
接下來我們將深入研究三種不同的 加載程序，它們是由我們設計的一個新的基于管理程序的沙箱檢測到的，該沙箱允許我們分析內存中的工件。每個示例加載不同的植入類型，即SMB、HTTPS和信標。我們將這些 裝載程序稱為, 和。我們還將討論可以用來檢測這些有效負載的一些方法。
SMB信標
以以下樣本為例
: a292
這個64位可執行文件使用各種已知的技巧來繞過沙盒，并使分析過程更加耗時。
為了繞過只掛鉤高級用戶模式函數的沙盒，它只調用內置API函數。為了使分析人員的工作更加困難，它通過哈希而不是使用純文本字符串來動態解析函數。惡意軟件包含調用以下函數的代碼：
該惡意軟件創建了兩個單獨的函數哈希/地址對表。一個表包含所有內置函數的一對，而第二個表只包含Nt*個函數對。
對于所使用的Rtl*函數，它循環遍歷第一個表并搜索函數哈希以獲得函數地址。對于使用的Nt*函數，它遍歷第二個表并同時增加一個計數器變量。
當找到哈希時，它將獲取計數器值，即相應內置函數的系統調用號，并輸入自定義系統調用存根。這有效地繞過了許多沙盒，即使掛接了較低級別的內置函數而不是高級函數。
加載程序的整體功能相對簡單，并使用映射注入來運行負載。它生成工具sethc.exe的子進程，創建一個新部分，并將解密的 信標加載程序映射到其中。 加載程序的最終執行是通過調用來加載SMB信標的。
內存中的規避功能
通過新的基于管理程序的沙盒，我們能夠在內存中檢測到解密的 SMB信標。這個信標加載程序甚至使用了一些內存中的規避功能，創建了一種奇怪的嵌合體文件。雖然它實際上是一個DLL，但“MZ”神奇的PE字節和隨后的DOS標頭被一個小的加載程序覆蓋，如下圖所示。
解密的 SMB信標
加載程序跳轉到導出的函數，該函數在內存中準備SMB信標模塊。為此，它首先加載 pla.dll庫，并清空代碼段(.text)中的一大塊字節。然后，它將信標文件寫入該blob并修復導入地址表，從而創建一個可執行內存模塊。
在分析該文件的過程中，我們可以找出所使用的一些內存內規避功能，如下表所示。
內存內規避功能
總之，信標加載程序和信標本身是同一個文件。PE標頭的部分用于跳轉到導出函數的，該函數反過來在 DLL中創建自己的模塊。最后，跳轉到信標模塊的入口點，在內存中執行它。
如上所述，我們沒有辦法成功檢測我們的示例的信標，除非我們可以在執行過程中查看內存內部。
我們將研究的第二個加載程序是一個模仿合法庫的64位DLL。
:5e0
這個示例試圖在一些方面看起來像文件mscms.dll，通過使用以下類似的功能：
相同的文件描述；
一個具有許多相同函數名的導出表；
幾乎相同的資源；
一個非常相似的互斥鎖；
這些功能也顯示在下圖中，其中惡意軟件文件與有效的mscml.dll進行了對比。
(左)和mscml.dll(右)的文件描述、導出表和資源的比較
不僅嘗試靜態地模擬合法的庫，而且在運行時也如此。
的所有導出函數內部調用相同的主要惡意軟件例程。當調用其中一個時，首先運行DLL入口點。在入口點，惡意軟件加載原始的mscms.dll，并解析它所偽造的所有函數。
這些原始函數的地址在執行偽方法后被存儲和調用。因此，每當調用的導出函數時，它都會運行主惡意軟件例程，然后調用mscms.dll中的原始函數。
主要的惡意軟件例程相對簡單。它首先創建了一個名為SM0:220:304:的互斥體，看起來與mscms.dll創建的原始互斥體非常相似。
信標加載程序被解密到內存緩沖區中，并在一個已知的技巧的幫助下執行。加載程序沒有直接調用信標加載程序，而是使用 API函數來運行它。
該函數包含三個參數，其中一個是回調函數。惡意軟件可能濫用此參數，通過回調函數間接調用地址，從而隱藏執行流程。
最后一個 示例是DLL側加載鏈的一部分，其中使用了一種安全軟件的自定義安裝程序。DLL側加載是一種劫持合法應用程序以運行獨立的惡意DLL的技術。
: 8129
這個32位的 DLL是由攻擊者自定義創建的 VPN安裝包的一部分已經加載dll找不到輸入點，該安裝包以ws.exe (: c786)的形式提交給。
ws.exe文件不是惡意的或被破壞的。由于該文件是簽名的，攻擊者利用它來逃避反病毒檢測。
安裝程序是一個自解壓縮RAR存檔，包含以下文件：
ws.exe文件內容
自解壓腳本命令如下：
自解壓腳本命令列表
當安裝程序運行時，所有文件都會被無聲地放到本地%%文件夾中，兩個可執行文件都會啟動。當 VPN安裝程序執行時，工具側加載.dll 惡意軟件。惡意軟件之所以這樣做，是因為它從庫的合法副本中導入了以下函數，如下圖所示：
導入.exe的地址表
此威脅還試圖通過將%%文件夾路徑添加到防御器中的排除列表中。
在啟動GUP.exe時，惡意的.dll文件被加載到進程空間中，因為它靜態地導入上圖所示的函數。雖然所有四個函數都在運行，但只有包含在編譯庫的新版本時注入的惡意例程。因此，我們不是在處理合法DLL的打了補丁的版本。這是一種更干凈的解決方案，不會像在其他惡意軟件中經常看到的那樣，在插入惡意程序后破壞代碼。
這個函數通常只包含一個子例程()，并且沒有返回值(如其在上的源代碼所示)。修改后的函數如下圖所示。
修改了.dll的導出函數
函數通過XOR和密鑰0xA解密，如下圖所示。
加載程序函數()
這個函數通過間接運行 階段，而不是直接跳轉到它。這個 API函數有三個參數，最后一個參數是一個被濫用的回調函數。
是從借來的，是反向的HTTP外殼負載，它使用以下API函數：
連接到以下URL，其中包含泰國一所大學的IP地址
檢測問題
在本文發布時， 信標的有效負載已不再可用。如果API調用的執行報告中沒有有效負載或任何可操作的信息，沙盒通常很難確定樣本是否惡意。這個示例本身沒有任何可以被歸類為惡意的功能。
通過內存分析尋找
在這三個例子中都存在一些常見的檢測挑戰。這些示例不能在正常的沙盒環境中執行。但是正如我們所討論的，如果我們在執行期間查看內存內部，就可以使用大量的信息進行檢測，比如函數指針、已解碼的加載程序階段和其他工件。
為了準確地檢測，研究人員發現解決高度規避惡意軟件的一個關鍵功能是，除了使用系統API更好地理解所發生的事情外，還需要在執行樣本時查看內存。
研究人員發現，在惡意軟件檢測中，查看執行關鍵點的內存增量，以提取有意義的信息和工件是很有用的。當我們的系統處理大量的樣本時，要實現大規模的工作有很多挑戰。接下來，我們將詳細介紹目前從內存中收集的一些主要類型的數據，以幫助檢測。盡管我們在本文介紹的是通過內存方法，但我們絕不是說檢測和記錄API調用對檢測沒有用。
自動有效負載提取
如上所述，惡意軟件開發者混淆其有效負載越來越普遍。雖然使用可執行打包器可以壓縮和模糊文件來實現這一點并不新鮮已經加載dll找不到輸入點，但當它與逃避策略結合使用時就會出現問題，因為沒有對準確檢測有用的靜態或動態數據。
編碼、壓縮、加密或下載額外的執行階段的策略有無限的組合。為這些有效負載制作簽名的能力顯然是分析師能夠從 等框架中捕獲大量不同惡意軟件組件的重要方式。如果我們能在內存中捕捉到它們，那么惡意軟件最終決定不執行也無所謂。
下面簡化圖顯示了我們可能在兩個階段中看到的示例，這些階段在初始可執行文件中從未出現過。
可以在打包的惡意軟件可執行文件中看到的典型階段
在圖的左側，我們看到了一個階段的示例。盡管“”一詞最初是為利用漏洞在目標系統上彈出外殼而手工制作的程序集而創造的，但該詞已演變為包含任何為惡意目的編寫的自定義程序集。一些惡意軟件階段是沒有可識別的可執行結構的自定義程序集。惡意軟件開發者采用這種方法的常見模式是將所有函數指針動態解析到一個表中，以便于訪問。
在圖的右側，我們看到后期是一個格式良好的可執行文件的示例。一些惡意軟件階段或有效負載是格式良好的可執行文件。這些可以由OS通過系統API加載，或者惡意軟件開發者可能會使用他們自己的PE加載程序，如果他們試圖隱蔽地避免調用任何API來為他們加載。
函數指針數據
我們可以從內存中提取的另一組用于檢測的豐富數據是動態解析函數指針，如下圖所示。惡意軟件的開發者很久以前就知道，如果他們顯式地調用他們計劃在導入表中使用的所有函數，它就會被用來對付他們。現在的標準做法是隱藏惡意軟件或其任何階段將使用的功能。
哈希是另一種常見的隱蔽策略，用于解析函數的指針而不需要它們的字符串。
可能在內存段中看到的動態解析指針示例
在 中，我們已經開始有選擇地搜索和使用在我們的檢測邏輯中解析了哪些函數指針的信息。
操作系統結構修改
研究人員從分析內存中發現的另一個有用的檢測數據來源是尋找對記賬結構的任何更改（惡意軟件開發者喜歡混淆這些！）。這些結構對于OS維護進程的狀態非常重要，例如加載了哪些庫、加載了可執行映像的位置以及OS稍后可能需要了解的進程的其他各種特征。考慮到這些字段中的許多都不應該被修改，跟蹤惡意軟件樣本何時以及如何操作它們通常很有用。
下圖顯示了示例如何從LDR模塊列表中卸載它加載的模塊。取消查找模塊意味著不再存在該模塊存在的記錄。例如，這樣做之后，中的任務管理器將不再列出它。
此圖僅是研究人員所看到的許多不同的OS結構修改中的一種，但它表明有許多不同類型的OS結構更改對惡意軟件檢測問題有用。
如何將模塊從LDR模塊列表中解關聯的示例
頁面權限
最后，檢測數據的另一個有用來源是對頁面權限所做的所有更改的完整日志。打包惡意軟件的開發者通常需要更改內存權限，以便正確加載和執行進一步的階段。了解哪些內存頁的權限發生了更改，通常可以提供有關代碼加載和執行位置的重要見解，這對檢測非常有用。
總結
盡管 已經存在多年，但檢測它對許多安全軟件提供商來說仍然是一個挑戰。這是因為該工具主要在內存中工作，不太接觸磁盤。
本文介紹了三種新的加載程序，并展示了如何使用各種技術檢測它們，這些檢測技術在新的基于管理程序的沙盒中可用。