標題：深入分析BundleBot新型惡意軟件

Check Point Research (CPR)對被稱為BundleBot的新型惡意軟件進行了深入分析發現，BundleBot濫用dotnet bundle（單文件），這是一種自包含的格式，可以很好繞過靜態檢測。它會偽裝成常規實用程序，人工智能工具和遊戲。通常通過Facebook廣告和受攻擊帳戶傳播。

詳細分析在過去的幾個月裡，BYOS公司一直在監控一個新的未知的竊取程序，研究人員稱之為BundleBot，他們發現其傳播並濫用dotnet bundle(單文件)，自包含格式。從.net core 3.0+到dotnet8+，這種形式的dotnet編譯已經支持了大約四年，並且已經有一些已知的惡意軟件家族濫用它，例如Ducktail。

使用這種特定dotnet格式的BundleBot主要是濫用Facebook廣告和受攻擊帳戶，利用dotnet bundle(單文件)、自包含格式、多階段攻擊和自定義混淆。

dotnet bundle（單文件）、自包含的格式通常會導致整個dotnet運行時出現非常大的二進製文件。此外，分析和調試這樣的文件可能會導致一些問題，特別是如果這樣的文件受到一些混淆的影響。

本文主要深入分析BundleBot的攻擊方式，重點對dotnet bundle（單文件）、自包含格式進行分析。

發現過程自.NET Core 3.0（2019）發布以來，可以將.NET程序集部署為單個二進製文件。這些文件是不包含傳統.NET元數據標頭的可執行文件，並通過特定於平台的應用程序主機引導程序在底層操作系統上本地運行。

dotnet bundle（單文件），自包含格式是一種編譯形式，可以生成一個不需要在操作系統上預裝特定Dotnet運行時版本的可執行二進製文件。可執行文件實際上是一個本地託管二進製文件，在其覆蓋中包含整個dotnet運行時、程序集和其他依賴項，因此它很大，約幾十MB。本機託管二進製文件負責從覆蓋中提取（在執行時）所有內容，加載dotnet運行時和程序集，準備所有內容，並將執行轉移到.NET模塊的入口點。

當涉及到從覆蓋中提取程序集時（在執行時），我們可以根據用於編譯特定應用程序的目標dotnet版本來處理不同的例程。 dotnet版本之間的區別在於，在dotnet5+（.NET Core 3.0+）之前，默認情況下，所有程序集都被提取到磁盤（臨時目錄）並加載到進程內存中。

另一方面，在dotnet5+版本中，覆蓋層中的所有程序集都被提取並直接加載到進程內存中（沒有文件被釋放在磁盤上，則只有本地庫）。在dotnet5+中，可以在編譯期間指定提取，但默認設置是直接被提取到內存中的。

儘管研究人員仍在處理與dotnet相關的應用程序，但上述對這種特定文件格式的描述清楚地表明，需要使用不同的工具集和技術來正確分析它。

研究人員檢測到BundleBot濫用dotnet bundle(單文件)，將其作為攻擊的最後階段，它與已經被公佈的幾個惡意活動有關，很可能是由同一個組織發起的。

攻擊載體在發現的示例中，最初的攻擊載體都是通過Facebook廣告或被攻擊的賬戶傳播的，攻擊程序偽裝成常規程序、人工智能工具和遊戲。例如，Google AI、PDF Reader、Canva、Chaturbate、Smart Miner、超級馬里奧3D世界。由於BundleBot的功能之一是竊取Facebook賬戶信息，這些被盜的信息進一步用於通過新受攻擊的賬戶傳播惡意軟件。

儘管如此，我們不能完全排除其他可能的傳播方式，因為我們無法通過相關的跟踪信息獲得所有檢測到的樣本源鏈接。

一旦受害者被誘騙從釣魚網站下載假程序實用程序，第一階段下載程序以“RAR”形式發送。這些下載階段通常是在Dropbox或Google Drive等託管服務上。

