Http 81 Botnet: the Comparison against MIRAI and New Findings
<!--kg-card-begin: markdown--><h1 id="overview">Overview</h1>
<p>In <a href="__GHOST_URL__/a-new-threat-an-iot-botnet-scanning-internet-on-port-81-en/">our previous blog</a>, we introduced a new IoT botnet spreading over http 81. We will name it in this blog the <code>http81</code> IoT botnet, while some anti-virus software name it Persirai, and some other name it after MIRAI.</p>
<p>In this blog, we will compare <code>http81</code> against mirai at binary level:</p>
<div>
<pre>
 1. Similarities to Mirai
   1.1 Same IP Blacklist in Scanning Module
   1.2 Same Functions as a Fundamental Library
 2. Differences against Mirai
   2.1 C2 Presence in the Source Code
   2.2 Infection method
   2.3 C2 Communication Protocol
   2.4 Attack vector
</pre>
<div>
<p>With the distinguish differences in infection, C2 communication and attacking vector,  the <code>http81</code> should be treated as a different botnet from mirai.</p>
<p>This blog also introduce several new findings:</p>
<ul>
<li>another inactive infection method on SSDP/UPnP</li>
<li>the SSDP/UPnP infection payload is reused by <code>00 06</code> UDP-Flood</li>
<li>the C2 domains are now silent by resolving to internal network address</li>
</ul>
<p>****PS：*<em>If not noted，MIRAI analysis will be based on the leaked source code from GitHub；the HTTP 81 botnet analysis will be based on the reverse engineering result of sample with a md5-hash 9584B6AEC418A2AF4EFAC24867A8C7EC .</em></p>
<h1 id="similaritiestomirai">Similarities to Mirai</h1>
<h3 id="sameipblacklistinscanningmodule">Same IP Blacklist in Scanning Module</h3>
<p>As we all know，<code>mirai</code> were spreading very fast under the support of SYN port detection. Nowadays this mechanisms is borrowed by several different botnets, including this <code>http81</code>.</p>
<p><code>Mirai</code> introduced an IP blacklist code snippet when choosing target scanning IP address to avoid touching some specific CIDR(SOURCE: scanner.c). As shown in the following figure.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/1_SYN_SCAN_BLACK_IP_ADDRESS.png" alt="" loading="lazy"></p>
<p>Exactly the same code snippet exists in <code>http81</code> botnet in function sub_A7C4. Following figure shows the same code lines in the red boxes. In fact, the whole while cycle is the same.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/2_SYN_SCANN_BLACK_LIST.jpg" alt="" loading="lazy"></p>
<h3 id="samefunctionsasafundamentallibrary">Same Functions as a Fundamental Library</h3>
<p>When compared at assembly instruction level, it is clear that a small number of functions are highly consistent between two botnets.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/table_Function_Name_From_MIRAI-6.jpg" alt="" loading="lazy"></p>
<p>These listed functions looks very fundamental, as from the function name. For example, the function rand_next is called in the IP blacklist snippet mentioned above.</p>
<h1 id="differencesagainstmirai">Differences against Mirai</h1>
<h3 id="c2presenceinthesourcecode">C2 Presence in the Source Code</h3>
<p>In the MIRAI source code, an Xor encryption algorithm is used to protect the original C2 domain name, to bury it into a ciphered text deep in the source code. Clues are showed in following snapshot, from the <code>table_init</code> function of the <code>table.c</code> file.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/3_C2_Config_Of_MIRAI.png" alt="" loading="lazy"></p>
<p>But in <code>http81</code>, the C2 is store in plain text. A bared C2 can be seen from the figure below.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/4_C2_Config_Of_Persirai.png" alt="" loading="lazy"></p>
<h3 id="infectionmethod">Infection method</h3>
<p>The source leaked <code>mirai</code> was spreading over <code>telnet 23/2323</code>. Some mirai variants works on different ports such as 7547/6789/3777, but no evidence of http 81 port exists. More details can be found in <a href="http://data.netlab.360.com/mirai-scanner/">Mirai Scanner</a>.</p>
<p>This http 81 port injection is a unique feature of the <code>http 81</code> botnet, with more details listed in <a href="__GHOST_URL__/a-new-threat-an-iot-botnet-scanning-internet-on-port-81-en/">our previous blog</a>.</p>
<h3 id="c2communicationprotocol">C2 Communication Protocol</h3>
<p>In the MIRAI source code, attack_parse function(Source: attack.c) records the details of its protocol.</p>
<p><code>http 81</code> botnet adopts a completely new protocol, listed in following table. In this list, <code>00 06</code> and <code>00 08</code> are code for UDP flood.</p>
<p><img src="__GHOST_URL__/content/images/2017/05/table_command_parse_Persirai_en.jpg" alt="Persirai Protocol" loading="lazy"></p>
<h3 id="attackvector">Attack vector</h3>
<p><code>MIRAI</code> owns 10 DDoS attack vectors including a unique GRE/VSE attacks, which listed in the <code>attack.h</code> file.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/5_DDOS_attack_Vector_In_MIRAI.jpg" alt="" loading="lazy"></p>
<p>But <code>http81</code> owns just two DDoS attack vectors. Both are UDP flood with protocol numbers <code>00 06</code> and <code>00 08</code>, mentioned in above.</p>
<h1 id="newfindings">New Findings</h1>
<h3 id="anotherinactiveinfectionmethodonssdpupnp">Another Inactive Infection Method on SSDP/UPnP</h3>
<p>Although <code>http81</code> use a unique http 81 injection, there is another infection method with instruction code <code>00 04 02</code>, which seems inactive.</p>
<p>Once activated, large number of UDP requests will be send in a short time to randomized destination IP on port 1900, with following packet contents.</p>
<div>
<pre>
M-SEARCH * HTTP/1.1
HOST:239.255.255.250:1900
ST:upnp:rootdevice
MAN:"ssdp:discover"
MX:3
</pre>
<div>
<p>This is exactly the first request packet of the SSDP protocol (<em>Function address: <code>0x0000A918</code></em>). If one of them hits a SSDP device, the bot will enter the SSDP interactive process to get more device information, and try to use the <code>EXPLOIT</code> (<em>CVE-2014-8361, &quot;Realtek SDK Miniigd <strong>UPnP</strong> SOAP Command Execution&quot;</em> ) when the keyword (<code>:52869/picsdesc.xml</code>) appears(<em>Function address: <code>0x0000A458</code></em>).</p>
<p>Sometimes, when the bot can not directly exploit the target device on the WAN side, an function containing &quot;AddPortMapping&quot; will be tried (<em>Function address: <code>0x0000AE20</code></em>) to establish an port tunnel, through which another shot of exploit will be tried.</p>
<h3 id="thessdpupnpinfectionpayloadisreusedby0006udpflood">The SSDP/UPnP Infection Payload is Reused by 00 06 UDP-Flood</h3>
<p>The <code>http81</code> botnet owns two DDoS attack vector, <code>00 06</code> and <code>00 08</code>. Payload of the former <code>00 06</code> is exactly the first request packet of SSDP protocol.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/00_06_udp_flood.jpg" alt="" loading="lazy"></p>
<p>Payload of the later <code>00 08</code> is different.</p>
<p><img src="__GHOST_URL__/content/images/2017/04/00_08_udp_flood.jpg" alt="" loading="lazy"></p>
<h3 id="thec2domainsarenowsilentbyresolvingtointernalnetworkaddress">The C2 Domains Are Now Silent by Resolving to Internal Network Address</h3>
<p><code>ntp.gtpnet.ir/load.gtpnet.ir</code> are now silent by resolving to internal network address since 2017-04-26 02:13:49(GMT+8), so the bot-master will not send command to the botnet at this moment. But it doesn't mean bot-master has lost control to the botnet.</p>
<ul>
<li>ntp.gtpnet.ir	A	10.40.40.40</li>
<li>load.gtpnet.ir	A	10.50.50.50</li>
</ul>
<p>Two different explanations we listed here:</p>
<ol>
<li>The manager found the botnet exposed and cut off the connection.</li>
<li>The manager is sharpening the botnet, but interfered by the heavy load from the bots. So the manager temporary offline the domain for a easier development.</li>
</ol>
<h1 id="review">Review</h1>
<p>We will treat <code>http81</code> a new new family different from mirai.</p>
<!--kg-card-end: markdown-->
Overview


