Mozi, Another Botnet Using DHT
<!--kg-card-begin: markdown--><h2 id="overview">Overview</h2>
<p>On September 03, 2019, a suspicious file was tagged by our new threat monitoring system and a quick checking on VT shows most engines flagged it as Gafgyt. The sample does reuse part of the Gafgyt code, but it is not really Gafgyt.</p>
<p>The sample represents a brand new P2P botnet implemented based on the DHT protocol, the last botnet which uses DHT is the Hajime, and we call it Mozi according to the characteristics of its propagation sample file name <code>Mozi.m</code>,<code>Mozi.a</code>.</p>
<p>Mozi Botnet relies on the DHT protocol to build a P2P network, and uses ECDSA384 and the xor algorithm to ensure the integrity and security of its components and P2P network. The sample spreads via Telnet with weak passwords and some known exploits (see the list below). In terms of functions, the execution of the instructions of each node in the Mozi botnet is driven by a Payload called Config issued by the Botnet Master. The main instructions include:</p>
<ul>
<li>DDoS attack</li>
<li>Collecting Bot Information</li>
<li>Execute the payload of the specified URL</li>
<li>Update the sample from the specified URL</li>
<li>Execute system or custom commands</li>
</ul>
<p>The overall network structure is shown in the following figure:<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_flow-3.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_flow.m.png" class="kg-image"/></a></p>
<h2 id="samplespread">Sample Spread</h2>
<p>Mozi infects new devices through weak telnet passwords and exploits.The infection process is as follows:</p>
<ul>
<li>The current Bot node randomly uses a local port to start the http service to provide sample downloads or receives the sample download address in the Config file issued by the Botnet Master.Provides a sample download address for future infected targets.</li>
<li>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 use a vulnerability to exploit the target, and then obtain a sample file from the sample download address provided by the current Bot node.</li>
<li>Run the Mozi Bot sample on the infected target device, join the Mozi P2P network to become the new Mozi Bot node and continue to infect other new devices.</li>
</ul>
<p>The vulnerabilities used by Mozi Botnet are shown in the following table:</p>
<table>
<thead>
<tr>
<th>Vulnerability</th>
<th>Affected Aevice</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://www.exploit-db.com/exploits/40740">Eir D1000 Wireless Router RCI</a></td>
<td>Eir D1000 Router</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/6864/">Vacron NVR RCE</a></td>
<td>Vacron NVR devices</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/37169/">CVE-2014-8361</a></td>
<td>Devices using the Realtek SDK</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/41598/">Netgear cig-bin Command Injection</a></td>
<td>Netgear R7000 and R6400</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/43055">Netgear setup.cgi unauthenticated RCE</a></td>
<td>DGN1000 Netgear routers</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/41471/">JAWS Webserver unauthenticated shell command execution</a></td>
<td>MVPower DVR</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/43414/">CVE-2017-17215</a></td>
<td>Huawei Router HG532</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/37171/">HNAP SoapAction-Header Command Execution</a></td>
<td>D-Link Devices</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/44576/">CVE-2018-10561, CVE-2018-10562</a></td>
<td>GPON Routers</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/28333/">UPnP SOAP TelnetD Command Execution</a></td>
<td>D-Link Devices</td>
</tr>
<tr>
<td><a href="https://www.exploit-db.com/exploits/39596/">CCTV/DVR Remote Code Execution</a></td>
<td>CCTV DVR</td>
</tr>
</tbody>
</table>
<p>At present, we do not know the exact scale of the Botnet, we do manage to become a node to join the DHT network and are tracking some baseline numbers, we will share more details probably in another blog later on. And from other data we have collected, we can also see the number of infection has been increasing.The picture below shows the Mozi bot infection based on the log collected by our honeypot.<br>
<img src="__GHOST_URL__/content/images/2019/12/fssfsadfsdff.png" alt="fssfsadfsdff" loading="lazy"></p>
<h2 id="samplereverseanalysis">Sample Reverse Analysis</h2>
<p>There are three versions of Mozi Botnet, which can be distinguished by their slightly different telnet propagation methods.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_versioin.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_versioin.png" class="kg-image"/></a><br>
Our analysis is mainly focus on the latest version v2, and this blog will cover the key elements such as propagation method, Config structure and its DHT network.</p>
<h3 id="sampleinformation">Sample Information</h3>
<blockquote>
<p>MD5:eda730498b3d0a97066807a2d98909f3</p>
<p>ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped</p>
<p>Packer: NO</p>
<p>Library:uclibc</p>
<p>Version: v2</p>
</blockquote>
<p>It is worth mentioning that in the first version Mozi(sample md5: <code>849b165f28ae8b1cebe0c7430f44aff3</code>) used upx packing. But instead of using the common upx magic number to defeat unpacking, it used a novel method, to erase the value of p_filesize &amp; p_blocksize to zero, with that change, researcher need to patch the upx source code then unpacking is possible.</p>
<h3 id="commonfunctions">Common Functions</h3>
<p>Mozi doesn't have much characteristics in the host behavior level. It reuses Gafgyt's code to implements many common functions, such as single instance, process name modification, and ACL modification.</p>
<ul>
<li>Single instance, by binding local port<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_bind.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_bind.png" class="kg-image"/></a></li>
<li>Change the process name to sshd or dropbear to confuse the victim<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_setname.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_setname.png" class="kg-image"/></a></li>
<li>ACL modification, Open up the ports;block SSH, TELNET services to prevent Bot from being re-infected by other malicious actors.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_iptables.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_iptables.png" class="kg-image"/></a></li>
</ul>
<p><a href="__GHOST_URL__/content/images/2019/12/mozi_forb.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_forb.png" class="kg-image"/></a></p>
<h3 id="performspecifictasks">Perform Specific Tasks</h3>
<p>After Mozi establishes the p2p network through the DHT protocol, the config file is synchronized, and the corresponding tasks are started according to the instructions in the config file.In P2P networks, nodes are untrusted, and anyone can fake a Mozi node at a very low cost.In order to ensure that the Mozi network is completely controllable and cannot be stolen by others, Mozi needs to perform signature verification on each synchronized config, and only if it can pass the signature verification can it be accepted and executed by the Mozi node.</p>
<p><a href="__GHOST_URL__/content/images/2019/12/mozi_configproc.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_configproc.png" class="kg-image"/></a></p>
<h4 id="documentinstructioninspection">Document &amp; Instruction Inspection</h4>
<p>Mozi uses the ECDSA384 algorithm to verify the legitimacy of files and instructions. Each sample integrates two xor-encrypted public keys, which are used to sign encrypted and decrypted config files, respectively.</p>
<pre><code> 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
</code></pre>
<h4 id="configfile">Config File</h4>
<p>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 and the flag field controls if 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 field content and executes the corresponding subtasks.The original config file is as follows.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_enconfig.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_enconfig.png" class="kg-image"/></a><br>
The decryption process is shown in the following figure, where the xor key is <code>4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E</code></p>
<p><a href="__GHOST_URL__/content/images/2019/12/mozi_xorproc.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_xorproc.png" class="kg-image"/></a><br>
The decrypted config is as follows.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_denconfig.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_denconfig.png" class="kg-image"/></a><br>
The supported keywords are as follows, which can be divided into three categories: declaration, control, and subtask.</p>
<pre><code>1：declaration
[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:control
[ver] 	verify 
[sv]	update  Config
[hp] 	DHT id prefix
[dip]   URL or ip:port list which can get Mozi sample
3:subtask
[atk]	DDOS attack
[ud] 	update
[dr] 	exec payload from specific URL 
[rn] 	exec system or customized cmds
[idp] 	report bot info
</code></pre>
<h4 id="botfunction">Bot Function</h4>
<ul>
<li>DDOS，<code>[atk]</code>field trigger, reuse Gafgyt attack code, support HTTP, TCP, UDP and other attacks.<pre><code>Command
-----------------------------------------
S    
T
U
KT
HTTP
</code></pre>
<a href="__GHOST_URL__/content/images/2019/12/mozi_atk.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_atk.png" class="kg-image"/></a></li>
<li>Report Bot information,<code>[idp]</code>field trigger, the content reported are Bot ID, IP, PORT, file name (full path), gateway, cpu architecture.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_idp.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_idp.png" class="kg-image"/></a></li>
<li>The payload of the specified URL is executed, and the<code>[dr]</code> field is triggered.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_dr.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_dr.png" class="kg-image"/></a></li>
<li>Update from the specified URL, the <code>[ud]</code>field is triggered. Close the current node's network connection and related processes, download the new version from the specified URL, save DHT node, ID and other data, and provide them as parameters for the new version.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_ud.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_ud.png" class="kg-image"/></a></li>
<li>Execute system or Bot custom command,<code>[rn]</code>field trigger.
<ul>
<li>System command<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_rnsys.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_rnsys.png" class="kg-image"/></a></li>
<li>Customize the<code>GET</code>command and send the Bot ID to the peer.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_rnget.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_rnget.png" class="kg-image"/></a></li>
<li>Customize the<code>run</code>command, execute the command issued by the peer, and return the result.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_rnrun.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_rnrun.png" class="kg-image"/></a></li>
</ul>
</li>
</ul>
<h3 id="dht">DHT</h3>
<p>Mozi Botnet uses its own extended DHT protocol to build a P2P network. There are two benefits to this. One is to use standard DHT to quickly establish a network, and the other is to use its own extension to hide the valid payload in the vast amount of normal DHT traffic so detection is impossible without proper knowledge. Mozi uses 8 sets of public nodes and the nodes specified in the [nd] field of the Config file as bootstrap nodes, toguide new nodes to join their DHT network.</p>
<ul>
<li>Public node, sample embedded</li>
</ul>
<pre><code>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
</code></pre>
<ul>
<li>[nd] Specified in the Config file<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_nd.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_nd.png" class="kg-image"/></a></li>
</ul>
<h4 id="idgeneration">ID Generation</h4>
<p>The ID is 20 bytes and consists of the prefix <code>888888</code> embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.</p>
<p><a href="__GHOST_URL__/content/images/2019/12/mozi_id.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_id.png" class="kg-image"/></a></p>
<h4 id="noderecognition">Node Recognition</h4>
<p>In order to distinguish regular traffic with its own traffic, Mozi uses<code>1:v4:flag(4 bytes)</code>such an identifier to identify whether the traffic is sent by its node. The meaning of the flag byte is as follows.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_node.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_node.png" class="kg-image"/></a><br>
flag means is as follows</p>
<pre><code>flag(4 bytes)
----------------------------------------------
offset:
	0  -----random
	1  ----- hard-code(0x42) or from [ver]
    2  -----calc by algorithm
    3  -----calc by algorithm
</code></pre>
<p>The first byte is randomly generated. The second byte is hard-coded 0x42 or specified by the [ver] field in the config file.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_ver.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_ver.png" class="kg-image"/></a><br>
The 3rd and 4th bytes are obtained by the algorithm.</p>
<pre><code>ver algorithm
----------------------------------------------
	int first,sec;
	string ver=&quot;\x31\x3a\x76\x34\x3a\x00\x00&quot;s;
	cout &lt;&lt; &quot;Please input the two number: (0x00-0xff)&quot; &lt;&lt; endl;
	cin.unsetf(ios::hex);
	cin &gt;&gt; hex &gt;&gt; first &gt;&gt; sec;
	ver[5] = char(first);
	ver[6] = char(sec);
	uint32_t va = 0;
	for(int i = 0; i &lt; 7; i++)
	{	
		uint32_t tmp = int(ver[i]);
		tmp = tmp &lt;&lt; 8;
		tmp ^= va;
		int rnd = 8;
	while (rnd--)
	{
		if ((tmp &amp; 0xffff) &gt; 0x8000)
		{
			tmp *= 2;
			tmp ^= 0xffff8005;
		}
		else
			tmp *= 2;
	}
	va = tmp&amp;0xffff;
	}
	cout  &lt;&lt; hex  &lt;&lt; &quot;Final &quot; &lt;&lt;  va &lt;&lt; endl;
</code></pre>
<blockquote>
<p>Please input the two number: (0x00-0xff)<br>
0x44 0x42<br>
Final 1f71<br>
Enter 0x44 0x42, and get the <code>0x1f71</code> same result as in the packet.</p>
</blockquote>
<h4 id="networkrequest">Network Request</h4>
<p>The network requests received by Mozi nodes can be divided into two categories, DHT requests and non-DHT requests. According to the aforementioned node identification, DHT requests are then again divided into Mozi-DHT requests and non-Mozi-DHT requests. Mozi supports three types of them, including ping, find_node, and get_peers. For non-DHT requests, there are two types based on whether the network packet length is greater than 99 or not.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_net-1.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_net-1.png" class="kg-image"/></a><br>
For Mozi, Different requests have different processing logic, see below<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_query.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_query.png" class="kg-image"/></a></p>
<ul>
<li>Number 2: ping, DHT request, reply to pong directly according to standard DHT process.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_ping.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_ping.png" class="kg-image"/></a></li>
<li>Number 3: find_node, DHT request.</li>
<li>Number 4: get_peers, DHT request.<br>
Mozi combines <code>find_node</code> and <code>get_peers</code> into one. If the request comes from the Mozi node, there is a certain probability to send its Config content to the other party; if the request comes from a non-Mozi node, it is processed according to the standard DHT process。<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_getnode.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_getnode.png" class="kg-image"/></a></li>
</ul>
<pre><code>raw data, first 128 bytes:
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&gt;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&quot;.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&lt;íá|
00000080  a1 c8 56 a3 cf 28 6b fa 14 06 1a 3e 3b 01 a0 e3  |¡ÈV£Ï(kú...&gt;;. ã|

The encrypted Config is located after &quot;5:nodes624:&quot;, using xor key (4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E), the content after decryption:

raw data:
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&gt;i|
00000020  35 3a 6e 6f 64 65 73 36 32 34 3a 				   |5:nodes624:

configuration:
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&amp;pu=http%3a%2f|

</code></pre>
<ul>
<li>Number 5: <code>announce_peer</code> not supported<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_ann.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_ann.png" class="kg-image"/></a></li>
<li>Number 6: Non-DHT request. The data packet length is less than 99 bytes. When the node receives this request, it will send its config content to the requester.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_6proc.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_6proc.png" class="kg-image"/></a></li>
<li>Number 7: Non-DHT request, the data packet length is greater than 99 bytes. When the node receives this request, it indicates that the received data is an encrypted Config file. For the execution process, refer to the previous section.<br>
<a href="__GHOST_URL__/content/images/2019/12/mozi_payload.png"><img src="__GHOST_URL__/content/images/2019/12/mozi_payload.png" class="kg-image"/></a></li>
</ul>
<h2 id="suggestions">Suggestions</h2>
<p>We recommend that users update the patch in a timely manner, and determine whether they are infected by looking up the process and file name, and HTTP, DHT network connection characteristics created by Mozi Botnet.</p>
<h2 id="contactus">Contact us</h2>
<p>Readers are always welcomed to reach us on <a href="https://twitter.com/360Netlab">twitter</a>, WeChat 360Netlab or email to netlab at 360 dot cn.</p>
<h2 id="ioclist">IoC list</h2>
<p>Sample MD5:</p>
<pre><code>eda730498b3d0a97066807a2d98909f3
849b165f28ae8b1cebe0c7430f44aff3
</code></pre>
<!--kg-card-end: markdown-->
Overview


On September 03, 2019, a suspicious file was tagged by our new threat monitoring system and a quick checking on VT shows most engines flagged it as Gafgyt. The sample does reuse part of the Gafgyt code, but it is not really Gafgyt.


The sample represents a brand new P2P botnet implemented based on the DHT protocol, the last botnet which uses DHT is the Hajime, and we call it Mozi according to the characteristics of its propagation sample file name Mozi.m,Mozi.a.


Mozi Botnet relies on the DHT protocol to build a P2P network, and uses ECDSA384 and the xor algorithm to ensure the integrity and security of its components and P2P network. The sample spreads via Telnet with weak passwords and some known exploits (see the list below). In terms of functions, the execution of the instructions of each node in the Mozi botnet is driven by a Payload called Config issued by the Botnet Master. The main instructions include:


 * DDoS attack
 * Collecting Bot Information
 * Execute the payload of the specified URL
 * Update the sample from the specified URL
 * Execute system or custom commands


The overall network structure is shown in the following figure:





Sample Spread


Mozi infects new devices through weak telnet passwords and exploits.The infection process is as follows:


 * The current Bot node randomly uses a local port to start the http service to provide sample downloads or receives the sample download address in the Config file issued by the Botnet Master.Provides 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 use a vulnerability to exploit the target, and then obtain a sample file from the sample download address provided by the current Bot node.
 * Run the Mozi Bot sample on the infected target device, join the Mozi P2P network to become the new Mozi Bot node and continue to infect other new devices.


The vulnerabilities used by Mozi Botnet are shown in the following table:





Vulnerability
Affected Aevice




Eir D1000 Wireless Router RCI
Eir D1000 Router


Vacron NVR RCE
Vacron NVR devices


CVE-2014-8361
Devices using the Realtek SDK


Netgear cig-bin Command Injection
Netgear R7000 and R6400


Netgear setup.cgi unauthenticated RCE
DGN1000 Netgear routers


JAWS Webserver unauthenticated shell command execution
MVPower DVR


CVE-2017-17215
Huawei Router HG532


HNAP SoapAction-Header Command Execution
D-Link Devices


CVE-2018-10561, CVE-2018-10562
GPON Routers


UPnP SOAP TelnetD Command Execution
D-Link Devices


CCTV/DVR Remote Code Execution
CCTV DVR





At present, we do not know the exact scale of the Botnet, we do manage to become a node to join the DHT network and are tracking some baseline numbers, we will share more details probably in another blog later on. And from other data we have collected, we can also see the number of infection has been increasing.The picture below shows the Mozi bot infection based on the log collected by our honeypot.





Sample Reverse Analysis


There are three versions of Mozi Botnet, which can be distinguished by their slightly different telnet propagation methods.



Our analysis is mainly focus on the latest version v2, and this blog will cover the key elements such as propagation method, Config structure and its DHT network.



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 in the first version Mozi(sample md5: 849b165f28ae8b1cebe0c7430f44aff3) used upx packing. But instead of using the common upx magic number to defeat unpacking, it used a novel method, to erase the value of p_filesize & p_blocksize to zero, with that change, researcher need to patch the upx source code then unpacking is possible.



Common Functions


Mozi doesn't have much characteristics in the host behavior level. It reuses Gafgyt's code to implements many common functions, such as single instance, process name modification, and ACL modification.


 * Single instance, by binding local port
   
   
 * Change the process name to sshd or dropbear to confuse the victim
   
   
 * ACL modification, Open up the ports;block SSH, TELNET services to prevent Bot from being re-infected by other malicious actors.
   
   






Perform Specific Tasks


After Mozi establishes the p2p network through the DHT protocol, the config file is synchronized, and the corresponding tasks are started according to the instructions in the config file.In P2P networks, nodes are untrusted, and anyone can fake a Mozi node at a very low cost.In order to ensure that the Mozi network is completely controllable and cannot be stolen by others, Mozi needs to perform signature verification on each synchronized config, and only if it can pass the signature verification can it be accepted and executed by the Mozi node.





Document & Instruction Inspection


Mozi uses the ECDSA384 algorithm to verify the legitimacy of files and instructions. Each sample integrates two xor-encrypted public keys, which are used to sign encrypted and decrypted config files, respectively.


 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 and the flag field controls if 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 field content and executes the corresponding subtasks.The original config file is as follows.



The decryption process is shown in the following figure, where the xor key is 4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E




The decrypted config is as follows.



The supported keywords are as follows, which can be divided into three categories: declaration, control, and subtask.


1：declaration
[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:control
[ver] 	verify 
[sv]	update  Config
[hp] 	DHT id prefix
[dip]   URL or ip:port list which can get Mozi sample
3:subtask
[atk]	DDOS attack
[ud] 	update
[dr] 	exec payload from specific URL 
[rn] 	exec system or customized cmds
[idp] 	report bot info



Bot Function


 * DDOS，[atk]field trigger, reuse Gafgyt attack code, support HTTP, TCP, UDP and other attacks.
   
   Command
   -----------------------------------------
   S    
   T
   U
   KT
   HTTP
   
   

 * Report Bot information,[idp]field trigger, the content reported are Bot ID, IP, PORT, file name (full path), gateway, cpu architecture.
   
   
 * The payload of the specified URL is executed, and the[dr] field is triggered.
   
   
 * Update from the specified URL, the [ud]field is triggered. Close the current node's network connection and related processes, download the new version from the specified URL, save DHT node, ID and other data, and provide them as parameters for the new version.
   
   
 * Execute system or Bot custom command,[rn]field trigger.
   
   * System command
     
     
   * Customize theGETcommand and send the Bot ID to the peer.
     
     
   * Customize theruncommand, execute the command issued by the peer, and return the result.
     
     
   



DHT


Mozi Botnet uses its own extended DHT protocol to build a P2P network. There are two benefits to this. One is to use standard DHT to quickly establish a network, and the other is to use its own extension to hide the valid payload in the vast amount of normal DHT traffic so detection is impossible without proper knowledge. Mozi uses 8 sets of public nodes and the nodes specified in the [nd] field of the Config file as bootstrap nodes, toguide new nodes to join their DHT network.


 * Public 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] Specified in the Config file
   
   


ID Generation


The ID is 20 bytes and consists of the prefix 888888 embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.





Node Recognition


In order to distinguish regular traffic with its own traffic, Mozi uses1:v4:flag(4 bytes)such an identifier to identify whether the traffic is sent by its node. The meaning of the flag byte is as follows.



flag means is as follows


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 randomly generated. 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 0x42

Final 1f71

Enter 0x44 0x42, and get the 0x1f71 same result as in the packet.



Network Request


The network requests received by Mozi nodes can be divided into two categories, DHT requests and non-DHT requests. According to the aforementioned node identification, DHT requests are then again divided into Mozi-DHT requests and non-Mozi-DHT requests. Mozi supports three types of them, including ping, find_node, and get_peers. For non-DHT requests, there are two types based on whether the network packet length is greater than 99 or not.



For Mozi, Different requests have different processing logic, see below




 * Number 2: ping, DHT request, reply to pong directly according to standard DHT process.
   
   
 * Number 3: find_node, DHT request.
 * Number 4: get_peers, DHT request.
   
   Mozi combines find_node and get_peers into one. If the request comes from the Mozi node, there is a certain probability to send its Config content to the other party; if the request comes from a non-Mozi node, it is processed according to the standard DHT process。
   
   


raw data, first 128 bytes:
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ú...>;. ã|

The encrypted Config is located after "5:nodes624:", using xor key (4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E), the content after decryption:

raw data:
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:

configuration:
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|




 * Number 5: announce_peer not supported
   
   
 * Number 6: Non-DHT request. The data packet length is less than 99 bytes. When the node receives this request, it will send its config content to the requester.
   
   
 * Number 7: Non-DHT request, the data packet length is greater than 99 bytes. When the node receives this request, it indicates that the received data is an encrypted Config file. For the execution process, refer to the previous section.
   
   



Suggestions


We recommend that users update the patch in a timely manner, and determine whether they are infected by looking up the process and file name, and HTTP, DHT network connection characteristics created by Mozi Botnet.



Contact us


Readers are always welcomed to reach us on twitter, WeChat 360Netlab or email to netlab at 360 dot cn.



IoC list


Sample MD5:


eda730498b3d0a97066807a2d98909f3
849b165f28ae8b1cebe0c7430f44aff3


{"version":"0.3.1","atoms":[],"cards":[["markdown",{"markdown":"## Overview\nOn September 03, 2019, a suspicious file was tagged by our new threat monitoring system and a quick checking on VT shows most engines flagged it as Gafgyt. The sample does reuse part of the Gafgyt code, but it is not really Gafgyt. \n\nThe sample represents a brand new P2P botnet implemented based on the DHT protocol, the last botnet which uses DHT is the Hajime, and we call it Mozi according to the characteristics of its propagation sample file name `Mozi.m`,`Mozi.a`.\n\nMozi Botnet relies on the DHT protocol to build a P2P network, and uses ECDSA384 and the xor algorithm to ensure the integrity and security of its components and P2P network. The sample spreads via Telnet with weak passwords and some known exploits (see the list below). In terms of functions, the execution of the instructions of each node in the Mozi botnet is driven by a Payload called Config issued by the Botnet Master. The main instructions include:\n- DDoS attack\n- Collecting Bot Information\n- Execute the payload of the specified URL\n- Update the sample from the specified URL\n- Execute system or custom commands\n\nThe overall network structure is shown in the following figure:\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_flow-3.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_flow.m.png\" class=\"kg-image\"/></a>\n\n## Sample Spread\n\nMozi infects new devices through weak telnet passwords and exploits.The infection process is as follows:\n- The current Bot node randomly uses a local port to start the http service to provide sample downloads or receives the sample download address in the Config file issued by the Botnet Master.Provides a sample download address for future infected targets.\n- 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 use a vulnerability to exploit the target, and then obtain a sample file from the sample download address provided by the current Bot node.\n- Run the Mozi Bot sample on the infected target device, join the Mozi P2P network to become the new Mozi Bot node and continue to infect other new devices.\n\nThe vulnerabilities used by Mozi Botnet are shown in the following table:\n| Vulnerability | Affected Aevice |\n| ------------- | ---------------- |\n| [Eir D1000 Wireless Router RCI](https://www.exploit-db.com/exploits/40740) | Eir D1000 Router |\n| [Vacron NVR RCE](https://www.exploit-db.com/exploits/6864/) | Vacron NVR devices |\n| [CVE-2014-8361](https://www.exploit-db.com/exploits/37169/) | Devices using the Realtek SDK|\n| [Netgear cig-bin Command Injection](https://www.exploit-db.com/exploits/41598/)| Netgear R7000 and R6400 |\n| [Netgear setup.cgi unauthenticated RCE](https://www.exploit-db.com/exploits/43055) | DGN1000 Netgear routers |\n| [JAWS Webserver unauthenticated shell command execution](https://www.exploit-db.com/exploits/41471/) | MVPower DVR | \n| [CVE-2017-17215](https://www.exploit-db.com/exploits/43414/) | Huawei Router HG532  |\n| [HNAP SoapAction-Header Command Execution](https://www.exploit-db.com/exploits/37171/) | D-Link Devices |\n| [CVE-2018-10561, CVE-2018-10562](https://www.exploit-db.com/exploits/44576/) | GPON Routers |\n| [UPnP SOAP TelnetD Command Execution](https://www.exploit-db.com/exploits/28333/) | D-Link Devices |\n| [CCTV/DVR Remote Code Execution](https://www.exploit-db.com/exploits/39596/) | CCTV DVR |\n\nAt present, we do not know the exact scale of the Botnet, we do manage to become a node to join the DHT network and are tracking some baseline numbers, we will share more details probably in another blog later on. And from other data we have collected, we can also see the number of infection has been increasing.The picture below shows the Mozi bot infection based on the log collected by our honeypot.\n![fssfsadfsdff](__GHOST_URL__/content/images/2019/12/fssfsadfsdff.png)\n\n## Sample Reverse Analysis\nThere are three versions of Mozi Botnet, which can be distinguished by their slightly different telnet propagation methods.\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_versioin.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_versioin.png\" class=\"kg-image\"/></a>\nOur analysis is mainly focus on the latest version v2, and this blog will cover the key elements such as propagation method, Config structure and its DHT network.\n\n### Sample Information\n> MD5:eda730498b3d0a97066807a2d98909f3\n>\n> ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped\n>\n> Packer: NO\n>\n> Library:uclibc\n>\n> Version: v2\n\nIt is worth mentioning that in the first version Mozi(sample md5: `849b165f28ae8b1cebe0c7430f44aff3`) used upx packing. But instead of using the common upx magic number to defeat unpacking, it used a novel method, to erase the value of p_filesize & p_blocksize to zero, with that change, researcher need to patch the upx source code then unpacking is possible.\n\n### Common Functions\n\nMozi doesn't have much characteristics in the host behavior level. It reuses Gafgyt's code to implements many common functions, such as single instance, process name modification, and ACL modification.\n\n- Single instance, by binding local port\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_bind.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_bind.png\" class=\"kg-image\"/></a>\n- Change the process name to sshd or dropbear to confuse the victim\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_setname.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_setname.png\" class=\"kg-image\"/></a>\n- ACL modification, Open up the ports;block SSH, TELNET services to prevent Bot from being re-infected by other malicious actors.\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_iptables.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_iptables.png\" class=\"kg-image\"/></a>\n\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_forb.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_forb.png\" class=\"kg-image\"/></a>\n\n\n### Perform Specific Tasks\n\nAfter Mozi establishes the p2p network through the DHT protocol, the config file is synchronized, and the corresponding tasks are started according to the instructions in the config file.In P2P networks, nodes are untrusted, and anyone can fake a Mozi node at a very low cost.In order to ensure that the Mozi network is completely controllable and cannot be stolen by others, Mozi needs to perform signature verification on each synchronized config, and only if it can pass the signature verification can it be accepted and executed by the Mozi node.\n\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_configproc.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_configproc.png\" class=\"kg-image\"/></a>\n\n#### Document & Instruction Inspection\n\nMozi uses the ECDSA384 algorithm to verify the legitimacy of files and instructions. Each sample integrates two xor-encrypted public keys, which are used to sign encrypted and decrypted config files, respectively.\n\n```\n xor key:4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E\n------------------------------------------------------------------\nxored publickey A \n\t4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F \n\t69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B \n\t38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 A1\t\nafter decryption: \n\t02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21 \n\t27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65 \n\t76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea ef\n-------------------------------------------------------------------\nxored publickey B\n\t4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8 \n\tE9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53 \n\t22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 88\nafter decryption:\n\t02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6 \n\ta7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d \n\t6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 c6\n```\n\n#### Config File\nEach 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 and the flag field controls if 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 field content and executes the corresponding subtasks.The original config file is as follows. \n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_enconfig.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_enconfig.png\" class=\"kg-image\"/></a>\nThe decryption process is shown in the following figure, where the xor key is `4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E`\n\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_xorproc.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_xorproc.png\" class=\"kg-image\"/></a>\nThe decrypted config is as follows. \n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_denconfig.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_denconfig.png\" class=\"kg-image\"/></a>\nThe supported keywords are as follows, which can be divided into three categories: declaration, control, and subtask.\n```\n1：declaration\n[cpu]　　cpu arch or os\n[cpux]  cpu arch or os\n[ss]\tbot role\n[ssx]\tbot role\n[nd] \tnew node info which help to join DHT\n2:control\n[ver] \tverify \n[sv]\tupdate  Config\n[hp] \tDHT id prefix\n[dip]   URL or ip:port list which can get Mozi sample\n3:subtask\n[atk]\tDDOS attack\n[ud] \tupdate\n[dr] \texec payload from specific URL \n[rn] \texec system or customized cmds\n[idp] \treport bot info\n```\n#### Bot Function\n- DDOS，``[atk]``field trigger, reuse Gafgyt attack code, support HTTP, TCP, UDP and other attacks.\n  ```\n  Command\n  -----------------------------------------\n  S    \n  T\n  U\n  KT\n  HTTP\n  ```\n  <a href=\"__GHOST_URL__/content/images/2019/12/mozi_atk.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_atk.png\" class=\"kg-image\"/></a>\n- Report Bot information,``[idp]``field trigger, the content reported are Bot ID, IP, PORT, file name (full path), gateway, cpu architecture.\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_idp.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_idp.png\" class=\"kg-image\"/></a>\n- The payload of the specified URL is executed, and the``[dr]`` field is triggered.\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_dr.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_dr.png\" class=\"kg-image\"/></a>\n- Update from the specified URL, the ``[ud]``field is triggered. Close the current node's network connection and related processes, download the new version from the specified URL, save DHT node, ID and other data, and provide them as parameters for the new version.\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_ud.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_ud.png\" class=\"kg-image\"/></a>\n- Execute system or Bot custom command,``[rn]``field trigger.\n  - System command\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_rnsys.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_rnsys.png\" class=\"kg-image\"/></a>\n  - Customize the`GET`command and send the Bot ID to the peer.\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_rnget.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_rnget.png\" class=\"kg-image\"/></a>\n  - Customize the`run`command, execute the command issued by the peer, and return the result.\n    <a href=\"__GHOST_URL__/content/images/2019/12/mozi_rnrun.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_rnrun.png\" class=\"kg-image\"/></a>\n### DHT\n\nMozi Botnet uses its own extended DHT protocol to build a P2P network. There are two benefits to this. One is to use standard DHT to quickly establish a network, and the other is to use its own extension to hide the valid payload in the vast amount of normal DHT traffic so detection is impossible without proper knowledge. Mozi uses 8 sets of public nodes and the nodes specified in the [nd] field of the Config file as bootstrap nodes, toguide new nodes to join their DHT network.\n\n- Public node, sample embedded\n```\ndht.transmissionbt.com:6881\nrouter.bittorrent.com:6881\nrouter.utorrent.com:6881\nbttracker.debian.org:6881\n212.129.33.59:6881\n82.221.103.244:6881\n130.239.18.159:6881\n87.98.162.88:6881\n```\n- [nd] Specified in the Config file\n<a href=\"__GHOST_URL__/content/images/2019/12/mozi_nd.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_nd.png\" class=\"kg-image\"/></a>\n#### ID Generation\n\nThe ID is 20 bytes and consists of the prefix `888888` embedded in the sample or the prefix specified by the config file [hp], plus a randomly generated string.\n\n\n\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_id.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_id.png\" class=\"kg-image\"/></a>\n\n#### Node Recognition\nIn order to distinguish regular traffic with its own traffic, Mozi uses``1:v4:flag(4 bytes)``such an identifier to identify whether the traffic is sent by its node. The meaning of the flag byte is as follows.\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_node.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_node.png\" class=\"kg-image\"/></a>\nflag means is as follows\n```\nflag(4 bytes)\n----------------------------------------------\noffset:\n\t0  -----random\n\t1  ----- hard-code(0x42) or from [ver]\n    2  -----calc by algorithm\n    3  -----calc by algorithm\n```\nThe first byte is randomly generated. The second byte is hard-coded 0x42 or specified by the [ver] field in the config file.\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_ver.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_ver.png\" class=\"kg-image\"/></a>\nThe 3rd and 4th bytes are obtained by the algorithm.\n```\nver algorithm\n----------------------------------------------\n\tint first,sec;\n\tstring ver=\"\\x31\\x3a\\x76\\x34\\x3a\\x00\\x00\"s;\n\tcout << \"Please input the two number: (0x00-0xff)\" << endl;\n\tcin.unsetf(ios::hex);\n\tcin >> hex >> first >> sec;\n\tver[5] = char(first);\n\tver[6] = char(sec);\n\tuint32_t va = 0;\n\tfor(int i = 0; i < 7; i++)\n\t{\t\n\t\tuint32_t tmp = int(ver[i]);\n\t\ttmp = tmp << 8;\n\t\ttmp ^= va;\n\t\tint rnd = 8;\n\twhile (rnd--)\n\t{\n\t\tif ((tmp & 0xffff) > 0x8000)\n\t\t{\n\t\t\ttmp *= 2;\n\t\t\ttmp ^= 0xffff8005;\n\t\t}\n\t\telse\n\t\t\ttmp *= 2;\n\t}\n\tva = tmp&0xffff;\n\t}\n\tcout  << hex  << \"Final \" <<  va << endl;\n```\n\n>Please input the two number: (0x00-0xff)\n>0x44 0x42                                       \n>Final 1f71            \nEnter 0x44 0x42, and get the `0x1f71` same result as in the packet.\n\n\n#### Network Request\n\nThe network requests received by Mozi nodes can be divided into two categories, DHT requests and non-DHT requests. According to the aforementioned node identification, DHT requests are then again divided into Mozi-DHT requests and non-Mozi-DHT requests. Mozi supports three types of them, including ping, find_node, and get_peers. For non-DHT requests, there are two types based on whether the network packet length is greater than 99 or not. \n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_net-1.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_net-1.png\" class=\"kg-image\"/></a>\nFor Mozi, Different requests have different processing logic, see below\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_query.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_query.png\" class=\"kg-image\"/></a>\n- Number 2: ping, DHT request, reply to pong directly according to standard DHT process.\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_ping.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_ping.png\" class=\"kg-image\"/></a>\n- Number 3: find_node, DHT request.\n- Number 4: get_peers, DHT request.\n  Mozi combines `find_node` and `get_peers` into one. If the request comes from the Mozi node, there is a certain probability to send its Config content to the other party; if the request comes from a non-Mozi node, it is processed according to the standard DHT process。\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_getnode.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_getnode.png\" class=\"kg-image\"/></a>\n```\nraw data, first 128 bytes:\n00000000  64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38  |d1:rd2:id20:8888|\n00000010  38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69  |8888·. .fáq.åM>i|\n00000020  35 3a 6e 6f 64 65 73 36 32 34 3a 15 15 29 d2 f3  |5:nodes624:..)Òó|\n00000030  a3 f7 0c fe df 1a 5d bd 3f 32 46 76 5e 62 b7 b8  |£÷.þß.]½?2Fv^b·¸|\n00000040  f0 94 78 a2 c4 37 5b 8e 2c 00 0b 20 12 07 e7 f4  |ð.x¢Ä7[.,.. ..çô|\n00000050  bc dc 19 a2 83 2e 67 fb 7a 5e 50 22 07 75 e8 ef  |¼Ü.¢..gûz^P\".uèï|\n00000060  f9 93 4a e9 91 75 36 e4 76 57 4b 7c 51 7c ff f5  |ù.Jé.u6ävWK|Q|ÿõ|\n00000070  f5 c4 57 f9 dc 62 35 b4 6a 5d 18 6b 54 3c ed e1  |õÄWùÜb5´j].kT<íá|\n00000080  a1 c8 56 a3 cf 28 6b fa 14 06 1a 3e 3b 01 a0 e3  |¡ÈV£Ï(kú...>;. ã|\n\nThe encrypted Config is located after \"5:nodes624:\", using xor key (4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E), the content after decryption:\n\nraw data:\n00000000  64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38  |d1:rd2:id20:8888|\n00000010  38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69  |8888·. .fáq.åM>i|\n00000020  35 3a 6e 6f 64 65 73 36 32 34 3a \t\t\t\t   |5:nodes624:\n\nconfiguration:\n00000000  5b 73 73 5d 73 6b 5b 2f 73 73 5d 5b 68 70 5d 38  |[ss]sk[/ss][hp]8|\n00000010  38 38 38 38 38 38 38 5b 2f 68 70 5d 5b 63 6f 75  |8888888[/hp][cou|\n00000020  6e 74 5d 68 74 74 70 3a 2f 2f 69 61 2e 35 31 2e  |nt]http://ia.51.|\n00000030  6c 61 2f 67 6f 31 3f 69 64 3d 32 30 31 39 38 35  |la/go1?id=201985|\n00000040  32 37 26 70 75 3d 68 74 74 70 25 33 61 25 32 66  |27&pu=http%3a%2f|\n\n```\n\n- Number 5: `announce_peer` not supported\n   <a href=\"__GHOST_URL__/content/images/2019/12/mozi_ann.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_ann.png\" class=\"kg-image\"/></a>\n- Number 6: Non-DHT request. The data packet length is less than 99 bytes. When the node receives this request, it will send its config content to the requester.\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_6proc.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_6proc.png\" class=\"kg-image\"/></a>\n- Number 7: Non-DHT request, the data packet length is greater than 99 bytes. When the node receives this request, it indicates that the received data is an encrypted Config file. For the execution process, refer to the previous section.\n <a href=\"__GHOST_URL__/content/images/2019/12/mozi_payload.png\"><img src=\"__GHOST_URL__/content/images/2019/12/mozi_payload.png\" class=\"kg-image\"/></a>\n## Suggestions\n\nWe recommend that users update the patch in a timely manner, and determine whether they are infected by looking up the process and file name, and HTTP, DHT network connection characteristics created by Mozi Botnet.\n\n## Contact us\n\nReaders are always welcomed to reach us on [twitter](https://twitter.com/360Netlab), WeChat 360Netlab or email to netlab at 360 dot cn.\n\n## IoC list\n\nSample MD5:\n\n```\neda730498b3d0a97066807a2d98909f3\n849b165f28ae8b1cebe0c7430f44aff3\n```\n\n\n\n"}]],"markups":[],"sections":[[10,0],[1,"p",[]]],"ghostVersion":"3.0"}