下載的“RAR”文件包含一個獨立的dotnet bundle(單文件)格式的第一階段下載程序。在執行第一階段後，第二階段以密碼保護的“ZIP”文件的形式下載，通常來自Google Drive等託管服務。第二階段的密碼在下載程序中進行硬編碼，通常是以編碼的形式。

被提取和執行的受密碼保護的“ZIP”文件的主要部分是BundleBot，它是dotnet bundle(單文件)、自包含格式和自定義混淆的組合。

下面是一個與虛假的實用程序“Google AI”有關的詳細攻擊鏈示例，它偽裝成使用Google AI Bard的營銷工具：

1.來自受攻擊賬戶的Facebook廣告或Facebook帖子的釣魚網站https://marketingaigg[.]com/。

受攻擊賬戶的Facebook上的釣魚網站

2.釣魚網站https://marketingaigg[.]com/偽裝成營銷工具，使用Google Bard AI引導下載頁面https://googlebardai[.]wiki/Googleai。

導致下載階段的釣魚網站

3.URL https://googlebardai[.]wiki/Googleai正在從Dropbox託管服務。

下載“RAR”文件Google_AI.rar (SHA-256:

“dfa9f39ab29405475e3d110d9ac0cc21885760d07716595104db5e9e055c92a6”)；4.Google_AI.rar包含GoogleAI.exe (SHA-256: ' 5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59 ')， dotnet bundle(單個文件)和自包含的應用程序；

5.GoogleAI.exe包含用作下載程序的GoogleAI.dll dotnet模塊(從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t, password=alex14206985alexjyjyjj下載受密碼保護的“ZIP”文件adsnew - 1.0.0.0 . ZIP)；

6.解壓後的ADSNEW-1.0.0.3.zip (SHA-256: ' 303c6d0cea77ae6343dda76ceabaefdd03cc80bd6e041d2b931e7f6d59ca3ef6 ')包含RiotClientServices.exe, dotnet bundle (單文件)以及自包含應用程序。

7.RiotClientServices.exe作為最後階段服務和執行，包含兩個惡意dotnet模塊RiotClientServices.dll，BundleBot,和libarysharing .dll ，他們是C2數據序列化程序。

自包含Dotnet Bundle 的分析當我們需要分析一個自包含的dotnet bundle(單文件)二進製文件時，我們會遇到幾個問題。

第一個問題是，我們需要以某種方式提取所有二進製文件，這些二進製文件是上述包bundle覆蓋的一部分。這種提取將幫助我們靜態地調查每個文件，就像我們在處理普通的dotnet程序集時所做的那樣。儘管目前該做法還不太成熟，但是已經有一些解決方案能夠充分分析dotnet bundle格式了，從而幫助我們進行提取。我們基於GUI的工具和庫，以編程的方式實現這一點。值得注意的是，目前dnSpy/dnSpyEx不支持提取dotnet bundle文件。

可以幫助提取的最可靠的基於GUI的工具包括：

ILSpy：開源.NET程序集瀏覽器和反編譯器；

dotPeek：免費的.NET反編譯器和程序集瀏覽器；

ILSpy中dotnet bundle的提取：

ILSpy中的dotnet bundle提取

dotPeek中dotnet bundle的提取：

dotPeek中dotnet bundle的提取

如上所述，dotnet bundle文件的提取也可以通過編程的方式完成。當我們處理較大的文件集時，這種方法非常方便。

為此，最合適的解決方案是使用AsmResolver。 AsmResolver是一個便攜式可執行(PE)檢查庫，能夠讀取，修改和寫入可執行文件，這包括.NET模塊以及本機映像。該庫仍然允許用戶訪問低級結構。更重要的是，AsmResolver理解bundle文件格式，因此我們可以使用它來自動提取。

下面是使用AsmResolver和PowerShell提取bundle文件內容的代碼示例。

現在，當我們成功地提取了dotnet bundle文件的全部內容時，就可以使用通常用來檢查普通dotnet程序集的任何工具，比如dnSpyEx。這將允許我們靜態地調查每個.net程序集。