In our previous blog, we introduced a new IoT botnet spreading over http 81. We will name it in this blog the http81 IoT botnet, while some anti-virus software name it Persirai, and some other name it after MIRAI.


In this blog, we will compare http81 against mirai at binary level:




 1. Similarities to Mirai
   1.1 Same IP Blacklist in Scanning Module
   1.2 Same Functions as a Fundamental Library
 2. Differences against Mirai
   2.1 C2 Presence in the Source Code
   2.2 Infection method
   2.3 C2 Communication Protocol
   2.4 Attack vector




With the distinguish differences in infection, C2 communication and attacking vector, the http81 should be treated as a different botnet from mirai.


This blog also introduce several new findings:


 * another inactive infection method on SSDP/UPnP
 * the SSDP/UPnP infection payload is reused by 00 06 UDP-Flood
 * the C2 domains are now silent by resolving to internal network address


****PS：*If not noted，MIRAI analysis will be based on the leaked source code from GitHub；the HTTP 81 botnet analysis will be based on the reverse engineering result of sample with a md5-hash 9584B6AEC418A2AF4EFAC24867A8C7EC .



Similarities to Mirai



Same IP Blacklist in Scanning Module


As we all know，mirai were spreading very fast under the support of SYN port detection. Nowadays this mechanisms is borrowed by several different botnets, including this http81.


