Background
Since the Log4J vulnerability was exposed, we see more and more malware jumped on the wagon, Elknot, Gafgyt, Mirai are all too familiar, on February 9, 2022, 360Netlab’s honeypot system captured an unknown ELF file propagating through the Log4J vulnerability. What stands out is that the network traffic generated by this sample triggered a DNS Tunnel alert in our system, We decided to take a close look, and indeed, it is a new botnet family, which we named B1txor20 based on its propagation using the file name “b1t”, the XOR encryption algorithm, and the RC4 algorithm key length of 20 bytes.
In short, B1txor20 is a Backdoor for the Linux platform, which uses DNS Tunnel technology to build C2 communication channels. In addition to the traditional backdoor functions, B1txor20 also has functions such as opening Socket5 proxy and remotely downloading and installing Rootkit.
Another interesting point is that we found that many developed features are not put into use (in IDA, there is no cross-reference); some features have bugs. we presume that the author of B1txor20 will continue to improve and open different features according to different scenarios, so maybe we will meet B1txor20’s siblings in the future.
B1txor20 Overview
We have captured a total of four different B1txor20 samples, their functions are almost the same, a total of 15 function numbers are supported, according to these functions, B1txor20 can be characterized as: using DNS Tunnel to establish C2 channel, support direct connection and relay, while using ZLIB compression, RC4 encryption, BASE64 encodingto protect the traffic of the backdoor Trojan, mainly targets ARM, X64 CPU architecture of the Linux platform.
The main features currently supported are shown below.
- SHELL
- Proxy
- Execute arbitrary commands
- Install Rootkit
- Upload sensitive information
Its basic flowchart is shown below.
Reverse Analysis
We choose the sample on February 09, 2022 as the main object of analysis, and its basic information is shown as follows.
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
The sample of B1txor20 is dynamically linked, so it is relatively easy to reverse. Simply put, when B1txor20 executes, it will first disguise itself as a [netns] process, run a single instance through the PID file/var/run/.netns.pid, and then use /etc/machine-id, /tmp/.138171241 or /dev/urandom to generate the BotID, then decrypt the domain name used for DNS Tunnel and the RC4 secret key used to encrypt the traffic and test the connectivity of the DNS server, and finally use DNS Tunnel to send registration information to C2 and wait for the execution of the commands issued by C2. Here we will not go into details about the regular functions, we will take a look at the DNS Tunnel implementation of the B1txor20.
Generating Bot ID
B1txor20 uses the following code snippet to read 32 bytes from /etc/machine-id, or /tmp/.138171241, for generating BotId, and if it fails, a 16 bytes of data will be generated via /dev/urandom and will be written to the previous 2 files.
The following code snippet shows the process of BotId calculation.
Taking the machine-id valueab3b49d10ec42c38b1093b8ce9ad12afof our VM as an example, the following equivalent python code can be used to calculate the value of BotId as 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
Decryption
B1txor20 decrypts the domain name and RC4 secret key stored in the sample with the following code snippet.
Its principle is very simple, it is a single-byte xor operation, where xor_key is49 D3 4F A7 A2 BC 4D FA 40 CF A6 32 31 E9 59 A1.
The decryption process is equivalent to the CyberChef implementation in the following figure, which shows that the domain name is.dns.webserv.systems and the RC4 secret key is EnLgLKHhy20f8A1dX85l.
Measure the connectivity of DNS servers
B1txor20 tests the connectivity of 3 DNS (8.8.8.8:53, 8.8.8.4:53, 194.165.16.24:443) servers with the following code snippet.
The principle is to use res_mkquery API to build the DNS request message for “google.com”, then send the request via res_send, and as long as it can be sent successfully, the network is considered to be connected to the corresponding DNS server, and they are saved for subsequent use.
The actual traffic generated by Bot and 194.165.16.24 is as follows.
C&C Communication
When the above preparations are completed, B1txor20 enters the final stage, using DNS Tunnel to establish communication with C2 and wait for the execution of the commands sent by C2.
Generally speaking, the scenario of malware using DNS Tunnel is as follows:
Bot sends the stolen sensitive information, command execution results, and any other information that needs to be delivered, after hiding it using specific encoding techniques, to C2 as a DNS request; After receiving the request, C2 sends the payload to the Bot side as a response to the DNS request. In this way, Bot and C2 achieve communication with the help of DNS protocol.
In such a network structure, there are 3 key points:
1:C2 must support the DNS protocol
2: Specific encoding techniques
3: The way DNS requests are sent
The following section will analyze the technical details of B1txor20’s communication around these points, in conjunction with the traffic generated by B1txor20 in practice.
0x01:Locating C2
Through the traffic in the above figure, we can see that the SLD used by B1txor20 is webserv.systems, and using the DIG command, we can see that this SLD is point to IP 194.165.16.24; and the DNS resolution service is turned on at this IP 194, so we can determine that the C2 of B1txor20 is exactly 194.165.16.24.
0x02:Generate Tunnel domain name
The format of B1txor20’s Tunnel domain name isBase64-Like String+.dns.websrv.systems. It is obvious that the front Base64 string is the information sent by Bot to C2, how is it generated?
First, the B1txor20 packet has a pre-construction process, which can be seen in the format of0xFF + BotId + 0xFF + Stage + 0xFF + TaskInfo, 0xFF is used to separate different items, and when the construction is finished, according to different Stage values, different tasks will fill theTaskInfosection accordingly.
Take the above task as an example, the Stage value is 1. Through the gather_info function, the information of “sysinfo_uptime,uid,hostname” is filled into TaskInfo, and they are separated by0x0a.
When the required information is ready, B1txor20 uses theprocess_queryfunction to further process the above information, which includes three processes: ZLIB compression, RC4 encryption, and Base64 encoding.
The secret key used in RC4 encryption is the string “EnLgLKHhy20f8A1dX85l” mentioned in the previous decryption section, and the Alphabet String used in Base64 is ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789^_.
Finally, B1txor20 adds 1 byte of status and 4 bytes of random string before the Base64 string generated above, and then splices it with domain, which is the final domain name to be queried. The value of status is [‘0’, ‘1’, ‘2’], 0 means that the current query is truncated, the subsequent query and the current should be spelled into the same; 1 means that when the query is complete.
Let’s take a look at the actual generated query 1HQoOKPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A.dns.webserv.systems, removing the first 5 bytes, and the .dns.webserv.systems part to get KPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A, then use Base64 decoding, RC4 decryption, ZLIB decompression, you can get the following raw data.
From the data content and format, it can correspond with our previous description one by one, indicating that our previous analysis is correct.
Botid =0x125d
Stage=1
sysinfo.uptime = 34
uid=30
hostname=debian
0x3:Send DNS request
When the above domain name construction is complete, B1txor20 generates and sends DNS requests using the RES series API.
There are 3 ways to send DNS requests, depending on the previous test of DNS connectivity.
1.Send to public dns (8.8.8.8, 8.8.4.4)
2.Send directly to C2 (194.165.16.24)
3.Send to local dns (nameserver in /etc/resolv.conf)
In this way, it is faster, but less concealed and easy to be detected and traced; in this way, 1 and 3 are more concealed, but a little slower.
0x4:Process C2 payload
After the Bot sends the DNS request in the above way, it waits for the execution of the C2 instruction, which is stored in the response message of the DNS request in the format of Status(1 byte):Body, where the Body part also uses “ZLIB compression, RC4 encryption, BASE64 encoding ” protection method.
For example, the actual command “1VSE6NZwczNMm2zgaXeLkZro=” is received in the following figure.
Body part for “VSE6NZwczNMm2zgaXeLkZro=”, After decoded by Base64, RC4 decryption, you can get the following format of data, and then decompression of thered part, you get the final instruction FF 02 FF 0A FF, you can see that its format and the format generated by the above query is consistent, at this point it can be known that Bot will go to perform 0x02 function, so that Bot’s round of interaction with C2 is complete.
C&C instructions
B1txor20 supports a total of 14 instructions, and the correspondence between instruction number and function is shown in the following table.
| 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 |
In the table, “Not used” means that this function has the corresponding processing code in the sample, but it is not called. We are not sure if these codes are used for debugging or in other scenarios.
We found that some functions are buggy in their implementation, such as 0x3, which uses the remove function to delete the socket file after bind the domain socket, which makes the socket unconnectable and thus the whole function is useless.
Small note
We noticed the domain name has been registered for 6 years, which is kind unusual?
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
Readers are always welcomed to reach us on Twitter or email us to netlab at 360 dot cn.
IOC
C2
webserv.systems
194.165.16.24:53
194.165.16.24:443
Scanner
104.244.73.126 Luxembourg|Luxembourg|Unknown 53667|FranTech_Solutions
109.201.133.100 Netherlands|North_Holland|Amsterdam 43350|NForce_Entertainment_B.V.
162.247.74.27 United_States|New_York|New_York_City 4224|The_Calyx_Institute
166.78.48.7 United_States|Texas|Dallas 33070|Rackspace_Hosting
171.25.193.78 Sweden|Stockholm_County|Stockholm 198093|Foreningen_for_digitala_fri-_och_rattigheter
185.100.87.202 Romania|Bucharest|Unknown 200651|Flokinet_Ltd
185.129.62.62 Denmark|Region_Hovedstaden|Copenhagen 57860|Zencurity_ApS
185.220.100.240 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.241 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.242 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.243 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.246 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.249 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.250 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.252 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.254 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.100.255 Germany|Bavaria|Nuremberg 205100|F3_Netze_e.V.
185.220.101.134 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.136 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.140 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.143 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.144 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.151 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.155 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.161 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.162 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.164 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.166 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.168 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.172 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.174 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.176 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.181 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.191 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.34 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.37 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.39 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.40 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.42 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.43 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.46 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.5 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.50 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.51 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.53 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.54 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.56 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.57 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.220.101.61 Netherlands|North_Holland|Amsterdam 200052|Feral.io_Ltd
185.56.80.65 Netherlands|South_Holland|Capelle_aan_den_IJssel 43350|NForce_Entertainment_B.V.
193.218.118.158 Ukraine|Kiev|Unknown None;
194.32.107.159 Romania|Romania|Unknown None;
194.32.107.187 Romania|Romania|Unknown None;
194.88.143.66 Italy|Lombardy|Metropolitan_City_of_Milan 49367|Seflow_S.N.C._Di_Marco_Brame'_&_C.
199.195.250.77 United_States|New_York|New_York_City 53667|FranTech_Solutions
23.129.64.216 United_States|Washington|Seattle 396507|Emerald_Onion
23.154.177.4 North_America_Regions|North_America_Regions|Unknown None;
45.13.104.179 France|Ile-de-France|Paris 57199|MilkyWan
45.154.255.147 Sweden|Stockholm_County|Stockholm 41281|KeFF_Networks_Ltd
45.61.185.90 United_States|United_States|Unknown 8100|QuadraNet_Enterprises_LLC
46.166.139.111 Netherlands|South_Holland|Capelle_aan_den_IJssel 43350|NForce_Entertainment_B.V.
5.2.69.50 Netherlands|Flevoland|Dronten 60404|Liteserver_Holding_B.V.
51.15.43.205 Netherlands|North_Holland|Haarlem 12876|Online_S.a.s.
62.102.148.68 Sweden|Stockholm_County|Akersberga 51815|IP-Only_Networks_AB
62.102.148.69 Sweden|Stockholm_County|Akersberga 51815|IP-Only_Networks_AB
81.17.18.62 Switzerland|Canton_of_Ticino|Unknown 51852|Private_Layer_INC
Downloader
hxxp://179.60.150.23:8000/xExportObject.class
ldap://179.60.150.23:1389/o=tomcat
hxxp://194.165.16.24:8229/b1t_1t.sh
hxxp://194.165.16.24:8228/b1t
hxxp://194.165.16.24:8228/b1t
hxxp://194.165.16.24:8228/_run.sh
hxxp://194.165.16.24:8228/run.sh
hxxp://194.165.16.24:8228/share.sh
hxxp://194.165.16.24:8228/b1t
hxxp://194.165.16.24:8228/run.sh
hxxp://194.165.16.24:8228/run.sh
hxxp://194.165.16.24:8229/b4d4b1t.elf
Sample MD5
027d74534a32ba27f225fff6ee7a755f
0a0c43726fd256ad827f4108bdf5e772
24c49e4c75c6662365e10bbaeaeecb04
2e5724e968f91faaf156c48ec879bb40
3192e913ed0138b2de32c5e95146a24a
40024288c0d230c0b8ad86075bd7c678
43fcb5f22a53a88e726ebef46095cd6b
59690bd935184f2ce4b7de0a60e23f57
5f77c32c37ae7d25e927d91eb3b61c87
6b42a9f10db8b11a15006abced212fa4
6c05637c29b347c28d05b937e670c81e
7ef9d37e18b48de4b26e5d188a383ec8
7f4e74e15fafaf3f8b79254558019d7f
989dd7aa17244da78309d441d265613a
dd4b6e2750f86f2630e3aea418d294c0
e82135951c3d485b7133b9673194a79e
fd84b2f06f90940cb920e20ad4a30a63
Source: https://blog.netlab.360.com/b1txor20-use-of-dns-tunneling_en/