dnSpyEx中dotnet程序集的靜態分析

由於dotnet程序集，特別是惡意程序集，通常非常複雜，並且經常受到一些混淆或保護的影響，大多數研究人員傾向於將靜態和動態分析方法結合起來。關於動態方法，我們使用一個自包含的dotnet bundle(單文件)二進制調試來接近第二個問題。

在託管調試器(如dnSpyEx)中調試dotnet程序集是常用的一種方法。 dnSpyEx中的調試不完全支持自包含的dotnet bundle二進製文件，如果試圖調試此類文件，可能會導致如下所示的類似異常。

調試自包含dotnet bundle時拋出的DnSpyEx異常

幸運的是，最近發布的dnSpyEx版本(v6.4.0)改進了對這類文件的調試，因此我們應該不會再遇到這種異常，調試可以順利進行。

儘管我們可以在最新版本的dnSpyEx (v6.4.0)中調試自包含的dotnet bundle文件，但它無法解決作為dotnet bundle混淆的dotnet程序集的處理問題。

當dotnet二進製文件被編譯為一個自包含的包時，這僅僅意味著整個依賴項(尤其是dotnet運行時)是生成的應用程序的一部分，並且這樣的應用程序通過其配置文件被配置為使用它們。這些配置文件是在提取包和去混淆每個受保護程序集之後影響調試的主要問題。

為了解決這個問題，我們實際上可以將自包含的dotnet bundle文件轉換為非自包含的、非單文件的.NET程序。通過這種方式轉換的程序將被誘騙使用dotnet運行時，這是操作系統的一部分，所以我們必須確保安裝了它。

轉換步驟如下：

1.如上所示，提取dotnet bundle文件的內容；

2.查找要在操作系統中安裝的dotnet運行時版本並進行安裝。為了快速查找我們的.NET應用程序所依賴和需要安裝的具體dotnet運行時的版本信息，我們可以定位並檢查配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*，它們應該在之前提取的內容中。

在下面的示例中，我們可以清楚地看到，需要安裝.NET Runtime 5.0.17, x86。

配置文件

需要安裝的dotnet運行時版本(Microsoft)

3.修改配置文件*[appname].runtimeconfig.json*和*[appname].deps.json*的內容。通過修改這些文件，我們將應用程序轉換為非自包含的、非單文件的.NET程序，並強制它使用已安裝的dotnet運行時版本。

修改*[appname]. runtimeeconfig .json*，將' includedFrameworks '字符串改為' frameworks '。

修改“[appname].runtimeconfig.json”

通過刪除來自“libraries”的“runtimepack”條目來修改*[appname].deps.json*。

修改“[appname]. depth .json”

4.運行和調試。自包含的dotnet bundle應用程序可以依賴於本機庫，這些庫可能是bundle的一部分，所以我們已經從內容中提取了它們，或者它們可以與bundle可執行文件一起單獨提供。通過檢查配置文件或運行配置文件，我們可以快速發現應用程序是否有這樣的依賴關係（在*[appname].deps.json*中定義），如下所示。

運行提取的bundle應用程序時出現依賴關係相關錯誤要解決這個問題，只需將bundle應用程序旁邊的所有依賴項複製到先前提取內容的位置。現在，調試應該像使用安裝在操作系統中的dotnet運行時的普通.NET應用程序一樣運行了。

在dnSpyEx中調試轉換的非自包含、非單文件的.NET應用程序

如果我們不處理作為dotnet bundle一部分的混淆的dotnet程序集，則不需要像上面那樣，因為使用最新版本的dnSpyEx (v6.4.0)可以直接調試它們。儘管如此，當我們處理混淆的程序集並傾向於以去混淆的形式調試它們時，仍然需要上面的操作方法。

如上所述，我們介紹了一種將自包含的dotnet bundle文件轉換為普通的dotnet程序集的通用方法，這取決於目標操作系統上預安裝的適當版本的dotnet運行時。這種方法應該適用於不同的操作系統平台（Windows、Linux、macOS）。

