背景
自從Log4J漏洞被曝光後，正所謂"忽如一夜漏洞來，大黑小灰笑開懷”。無數黑産團夥摩拳擦掌加入了這個“狂歡派對”，其中既有許多業界非常熟悉的惡意軟體家族，同時也有一些新興勢力想趁着這股東風在黑灰産上分一杯羹。360Netlab作為專注于蜜罐和Botnet檢測跟蹤的團隊，我們自該漏洞被公開後就一直關注它會被哪些僵屍網絡利用，期間我們看到了Elknot，Gafgyt，Mirai等老朋友的從不缺席，也見證了一些新朋友的粉墨登場。
2022年2月9日，360Netlab的蜜罐系統捕獲了一個未知的ELF檔案通過Log4J漏洞傳播，此檔案在運作時産生的網絡流量引發了疑似DNS Tunnel的告警，這引起了我們的興趣。經過分析，我們确定是一個全新的僵屍網絡家族，基于其傳播時使用的檔案名"b1t"，XOR加密算法，以及RC4算法秘鑰長度為20位元組，它被我們命名為B1txor20。
簡單來說，B1txor20是一個針對Linux平台的後門木馬， 它利用DNS Tunnel技術建構C2通信信道，除了傳統的後門功能，B1txor20還有開啟Socket5代理，遠端下載下傳安裝Rootkit，反彈Shell等功能，這些功能可以很友善的将被侵入的裝置變成跳闆，供後續滲透時使用。
另外一個有意思的點是我們發現許多開發好了的功能并沒有投入使用（在IDA中表現為，沒有交叉引用)；有些功能存在BUG。我們推測B1txor20的作者會持續完善，并根據的不同場景，定制式地開啟不同的功能，或許以後我們将遇到B1txor20的兄弟姐妹。
鑒于B1txor20所使用漏洞的高危性，以及其C2信道的隐蔽性，我們決定撰寫本文向社群分享我們的發現，共同維護網絡安全。
B1txor20概覽
我們一共捕獲了4個不同MD5的B1txor20樣本檔案，它們的功能幾乎一樣，一共支援15個功能号，根據這些功能，可以将B1txor20定性為：一個使用DNS Tunnel技術建構隐蔽的C2信道，支援直連和中繼2種方式，同時使用zlib壓縮，RC4加密，BASE64編碼的方式保護流量的後門木馬，目前通過Log4j漏洞傳播，主要針對ARM,X64 CPU架構的Linux平台。
目前支援的主要功能如下所示：
- SHELL
- Proxy
- 執行任意指令
- 安裝Rootkit
- 上傳敏感資訊
它的基本流程圖如下所示：
逆向分析
本文選擇2022年2月09日的樣本為主要分析對象，它的基本資訊如下所示：
MD5:0a0c43726fd256ad827f4108bdf5e772
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
Packer:None
B1txor20的樣本是動态連結的，是以在逆向上比較容易，簡單來說，當B1txor20在被侵入裝置動行後，首先會将自身僞裝成[netns]程序，通過/var/run/.netns.pid這個PID檔案實作單一執行個體，然後使用/etc/machine-id，/tmp/.138171241或/dev/urandom3者中任意一個，生成BotID，接着解密用于DNS Tunnel的域名，以及用于加密流量的RC4秘鑰并測試DNS伺服器的連通性，最後使用DNS Tunnel技術向C2發送上線資訊，等待執行C2下發的指令。其中程序僞裝，單一執行個體這些功能比較簡單，就再不細述，下文将圍繞DNS Tunnel剖析B1txor20的實作。
生成Bot ID
B1txor20通過以下代碼片段從etc/machine-id，或/tmp/.138171241，讀取32位元組用于生成BotId，如果失敗，則通過/dev/urandom生成16位元組資料，并将它寫入到前面2個檔案。
下面的代碼片段是BotId的計算過程：
以我們虛拟機的machine-id值ab3b49d10ec42c38b1093b8ce9ad12af為例，通過下面等效的python代碼，可以算出BotId的值為0x125d。
import struct
id='ab3b49d10ec42c38b1093b8ce9ad12af'
values=struct.unpack("<16H",id)
sum=0
for i in values:
sum ^= i
print hex(sum)
if sum&0xff <0xf:
sum+=0x10
if sum>>8 < 0xf:
sum+=0x1000
print hex(sum) # sum=0x125d
解密
B1txor20通過以下代碼片段解密存儲在樣本中的域名和RC4秘鑰，
它的原理非常簡單，就是單位元組xor操作，其中xor_key為49 D3 4F A7 A2 BC 4D FA 40 CF A6 32 31 E9 59 A1
通過下圖的CyberChef實作等效的解密過程，可知域名為.dns.webserv.systems，RC4秘鑰為EnLgLKHhy20f8A1dX85l。
測出DNS伺服器的連通性
B1txor20通過以下代碼片段測試3個DNS （8.8.8.8:53，8.8.8.4:53，194.165.16.24:443）伺服器的連通性。
它的原理是使用res_mkqueryAPI建構“google.com”的DNS請求封包，然後通過res_send發送請求，隻要能夠發送成功，就認為和相應DNS伺服器的網絡是連通，把它們儲存起來供後續使用。
實際中Bot與194.165.16.24産生的流量如下所示：
C&C通信
當上述的準備工作完成後，B1txor20進入最終階段，使用DNS Tunnel技術和C2建立通信，等待執行C2下發的指令。
一般來說惡意軟體使用DNS Tunnel的場景是這樣的：Bot把竊取的敏感資訊，指令的執行結果等等任何需要傳遞的資訊，在使用特定的編碼技術隐藏之後，以DNS請求的方式，将它發送到C2；C2到接收到請求之後，把payload做為DNS請求的響應，将它發送到Bot端。這樣一來，Bot與C2就在DNS協定的幫助之下實作了通信。在這樣的網絡結構中，有3個關鍵的點值得注意
- C2必須支援DNS協定
- 特定的編碼技術
- DNS請求的發送方式
下文将圍繞這些點，結合B1txor20在實際中産生的流量，分析B1txor20的通信技術細節。
0x01:定位C2
通過上圖的流量，可以看出B1txor20使用的SLD是webserv.systems，使用DIG指令可知此SLD綁定的IP為194.165.16.24；而194這個IP上又開啟了DNS解析服務，是以我們可以确定B1txor20的C2正是194.165.16.24。
0x02:生成Tunnel域名
B1txor20的Tunnel域名格式為Base64-Like String+.dns.websrv.systems 很明顯前面
類似Base64的字串就是Bot發往C2的資訊，它是如何生成的呢？
首先，B1txor20資料包的有一個前置構造過程，可以看出其格式為0xFF + BotId + 0xFF + Stage + 0xFF + Other Info，0xFF用于分隔不同的項，當成完構造後，再根據不同的Stage值，進入不同的任務，填充Other Info部分。
以上線這個任務為例，Stage值為1，通過gather_info函數，将"sysinfo_uptime,uid,hostname"這些資訊填充到Other Info中，它們使用0x0a分隔。
當所需的資訊都已準備好之後，B1txor20接着使用process_query函數對上面的資訊進一步處理，它包括ZLIB壓縮，RC4加密，Base64編碼3個過程。
其中RC4加密所使用的秘鑰就是前文解密章節所說的字串“EnLgLKHhy20f8A1dX85l”，Base64使用的Alphabet String為ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789^_。
最後B1txor20在上面生成的Base64字串前加入1位元組表示status，4位元組随機字串，再和domain進行拼接，就麼得了最終要查詢的域名。其中status的取值為['0', '1', '2']，0表示目前的查詢被截斷了，後續的查詢和目前應該拼成同一個；1表示當成查詢是完整的。
以實際産生的一個查詢1HQoOKPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A.dns.webserv.systems為例，去除前5位元組，以及.dns.webserv.systems部分，得到KPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A，然後使用Base64解碼，RC4解密，ZLIB解壓，就能得到了以下原始資料。
從資料内容和格式來看，它和我們前文的描述能一一對應，說明我們前面的分析是正确的。
Botid =0x125d
Stage=1
sysinfo.uptime = 34
uid=30
hostname=debian
0x3:發送DNS請求
當上述域名構造完成後，B1txor20使用RES系列API生成并發送DNS請求。
根據前文測試DNS連通情況的不同，發送DNS請求的方式有3種。
- 向public dns(8.8.8.8，8.8.4.4)發送
- 直接向C2(194.165.16.24)發送
- 向local dns(nameserver in /etc/resolv.conf)發送
其中2這種方式，它的速度較快，但蔽性弱，很容易被探測追蹤；1,3這種倆種方式隐蔽性強，但速度稍慢。
0x4:處理C2指令
當Bot通過上述方式發送DNS請求後，就等待執行C2下發的指令。C2的指令存放在DNS請求的響應封包中，它的格式為Status(1 byte):Body，其中Body部分也使用了“ZLIB壓縮，RC4加密，BASE64編碼”這種保護方法。
以下圖實際收到的指令“1VSE6NZwczNMm2zgaXeLkZro= ”為例，
Body部分為"VSE6NZwczNMm2zgaXeLkZro="，它經過Base64解碼，RC4解密後，就能得到了以下格式的資料，再将紅色部分解壓，就得到了最終的指令FF 02 FF 0A FF，可以看出它的格式和上文查詢産生的格式是一緻的，此時可知Bot将去執行0x02号功能，至此Bot與C2的一輪互動就完成了。
C&C指令
B1txor20一共支援15條指令，指令号與功能的對應關系如下表所示：
| CMD ID | FUNCTION |
| 0x1 | Beacon/Heartbeat |
| 0x2 | Upload system info |
| 0x3 | Create "/dev/pamd" (unix domain socket) which can get a shell |
| 0x4 | Exec arbitrary system cmd via popen |
| 0x5 | Traffic forwarding |
| 0x6 | Write File |
| 0x7 | Read File |
| 0x8 | Deliver info via "/var/tmp/.unetns"(unix domain socket)，Not used |
| 0x9 | Upload specific info，Not used |
| 0x10 | Stop proxy service |
| 0x11 | Start proxy service |
| 0x1a | Create proxy service |
| 0x21 | Reverse shell |
| 0x50 | Upload "/boot/conf- XXX" info，Not used |
| 0x51 | install M3T4M0RPH1N3.ko rootkit |
表中"Not used"表示這個功能，在樣本中有應的處理代碼，但沒有被調用，我們不确定這些代碼是用于調試的，或是在别的樣本中使用。
另外有意思的一點是，我們發現有些功能在實作上是有Bug的，如0x3，它在bind 域套接字後，使用remove函數删除了套接字檔案，這會讓此套接字無法被connect，進而整個功能失效。
花絮
域名一買就是6年，這是想要大幹一票？
webserv.systems createddate 2021-02-08 15:13:22
webserv.systems updateddate 2021-02-24 22:27:23
webserv.systems expiresdate 2027-02-08 15:13:22