overview
On September 3, 2019, we captured a suspicious sample file. Most of the antivirus engines identified it as gafgyt, but the similarity between the sample and the known gafgyt is not high. Only part of the code of gafgyt is reused. After detailed analysis, we confirm that this is another P2P botnet based on DHT protocol after Hajime. According to the characteristics of its sample propagation sample file named Mozi. M, Mozi. A, we named it Mozi botnet.
Mozi.m
Mozi.a
Mozi
Mozi botnet relies on DHT protocol to build a P2P network. Ecdsa384 and XOR algorithm are used to ensure the integrity and security of its components and P2P network. The samples are worm propagated through telnet weak password and some known vulnerabilities. In terms of function, the execution of instructions of each node in Mozi botnet is driven by the payload named config issued by botnet master. The main instructions include:
- DDoS attack
- Collect BOT information
- Executes the payload for the specified URL
- Update sample from specified URL
- Execute system or custom commands
The overall network structure is shown in the figure below:
Sample propagation
Mozi infects new devices through telnet weak password and vulnerability exploitation. The infection process is as follows:
- The current BOT node randomly listens to the local port to start the HTTP service to provide sample download or receive the sample download address in the config file issued by the botnet master. Used to provide a sample download address for future infected targets.
- The current BOT node logs in to the target device with a weak password, writes the downloader file in echo mode and runs it, and downloads the sample file from the sample download address provided by the current BOT node. Or exploit the intrusion target through the vulnerability, and then obtain the sample file from the sample download address provided by the current BOT node.
- Run Mozi BOT samples on the infected target devices, join the Mozi P2P network to become a new Mozi BOT node and continue to infect other new devices.
The vulnerabilities exploited by Mozi botnet are shown in the following table:
At present, we do not know the scale of the Botnet, but according to the data we have, the infection of the botnet has been growing. The following figure shows the Mozi BOT infection log collected by our honeypot.
Sample reverse analysis
At present, there are three versions of Mozi Botnet, which are slightly different in telnet communication, and very close in other aspects. The following will mainly focus on the latest version V2, and will also intersperse the earlier version (sample MD5: 849b165f28ae8b1c7430f44af3). Analyze the technical details of Mozi from the aspects of communication mode, config structure, DHT network, etc.
849b165f28ae8b1cebe0c7430f44aff3
Sample information
MD5:eda730498b3d0a97066807a2d98909f3
ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped
Packer: NO
Library:uclibc
Version: V2
It is worth mentioning that Mozi adopted upx shell in the first version. Mozi uses a novel technique to put the value of P ﹣ filesize & P ﹣ blocksize into 0. You need to make the corresponding patch to the upx source code to get out of the shell.
Common functions
Mozi doesn't have many features at the host behavior level. It reuses the code of gafgyt and implements many common functions, such as single instance, process name modification and network traffic release.
Perform specific tasks
After Mozi establishes P2P network through DHT protocol, it synchronizes the config file and starts corresponding tasks according to the instructions in the config file. In P2P networks, nodes are untrustworthy. Anyone can forge a Mozi node at a very low cost. In order to ensure that Mozi network is completely controllable and not stolen by others, Mozi needs to do signature verification for each synchronized config. Only through signature verification can it be accepted and executed by Mozi node.
Document & Instruction verification
Mozi uses ecdsa384 algorithm to verify the validity of files and instructions. Each sample integrates two XOR encrypted public keys, which are respectively used to verify the signature encryption and the decrypted config file.
xor key:4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E
------------------------------------------------------------------
xored publickey A
4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F
69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B
38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 A1
after decryption:
02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21
27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65
76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea ef
-------------------------------------------------------------------
xored publickey B
4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8
E9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53
22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 88
after decryption:
02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6
a7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d
6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 c6
Config file
Each sample integrates an XOR encrypted initial config file with a length of 528 bytes. Its structure is data (428 bytes), sign (96 bytes), flag (4 bytes). The sign field is a digital signature. The flag field controls whether the config file is updated or not. There are many control fields in the config file. After receiving the config, the Mozi node parses the contents of the fields and executes the corresponding subtasks. The original config file is decrypted as shown in the following figure, where XOR key is
4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E
The decrypted config supports the following keywords: auxiliary, control and subtask.
1：辅助字段，用于信息说明
[cpu] cpu arch or os
[cpux] cpu arch or os
[ss] bot role
[ssx] bot role
[nd] new node info which help to join DHT
2:控制字段，用于更新节点的数据
[ver] verify
[sv] update Config
[hp] DHT id prefix
[dip] URL or ip:port list which can get Mozi sample
3:子任务字段，用于开启相应的子任务
[atk] DDOS attack
[ud] update
[dr] exec payload from specific URL
[rn] exec system or customized cmds
[idp] report bot info
Bot function
DHT
Mozi botnet uses its own extended DHT protocol to build P2P network, which has two advantages: one is that it can use standard DHT to quickly network, and the other is that it can use its own expansion to hide the effective payload traffic in the massive normal DHT traffic and avoid detection. Mozi uses eight groups of common nodes and the nodes specified in the [nd] field of the config file as bootstrap nodes. Boot the new node into its DHT network.
- Common node, sample embedded
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
212.129.33.59:6881
82.221.103.244:6881
130.239.18.159:6881
87.98.162.88:6881
- [nd] in config file specifies
ID generation
Id20 bytes, consisting of the prefix (888888) embedded in the sample or the prefix specified in the config file [HP], plus randomly generated strings.
Node recognition
In order to quickly distinguish traffic, Mozi uses the identification of 1: V4: Flag (4 bytes) to identify whether the traffic is sent by its nodes. The meaning of flag bytes is as follows:,
1:v4:flag(4 bytes)
flag(4 bytes)
----------------------------------------------
offset:
0 -----random
1 ----- hard-code(0x42) or from [ver]
2 -----calc by algorithm
3 -----calc by algorithm
The first byte is generated randomly, and the second byte is hard coded 0x42 or specified by the [ver] field in the config file. The 3rd and 4th bytes are obtained by the algorithm,
ver algorithm
----------------------------------------------
int first,sec;
string ver="\x31\x3a\x76\x34\x3a\x00\x00"s;
cout << "Please input the two number: (0x00-0xff)" << endl;
cin.unsetf(ios::hex);
cin >> hex >> first >> sec;
ver[5] = char(first);
ver[6] = char(sec);
uint32_t va = 0;
for(int i = 0; i < 7; i++)
{
uint32_t tmp = int(ver[i]);
tmp = tmp << 8;
tmp ^= va;
int rnd = 8;
while (rnd--)
{
if ((tmp & 0xffff) > 0x8000)
{
tmp *= 2;
tmp ^= 0xffff8005;
}
else
tmp *= 2;
}
va = tmp&0xffff;
}
cout << hex << "Final " << va << endl;
Please input the two number: (0x00-0xff) 0x44 0x42final 1f71 input 0x44 0x42 to get 0x1f71, which is consistent with the result in the packet.
0x1f71
Network request
The network requests received by Mozi nodes can be divided into two categories: DHT requests and non DHT requests. According to the above node identification, DHT requests are divided into Mozi DHT requests and non Mozi DHT requests. Mozi supports Ping, find node and get peers. For non DHT requests, there are two types according to whether the network packet length is greater than 99.
Mozi numbers different requests as follows, and different requests have different processing logic
原始数据内容(节选前128字节):
00000000 64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38 |d1:rd2:id20:8888|
00000010 38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69 |8888·. .fáq.åM>i|
00000020 35 3a 6e 6f 64 65 73 36 32 34 3a 15 15 29 d2 f3 |5:nodes624:..)Òó|
00000030 a3 f7 0c fe df 1a 5d bd 3f 32 46 76 5e 62 b7 b8 |£÷.þß.]½?2Fv^b·¸|
00000040 f0 94 78 a2 c4 37 5b 8e 2c 00 0b 20 12 07 e7 f4 |ð.x¢Ä7[.,.. ..çô|
00000050 bc dc 19 a2 83 2e 67 fb 7a 5e 50 22 07 75 e8 ef |¼Ü.¢..gûz^P".uèï|
00000060 f9 93 4a e9 91 75 36 e4 76 57 4b 7c 51 7c ff f5 |ù.Jé.u6ävWK|Q|ÿõ|
00000070 f5 c4 57 f9 dc 62 35 b4 6a 5d 18 6b 54 3c ed e1 |õÄWùÜb5´j].kT<íá|
00000080 a1 c8 56 a3 cf 28 6b fa 14 06 1a 3e 3b 01 a0 e3 |¡ÈV£Ï(kú...>;. ã|
加密的Config位于"5:nodes624:"之后，使用xor key(4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E) 解密后:
原始数据部分：
00000000 64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38 |d1:rd2:id20:8888|
00000010 38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69 |8888·. .fáq.åM>i|
00000020 35 3a 6e 6f 64 65 73 36 32 34 3a |5:nodes624:
Config部分:
00000000 5b 73 73 5d 73 6b 5b 2f 73 73 5d 5b 68 70 5d 38 |[ss]sk[/ss][hp]8|
00000010 38 38 38 38 38 38 38 5b 2f 68 70 5d 5b 63 6f 75 |8888888[/hp][cou|
00000020 6e 74 5d 68 74 74 70 3a 2f 2f 69 61 2e 35 31 2e |nt]http://ia.51.|
00000030 6c 61 2f 67 6f 31 3f 69 64 3d 32 30 31 39 38 35 |la/go1?id=201985|
00000040 32 37 26 70 75 3d 68 74 74 70 25 33 61 25 32 66 |27&pu=http%3a%2f|
Disposal suggestion
We suggest that users update the patch in time, judge whether it is infected according to the process, file name and HTTP, DHT network connection characteristics created by Mozi Botnet, and then clean up its related processes and files.
Relevant security and law enforcement agencies can contact NetLab [at] 360.cn by email for more information.
Contact us
Interested readers can contact us at twitter or on WeChat official account 360Netlab.
IoC list
Sample MD5:
eda730498b3d0a97066807a2d98909f3
849b165f28ae8b1cebe0c7430f44aff3