了解瞭如何提取自包含的dotnet bundle文件的內容以及如何對其進行調試後，我們就可以繼續進行分析了。

技術分析自帶的dotnet bundle格式，可加強分析和靜態檢測；

受簡單但有效的自定義模糊處理的影響；

濫用密碼保護的文件來進行最後階段的傳播；

最後階段是一個新的竊取程序BundleBot；

用於C2通信的自定義homebrew分組數據序列化。

下載程序技術分析下載階段的分析，請使用GoogleAI.exe示例SHA-256：“5ac212ca8a5516e376e0af83788e2197690ba73c6b6bda3b646a22f0af94bf59”。

此示例是一個32位自包含的dotnet bundle應用程序（.NET Core 3.0.3），其最初是RAR文件的一部分。提取該捆綁包後，主模塊GoogleAI.dll是一個下載程序，受簡單的自定義混淆影響，只有字符串和名稱(無意義的泰語文本)。

受簡單自定義混淆影響的下載程序

下載程序的PDB路徑：D:\BOT\RAT\RAT 4.0版\HashCode\BOT ADS Server 4\ClientDowload FB\ClientDowload\obj\Debug\netcoreapp3.0\win-x86\GoogleAI.PDB。

去混淆之後，主要功能駐留在名為ProcessMain的函數中。

下載程序的主要功能

其主要功能可以概括如下：

1.單例檢查；

2.下載使用隨機名稱和“.rar”擴展名保存的受密碼保護的ZIP文件；

3.從https://drive.google[.]com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58Oexport=downloadconfirm=t下載文件；

4.將下載的文件屬性設置為“隱藏”；

5.將下載文件的內容提取到新創建的文件夾C:\Users\User\Documents\{random}，密碼：alex14206985alexjyjyjj；

6.將新創建的文件夾和其中所有“.exe”文件的屬性設置為“隱藏”；

7.刪除下載的文件；

BundleBot以自包含的dotnet bundle文件的形式出現，是下載的受密碼保護文件的主要部分，並由下載程序執行。值得注意的是，所有分析的下載程序都包含相同的硬編碼密碼alex14206985alexjyjyjj(明文或base64編碼)來開始下一階段地提取。

BundleBot技術分析對BundleBot階段的分析，使用了示例RiotClientServices.exe，SHA-256：“6552a05a4ea87494e80d0654f872f980cf19e46b4a99d5084f9ec3938a20db91”。

這個示例是一個32位的自包含dotnet bundle應用程序(.NET 5.0.17)，最初是受密碼保護的ZIP文件的一部分。在提取這個包之後，它的主要惡意組件是主模塊RiotClientServices.dll和庫librarysharing.dll。

程序集RiotClientServices.dll是一個新的自定義的竊取程序，它使用庫libarysharing .dll來處理和序列化作為惡意通信的一部分發送到C2的數據包數據。

這些二進製文件受到類似的自定義混淆的影響，這些混淆主要集中在名稱混淆和用大量垃圾代碼填充這些dotnet模塊。這樣的混淆將導致大量的方法和類，這將使分析變得更加困難，並且需要創建自定義的去混淆器來簡化分析過程。

在去混淆之前，RiotClientServices.dll的大小約為11MB，包含26742個方法和902個類。在libarysharing .dll示例中，混淆導致二進制大小約為10MB，包含32462個方法和9473個類。

“librarysharing .dll”的模糊代碼：類“Serialize”

正因為如此，我們快速設計了一個簡單的去混淆器，它適用於所有受類似自定義混淆影響的二進製文件。這個去混淆器使用AsmResolver和PowerShell來清理垃圾代碼，並且仍然進行調試。

去混淆後，我們可以將方法和類的大小、數量減少到:

1.RiotClientServices.dll大小≈124KB, 158個方法，35個類；

2.LirarySharing.dll大小≈30KB, 220個方法，28個類