Mirai introduced an IP blacklist code snippet when choosing target scanning IP address to avoid touching some specific CIDR(SOURCE: scanner.c). As shown in the following figure.





Exactly the same code snippet exists in http81 botnet in function sub_A7C4. Following figure shows the same code lines in the red boxes. In fact, the whole while cycle is the same.






Same Functions as a Fundamental Library


When compared at assembly instruction level, it is clear that a small number of functions are highly consistent between two botnets.





These listed functions looks very fundamental, as from the function name. For example, the function rand_next is called in the IP blacklist snippet mentioned above.



Differences against Mirai



C2 Presence in the Source Code


In the MIRAI source code, an Xor encryption algorithm is used to protect the original C2 domain name, to bury it into a ciphered text deep in the source code. Clues are showed in following snapshot, from the table_init function of the table.c file.





But in http81, the C2 is store in plain text. A bared C2 can be seen from the figure below.






Infection method


The source leaked mirai was spreading over telnet 23/2323. Some mirai variants works on different ports such as 7547/6789/3777, but no evidence of http 81 port exists. More details can be found in Mirai Scanner.


This http 81 port injection is a unique feature of the http 81 botnet, with more details listed in our previous blog.



C2 Communication Protocol


In the MIRAI source code, attack_parse function(Source: attack.c) records the details of its protocol.


http 81 botnet adopts a completely new protocol, listed in following table. In this list, 00 06 and 00 08 are code for UDP flood.






Attack vector


MIRAI owns 10 DDoS attack vectors including a unique GRE/VSE attacks, which listed in the attack.h file.





But http81 owns just two DDoS attack vectors. Both are UDP flood with protocol numbers 00 06 and 00 08, mentioned in above.



New Findings



Another Inactive Infection Method on SSDP/UPnP


Although http81 use a unique http 81 injection, there is another infection method with instruction code 00 04 02, which seems inactive.


Once activated, large number of UDP requests will be send in a short time to randomized destination IP on port 1900, with following packet contents.




M-SEARCH * HTTP/1.1
HOST:239.255.255.250:1900
ST:upnp:rootdevice
MAN:"ssdp:discover"
MX:3




This is exactly the first request packet of the SSDP protocol (Function address: 0x0000A918). If one of them hits a SSDP device, the bot will enter the SSDP interactive process to get more device information, and try to use the EXPLOIT (CVE-2014-8361, "Realtek SDK Miniigd UPnP SOAP Command Execution" ) when the keyword (:52869/picsdesc.xml) appears(Function address: 0x0000A458).


Sometimes, when the bot can not directly exploit the target device on the WAN side, an function containing "AddPortMapping" will be tried (Function address: 0x0000AE20) to establish an port tunnel, through which another shot of exploit will be tried.



