關于 Trickbot 惡意軟件新增的 Anchor 模塊分析

譯者：知道創宇404實驗室翻譯組
原文鏈接：https://www.netscout.com/blog/asert/droppi...

摘要

長期以來，Trickbot一直是主要的銀行惡意軟件家族之一。盡管最近發生了一些干擾事件，但攻擊者仍在繼續推動惡意軟件的發展，并在最近開始將其部分代碼移植到Linux操作系統。正如本次技術深入研究所顯示的，命令與控制（C2）服務器與bot之間的通信極其復雜。此外，我們還分析了Linux2版Trickbots的Anchor模塊的C2通信過程。

主要發現

• Trickbot攻擊者利用復雜的通信模式來控制受感染的機器。
• 最近的研究表明，攻擊者將部分代碼轉移到Linux上，從而增加了可移植性和潛在受害者的范圍。
• Anchor模塊可以使用過程化技術來規避分析。
• 基于Windows和Linux的機器能夠在受害者的系統中安裝額外的模塊。

通信設置

Trickbot的Anchor框架是2018年發現的一個后門模塊。該Anchor只部署在選定的目標上。目前Anchor與C2的通信使用DNS通道，我們將在后面介紹。

圖1：Bot和C2之間的通信部分

圖1顯示了bot與C2之間的通信流程。在整個溝通過程中，有一些用于bot的命令（稱為bot_commands）以及用于C2的命令（稱為c2_commands）。下表1中提供了圖1中所示命令的說明。

通信的第1部分是Bot與C2之間的初始設置。僵尸程序將c2_command 0發送到C2，其中包含有關客戶端的信息，包括僵尸程序ID（圖1的第1部分）。建立初始通信后，C2會以一條包含信號/ 1 /的消息作為響應。

在通信的第2部分中，bot發送回相同的信號（也是c2_command 1），而C2則用bot_command響應（圖1的第2部分）。

根據收到的初始bot命令（圖1的第3部分），bot可以進一步請求C2發送可執行文件。

最后，bot將執行結果發送回C2（圖1的第4部分）。

表1：bot和C2之間的通信部分

創建DNS查詢

與C2的通信（圖1）的每個部分都遵循3個不同的DNS查詢序列（圖2）。NTT先前發表了一篇文章，探討了bot如何向Anchor C2服務器創建DNS查詢。在這篇文章中，我們做了進一步的研究，以便更好地理解DNS查詢的每個部分的作用。

圖2:DNS查詢的高級概述

圖2給出了DNS查詢的高級概述。對于發送到惡意軟件C2的數據類型，每個查詢都有自己的格式，如下所述：

Query 0

Bot DNS 查詢

0/anchor_dns////

• 0 –表示0類型查詢
• UUID –bot生成的16字節長度
• current_part –正在發送的數據的當前部分（下面將進一步說明）
• total_parts –數據被分成的部分的總數
• anchor_dns –與C2通信的Anchor bot的類型
• Bot_GUID – Windows和Linux平臺生成的GUID不同
• c2_command –用于C2的命令
• content –根據命令類型發送的內容（表2）

Anchor模塊生成的GUID對于每個平臺都不同：

• Windows-.<32 bytes client id>
• Linux – .<32 bytes client id>

發送到C2的每個命令后面都有其自己的內容集（表2）：

表2：c2_command的內容

由于DNS名稱的最大長度為255個字節，因此為第一個查詢發送的數據將分部分發送。這也解釋了類型0查詢中顯示的字段current_path和total_parts。下面是關于數據分成多少部分的偽代碼：

def get_total_parts(c2, data):
    divider = ((0xfa - len(c2)) >> 1) - 0x18
    size = len(data)
return (size / divider) + 1

與密鑰進行異或后，發送到C2的數據將被設計為子域。密鑰繼續保持為0xb9。

下面的示例顯示了將數據發送到c2_command 0時該數據的內容以及將其分為多少部分：

• 0\x00\x03/anchor_dns/WIN-COMP_W617601.HGDJ3748EURIHDGV192873645672DFGW/0/Windows 7/1001/0.0.0.0/

• 0\x01\x03EAA477CDE0E29EF989E433E633F545A09FD31789937121144906202B0EFD32CB/Tb1i5Xc

• 0\x02\x03Zih0P1wW70rhjGp7G75WsFu69/

C2響應

發送查詢的每個部分后，C2會使用IP進行響應。Bot使用此IP來獲取將在下一個查詢序列中使用的標識符值。

def get_identifier(IP):
return inet_aton(IP) >> 6

Query 1:

Bot DNS 查詢

兩個平臺對類型1都有相同的查詢。類似地，數據在用0xb9進行異或后創建為子域。

• dw_Identifier – 與C2發送給bot的查詢類型為0的值相同

C2響應

指揮與控制系統以IP響應。這個IP也通過與上面偽代碼中get_identifier相同的函數例程傳遞，結果值是最終查詢類型中預期的數據大小。

Query 2:

Bot DNS 查詢

兩個平臺對類型2都有相同的查詢。

• dw_Identifier – C2發送給bot的查詢類型為0的值相同
• dw_DataReceivedSize –到目前為止已接收的數據大小

bot繼續發送查詢類型2請求，直到從C2接收到的數據的總大小與C2響應查詢類型1所發送的值的總大小相匹配。

C2響應

對于bot執行的每個type 2 DNS查詢，C2將用一個IP記錄列表來響應。這個IP列表（圖3）是關于如何構造數據的結構，與NTT提到的完全相同。

圖3:C2發送的IP記錄

IP的第一個帶點十進制數表示bot解析IP列表的順序。

