深入分析BundleBot新型惡意軟體

今天小編分享的互聯網經驗：深入分析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_B1VuS6dbQeDAAqLuPbfAV58O&export=download&confirm=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:BOTRATRAT 4.0 版 HashCodeBOT ADS Server 4ClientDowload FBClientDowloadobjDebugnetcoreapp3.0win-x86GoogleAI.PDB。

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

下載程式的主要功能

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

1. 單例檢查；

2. 下載使用随機名稱和 ".rar" 擴展名保存的受密碼保護的 ZIP 檔案；

3. 從 https://drive.google [ . ] com/uc?id=1-mC5c7o_B1VuS6dbQeDAAqLuPbfAV58O&export=download&confirm=t 下載檔案；

4. 将下載的檔案屬性設定為 " 隐藏 "；

5. 将下載檔案的内容提取到新創建的檔案夾 C:UsersUserDocuments{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 個類

"librarysharing .dll" 的去混淆代碼，類 "Serialize"

可以使用 de4dot 工具進一步清除名稱 ( 方法、類等 ) 的混淆。盡管如此，我們也不要忘記提供所有二進制檔案，為了保留調試，主模塊正在引用和使用庫。

"libarysharing .dll" 混淆前後比對

去混淆後，BundleBot 的主邏輯可以在模塊 RiotClientServices.dll 中看到：

"RiotClientServices.dll" 模塊中 BundleBot 的主邏輯

1.Sleep 補丁檢測（反沙盒）；

2. 通過系統資料庫路徑 HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun, value ApplicationName 安裝 / 解除安裝持久性軟體；

3. 信息竊取；

4.C2 BOT 通信 ( TCP 套接字與 C2 IP 51.79.180.158，端口 5505 通信 )

被盜和泄露的數據：

1.Telegram 數據；

2.Discord token；

3. 計算機信息。  HWID ( 根據作業系統驅動器的 CPU 計數、用户名、機器名、作業系統版本和 TotalSize 計算的 MD5 的前 10 個字節 ) ，Windows 版本，用户名，Windows 系統所在的國家，IP 信息 ( IP 地址，國家，地區，城市，時區，ISP ) - 通過服務 http://icanhazip [ . ] com 和 http://ip-api [ . ] com/json/ 檢索；

4.Web 浏覽器數據（Chrome、Edge、Opera、Brave、Coccoc、Firefox）：配置檔案名稱、解密密鑰、憑據 cookie、密碼、書籤、擴展名、信用卡；

5.Facebook 帳户：  uid，名稱，cookie, access_token，頁面，廣告帳户信息，業務信息，浏覽器名稱，浏覽器配置檔案名稱；

6. 捕獲螢幕截圖；

在 libarysharing .dll 庫的幫助下，所有被盜數據和 C2 通信都被處理、序列化和壓縮。這個庫定義了 bot 通信的主要功能如下 :

1.Bot 标識：啓動 TCP 套接字，将被盜數據發送到 C2（序列化，GZip 壓縮）；

2.Bot 更新 ( 使用新版本完成 Bot 的重新安裝 ) ；

3.Bot 關閉 ( 僅退出進程 ) ；

4.Bot Kill ( 删除持久性并退出進程 ) ；

5.Bot 重新更新标識 ( 竊取數據并發送給 C2 )

6.Bot 獲取浏覽器數據 ( 收集 web 浏覽器數據并發送給 C2 ) ；

與 Bot 識别相關的網絡流量剖析示例：

與 Bot 識别相關的網絡流量剖析

值得注意的是，我們遇到了一個稍微不同的最終版本的 BundleBot，它共享所有代碼，但除此之外，它還具有通過 HTTPS 将被盜數據泄露到 C2 的功能。我們分析的所有這些樣本都被配置為避免通過 TCP 使用 bot 通信，而只是被配置為将被盜數據泄露到 URL 為 https://cp.bemilcoin [ . ] io/api/cookiePc?cookie 的 C2 web 伺服器。添加的代碼如下所示。

與向 C2 web 伺服器泄露數據相關的代碼

被盜的數據以 ZIP 檔案的形式泄露到 C2 web 伺服器。

被竊取的數據以 ZIP 檔案的形式泄露到 C2 web 伺服器

由于我們能夠獲得這些特定版本的原始 pdb 檔案，并且能夠确認這個新功能產生的依賴項，因此該功能不是由手動更改引起的，而更可能是作為最近添加的功能。

總結

通過對 BundleBot 幾個月的監測，我們更深入地了解了它的攻擊載體，以及它是如何濫用 dotnet bundle ( 單檔案 ) 的，這種自包含格式可以完美繞過靜态檢測。這種特定的檔案格式和多階段攻擊相結合，在幾個月的時間裏大肆傳播。

通過 Facebook 廣告和被攻擊的賬户傳播已經被攻擊者濫用了一段時間，但将其與公開的惡意軟體的功能 ( 竊取受害者的 Facebook 賬户信息 ) 結合起來，可能會成為一種 self-feeding 程式。

我們在本文中介紹了如何濫用 dotnet bundle ( 單檔案 ) 、自包含格式，并通過應用自定義的混淆來進一步強化分析。我們詳細介紹了幾種工具和技術，盡可能完整地分析類似的攻擊。