The SSDP/UPnP Infection Payload is Reused by 00 06 UDP-Flood


The http81 botnet owns two DDoS attack vector, 00 06 and 00 08. Payload of the former 00 06 is exactly the first request packet of SSDP protocol.





Payload of the later 00 08 is different.






The C2 Domains Are Now Silent by Resolving to Internal Network Address


ntp.gtpnet.ir/load.gtpnet.ir are now silent by resolving to internal network address since 2017-04-26 02:13:49(GMT+8), so the bot-master will not send command to the botnet at this moment. But it doesn't mean bot-master has lost control to the botnet.


 * ntp.gtpnet.ir A 10.40.40.40
 * load.gtpnet.ir A 10.50.50.50


Two different explanations we listed here:


 1. The manager found the botnet exposed and cut off the connection.
 2. The manager is sharpening the botnet, but interfered by the heavy load from the bots. So the manager temporary offline the domain for a easier development.



Review


We will treat http81 a new new family different from mirai.

{"version":"0.3.1","markups":[],"atoms":[],"cards":[["markdown",{"cardName":"card-markdown","markdown":"#Overview\n\nIn [our previous blog](__GHOST_URL__/a-new-threat-an-iot-botnet-scanning-internet-on-port-81-en/), we introduced a new IoT botnet spreading over http 81. We will name it in this blog the `http81` IoT botnet, while some anti-virus software name it Persirai, and some other name it after MIRAI.\n\nIn this blog, we will compare `http81` against mirai at binary level:\n\n<div>\n<pre>\n 1. Similarities to Mirai\n   1.1 Same IP Blacklist in Scanning Module\n   1.2 Same Functions as a Fundamental Library\n 2. Differences against Mirai\n   2.1 C2 Presence in the Source Code\n   2.2 Infection method\n   2.3 C2 Communication Protocol\n   2.4 Attack vector\n</pre>\n<div>\n\nWith the distinguish differences in infection, C2 communication and attacking vector,  the `http81` should be treated as a different botnet from mirai.\n\nThis blog also introduce several new findings:\n\n * another inactive infection method on SSDP/UPnP\n * the SSDP/UPnP infection payload is reused by `00 06` UDP-Flood\n * the C2 domains are now silent by resolving to internal network address\n\n\n\n*\\***PS：**If not noted，MIRAI analysis will be based on the leaked source code from GitHub；the HTTP 81 botnet analysis will be based on the reverse engineering result of sample with a md5-hash 9584B6AEC418A2AF4EFAC24867A8C7EC .*\n\n# Similarities to Mirai\n###  Same IP Blacklist in Scanning Module\n\nAs we all know，`mirai` were spreading very fast under the support of SYN port detection. Nowadays this mechanisms is borrowed by several different botnets, including this `http81`.\n\n`Mirai` introduced an IP blacklist code snippet when choosing target scanning IP address to avoid touching some specific CIDR(SOURCE: scanner.c). As shown in the following figure.\n\n![](__GHOST_URL__/content/images/2017/04/1_SYN_SCAN_BLACK_IP_ADDRESS.png)\n\nExactly the same code snippet exists in `http81` botnet in function sub_A7C4. Following figure shows the same code lines in the red boxes. In fact, the whole while cycle is the same.\n\n![](__GHOST_URL__/content/images/2017/04/2_SYN_SCANN_BLACK_LIST.jpg)\n \n\n### Same Functions as a Fundamental Library\n\nWhen compared at assembly instruction level, it is clear that a small number of functions are highly consistent between two botnets.\n\n![](__GHOST_URL__/content/images/2017/04/table_Function_Name_From_MIRAI-6.jpg)\n\nThese listed functions looks very fundamental, as from the function name. For example, the function rand_next is called in the IP blacklist snippet mentioned above.\n\n# Differences against Mirai\n### C2 Presence in the Source Code\n\nIn the MIRAI source code, an Xor encryption algorithm is used to protect the original C2 domain name, to bury it into a ciphered text deep in the source code. Clues are showed in following snapshot, from the `table_init` function of the `table.c` file.\n\n![](__GHOST_URL__/content/images/2017/04/3_C2_Config_Of_MIRAI.png)\n\nBut in `http81`, the C2 is store in plain text. A bared C2 can be seen from the figure below.\n\n![](__GHOST_URL__/content/images/2017/04/4_C2_Config_Of_Persirai.png)\n\n### Infection method\n\nThe source leaked `mirai` was spreading over `telnet 23/2323`. Some mirai variants works on different ports such as 7547/6789/3777, but no evidence of http 81 port exists. More details can be found in [Mirai Scanner]( http://data.netlab.360.com/mirai-scanner/).\n\nThis http 81 port injection is a unique feature of the `http 81` botnet, with more details listed in [our previous blog](__GHOST_URL__/a-new-threat-an-iot-botnet-scanning-internet-on-port-81-en/).\n\n### C2 Communication Protocol\n\nIn the MIRAI source code, attack_parse function(Source: attack.c) records the details of its protocol.\n\n`http 81` botnet adopts a completely new protocol, listed in following table. In this list, `00 06` and `00 08` are code for UDP flood.\n\n![Persirai Protocol](__GHOST_URL__/content/images/2017/05/table_command_parse_Persirai_en.jpg)\n\n### Attack vector\n\n`MIRAI` owns 10 DDoS attack vectors including a unique GRE/VSE attacks, which listed in the `attack.h` file.\n\n![](__GHOST_URL__/content/images/2017/04/5_DDOS_attack_Vector_In_MIRAI.jpg)\n\nBut `http81` owns just two DDoS attack vectors. Both are UDP flood with protocol numbers `00 06` and `00 08`, mentioned in above.\n\n# New Findings\n\n### Another Inactive Infection Method on SSDP/UPnP\n\nAlthough `http81` use a unique http 81 injection, there is another infection method with instruction code `00 04 02`, which seems inactive.\n\nOnce activated, large number of UDP requests will be send in a short time to randomized destination IP on port 1900, with following packet contents.\n\n<div>\n<pre>\nM-SEARCH * HTTP/1.1\nHOST:239.255.255.250:1900\nST:upnp:rootdevice\nMAN:\"ssdp:discover\"\nMX:3\n</pre>\n<div>\n\nThis is exactly the first request packet of the SSDP protocol (*Function address: `0x0000A918`*). If one of them hits a SSDP device, the bot will enter the SSDP interactive process to get more device information, and try to use the `EXPLOIT` (*CVE-2014-8361, \"Realtek SDK Miniigd **UPnP** SOAP Command Execution\"* ) when the keyword (`:52869/picsdesc.xml`) appears(*Function address: `0x0000A458`*).\n\nSometimes, when the bot can not directly exploit the target device on the WAN side, an function containing \"AddPortMapping\" will be tried (*Function address: `0x0000AE20`*) to establish an port tunnel, through which another shot of exploit will be tried.\n\n### The SSDP/UPnP Infection Payload is Reused by 00 06 UDP-Flood\n\nThe `http81` botnet owns two DDoS attack vector, `00 06` and `00 08`. Payload of the former `00 06` is exactly the first request packet of SSDP protocol.\n\n![](__GHOST_URL__/content/images/2017/04/00_06_udp_flood.jpg)\n\nPayload of the later `00 08` is different.\n\n![](__GHOST_URL__/content/images/2017/04/00_08_udp_flood.jpg)\n\n\n###The C2 Domains Are Now Silent by Resolving to Internal Network Address\n`ntp.gtpnet.ir/load.gtpnet.ir` are now silent by resolving to internal network address since 2017-04-26 02:13:49(GMT+8), so the bot-master will not send command to the botnet at this moment. But it doesn't mean bot-master has lost control to the botnet.\n\n\n * ntp.gtpnet.ir\tA\t10.40.40.40\n * load.gtpnet.ir\tA\t10.50.50.50\n\n\nTwo different explanations we listed here:\n\n1.\tThe manager found the botnet exposed and cut off the connection.\n2.\tThe manager is sharpening the botnet, but interfered by the heavy load from the bots. So the manager temporary offline the domain for a easier development.\n\n# Review\n\nWe will treat `http81` a new new family different from mirai."}]],"sections":[[10,0]],"ghostVersion":"3.0"}