• 本表格的IP地址4.?.?.?顯示C2發送了多少數據，IP的最后3個點狀十進制數字表示大小。
• 本表格的IP地址8.?.?.?顯示當前記錄列表中數據的大小，IP的最后3個點十進制數字表示該值。
• 圖3中的附加IP都是IP的最后3個點號十進制數連接在一起的數據。

在下面的圖4中，我們看到C2發送的IP記錄的PE文件有效負載示例。

圖4：PE文件有效負載示例

Windows Anchor

從C2收到的最終數據具有以下結構：

//anchor_dns//<32_bytes_random_alphanumeric>//\r\n<base64_e

• base64_encoded_data：生成的bot_command子例程使用的信息。

Bot_Command 0

base64_encoded_data from C2–解碼為一系列參數

• 通過cmd.exe執行一系列參數

Bot_Command 1 & 2

base64_encoded_data from C2–解碼為文件名and/or文件參數

• bot向C2進行PE文件的DNS查詢。
  • bot_command 1發送c2_command 5
  • bot_command 2發送c2_command
• EXE在%TEMP%目錄中創建，前綴為tcp并執行。（圖5和圖6）

圖5：正在運行64位Anchor PE

圖6：執行DLL的64位Anchor PE

Bot_Command 5 & 6

base64_encoded_data from C2–解碼為文件名and/or文件參數

• 該漫游器向C2進行PE文件的DNS查詢。
  • bot_command 5發送c2_command 5
  • bot_command 6發送c2_command
• PE文件注入到進程中。

Bot_Command 7&8

base64_encoded_data from C2 –解碼為文件名and/or文件參數

• 該漫游器向C2進行PE文件的DNS查詢。
  • bot_command 5發送c2_command 5
  • bot_command 6發送c2_command
• 通過進程doppelg?nging將PE文件注入到進程中。

Bot_Command 9

base64_encoded_data from C2 –解碼為一系列參數

• 通過管道對象對cmd.exe執行一系列參數

Bot_Command 10

base64_encoded_data from C2 –解碼為一系列參數

• 通過管道對象對powershell.exe執行一系列參數

Bot_Command 11&12

base64_encoded_data from C2–解碼為文件名

• 該bot向C2進行PE文件的DNS查詢。
  • bot_command 11發送c2_command 5
  • bot_command 12發送c2_command
• 該PE文件被注入創建的3個不同的運行進程中。
• 這些過程是explorer.exe，mstsc.exe和notepad.exe。

Bot_Command 13

base64_encoded_data from C2 –解碼為計劃的任務字符串

• bot更改了預定任務

Bot_Command 14

• 卸載Anchor

Linux Anchor

Linux Anchor模塊是由Stage 2 Security首先發現的。Stage2 Security所做的分析是廣泛的，但是我們想用與上面Windows版本相同的方式更仔細地研究C2通信。

0-4中的bot_命令包含Linux模塊在嘗試連接到任何Windows共享時要使用的smb2信息（包括域、用戶和密碼）。該模塊有一個嵌入式PE文件，用于在Windows共享上執行命令或文件。

Bot_Command 0

base64_encoded_data from C2 -解碼為一系列參數

• 通過Windows共享上的cmd.exe執行一系列參數。

Bot_Command 1&2

base64_encoded_data from C2-解碼為文件名and/or文件參數

• 該bot向C2進行PE文件的DNS查詢。
  • bot_command 1發送c2_command 5
  • bot_command 2發送c2_command
• 文件被執行。

Bot_Command 3和4

base64_encoded_data from C2-解碼為文件名和/或文件參數

• 該bot向C2進行PE文件的DNS查詢。
  • bot_command 3發送c2_command 5
  • bot_command 4發送c2_command
• DLL文件導出功能Control_RunDLL被執行。

Bot_Command 10&11&12

base64_encoded_data from C2

• 對于bot_command 10，編碼數據是由bot執行的Linux文件。
• Bot_Commands 11和12向Linux的C2進行DNS查詢。
  • bot_command 11發送c2_command 5
  • bot_command 12發送c2_command
• bot將文件的權限設置為777并執行。

Bot_Command 100

base64_encoded_data from C2-解碼為GUID

• bot檢查C2發送的GUID是否與bot的GUID相匹配。
• 如果GUID不匹配，bot會終止C2通信。

結論

Anchor的C2通信的復雜性和bot可以執行的有效負載反映了Trickbot攻擊者相當大的創新能力，這從他們轉向Linux就可以看出。需要注意的是，Trickbot并不是實現瞄準其他操作系統的唯一惡意軟件。今年早些時候，我們分析了一個名為Lucifer的DDoS bot，該bot可以在Windows和Linux平臺上運行。隨著越來越多的攻擊者在構建交叉編譯惡意軟件系列，安全人員必須重新評估Linux系統的安全實踐，以確保他們做好充分準備抵御這些日益增長的威脅。

IOC:

Anchor C2s:

• westurn[.]in
• onixcellent[.]com
• wonto[.]pro
• ericrause[.]com

Anchor PE 64bit

• SHA256 - c427a2ce4158cdf1f320a1033de204097c781475889b284f6815b6d6f4819ff8
• SHA256 - 4e5fa5dcd972170bd06c459f9ee4c3a9683427d0487104a92fc0aaffd64363b2

Anchor ELF 64bit

• SHA256 - 4655b4b44f6962e4f9641a52c24373390766c50b62fcc222e40511c0f1ed91d2

Anchor PE 32bit Helper file for Linux

• SHA256 - 7686a3c039b04e285ae2e83647890ea5e886e1a6631890bbf60b9e5a6ca43d0a