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