HNS Botnet Recent Activities
<!--kg-card-begin: markdown--><p>Author: Rootkiter, yegenshen</p>
<p>HNS is an IoT botnet (Hide and Seek) originally discovered by BitDefender in January this year. In that <a href="https://labs.bitdefender.com/2018/01/new-hide-n-seek-iot-botnet-using-custom-built-peer-to-peer-communication-spotted-in-the-wild/">report</a>, the researchers pointed out that HNS used CVE-2016-10401, and other vulnerabilities to propagate malicious code and stole user information. The HNS communicates through the P2P mechanism, which is the second IoT botnet that we know uses P2P communication after Hajime.</p>
<p>P2P-like botnets are hard to take down, and the HNS botnet has been continuously updated over the past few months, some major updates we see:</p>
<ul>
<li>Added exploits for AVTECH devices (webcam, webcam), CISCO Linksys router, JAWS/1.0 web server, Apache CouchDB, OrientDB; with the two devices mentioned in the original report, HNS currently supports 7 exploiting methods all together</li>
<li>Hard-coded P2P node addresses have been increased to 171;</li>
<li>In addition, we observed that the HNS botnet adds a cpuminer mining program, it is not functioning properly yet.</li>
<li>In particular, with the added support of OrientDB and CouchDB database servers, HNS is no longer just an IoT botnet, but a cross-platform botnet now.</li>
</ul>
<h4 id="malwaresamples">Malware Samples</h4>
<p>We analyzed following samples:</p>
<pre><code>c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner
</code></pre>
<h4 id="networkscanningandexploits">Network Scanning and Exploits</h4>
<p>HNS botnet looks for potential victims by initiating a network scanning. In this scanning, HNS borrows code from mirai botnet, and shares the same characters.</p>
<p>The scanning target ports include fixed TCP port 80/8080/2480/5984/23 and other random ports.</p>
<p><img src="__GHOST_URL__/content/images/2018/07/scanning-ports.png" alt="" loading="lazy"></p>
<p>These ports and their corresponding well known services are:</p>
<pre><code>23    Telnet
80    HTTP Web Service
2480  OrientDB
5984  CouchDB
8080  HTTP Web Service
Random-Port   NA
</code></pre>
<p>HNS will try to implant itself on these ports, utilizing the following exploits. In these exploits, 1 and 2 are listed in bitdefender original report. The other 5 are newly integrated.</p>
<ol>
<li><a href="https://sekurak.pl/tp-link-httptftp-backdoor/">TPLink-Routers RCE</a></li>
<li><a href="https://www.exploit-db.com/exploits/43055/">Netgear RCE</a></li>
<li>new: <a href="https://www.exploit-db.com/exploits/40500/">AVTECH RCE</a></li>
<li>new: <a href="https://vuldb.com/?id.12362">CISCO Linksys Router RCE</a></li>
<li>new: <a href="https://www.pentestpartners.com/security-blog/pwning-cctv-cameras/">JAW/1.0 RCE</a></li>
<li>new: <a href="https://www.exploit-db.com/exploits/42965/">OrientDB RCE</a></li>
<li>new: <a href="https://www.exploit-db.com/exploits/44913/">CouchDB RCE</a></li>
</ol>
<h4 id="171hardcodedp2ppeer">171 Hard-coded P2P peer</h4>
<p>HNS node contacts to other P2P peers with the following 3 methods, in which, 2 and 3 are listed in bitdefender original report.</p>
<ol>
<li>From a hard-coded built-in list of 171 peer addresses</li>
<li>From the command-line args</li>
<li>From the other P2P peers</li>
</ol>
<p>These 171 peers will interact during the check-in and following interaction process</p>
<h6 id="thecheckinprocess">The Check-in Process</h6>
<p>When started with no command-line args, HNS node will send lots of UPD check-in packets. IP addresses of these packets are randomized, while some others are set based on the build-in list. Part of the list is shown as follows, with a full list can be seen in the IoC section.</p>
<p><img src="__GHOST_URL__/content/images/2018/07/hard-coded-peer.png" alt="" loading="lazy"></p>
<h6 id="theinteractionprocess">The Interaction Process</h6>
<p>HNS has the following characteristics when doing P2P interaction between its nodes:</p>
<ul>
<li>The check-in packet is a UDP packet with random length and content. So no significant feature here. The stands out is in the second packet from the upstream nodes, which has a length of 2 and the first byte is the uppercase letter ‘O’. In addition, the second byte of the return packet is actually a checksum value calculated from the request packet, so as can also be used to ID HNS communications. The detailed verification algorithm is shown as below.</li>
<li>After joining into the P2P network, HNS needs to perform address synchronization constantly to ensure nodes connections. This synchronous operation has strong network characteristics. First, the downstream node sends a request packet with the length 1 with content &quot;~&quot; to the upstream node, and then the upstream node replies with a packet of length 8 with the initial letter &quot;^&quot;.</li>
<li>HNS nodes interact frequently and have lots of data exchange. The request packet length is 69 with initial letter &quot;y&quot;, and the reply packet has a length of 261 with initial letter uppercase &quot;Y&quot;.</li>
</ul>
<p>The algorithm for service repond packets, based on python 2.7</p>
<p>When sending the following request packet:</p>
<pre><code>data_pointer = &quot;5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b&quot;.replace(&quot;&quot;,&quot;&quot;).decode('hex')
</code></pre>
<p>The expected response packet from the upstream node would be:</p>
<pre><code>ack=&quot;4f b6&quot;.replace(&quot; &quot;,&quot;&quot;).decode('hex')
</code></pre>
<p>Where chr(0x4f) is fixed and chr(0xb6) is calculated as follows:</p>
<pre><code>def calc_crc(data_pointer):
    data_len_1 = len(data_pointer)-1
    tmp = 88
    for i in range(0,data_len_1):
        tmp += ord(data_pointer[i])
        tmp = tmp &amp;0xff
    tmp2 = tmp^0x3d
    print hex(tmp2),hex(ord(data_pointer[data_len_1]))
    if(tmp2 == ord(data_pointer[data_len_1])):
        return (2*tmp2&amp;0xfe)
    return -1;
</code></pre>
<h4 id="contactus">Contact Us</h4>
<p>If readers have new discoveries, feel free to contact us on <a href="https://twitter.com/360netlab">twitter</a>.</p>
<h4 id="ioc">IoC</h4>
<p>Malware Sample md5</p>
<pre><code>c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner
</code></pre>
<p>All 171 hard coded P2P peer address list is <a href="__GHOST_URL__/file/hns_hardcoded_peer_list.txt">here</a>.</p>
<!--kg-card-end: markdown-->
Author: Rootkiter, yegenshen


HNS is an IoT botnet (Hide and Seek) originally discovered by BitDefender in January this year. In that report, the researchers pointed out that HNS used CVE-2016-10401, and other vulnerabilities to propagate malicious code and stole user information. The HNS communicates through the P2P mechanism, which is the second IoT botnet that we know uses P2P communication after Hajime.


P2P-like botnets are hard to take down, and the HNS botnet has been continuously updated over the past few months, some major updates we see:


 * Added exploits for AVTECH devices (webcam, webcam), CISCO Linksys router, JAWS/1.0 web server, Apache CouchDB, OrientDB; with the two devices mentioned in the original report, HNS currently supports 7 exploiting methods all together
 * Hard-coded P2P node addresses have been increased to 171;
 * In addition, we observed that the HNS botnet adds a cpuminer mining program, it is not functioning properly yet.
 * In particular, with the added support of OrientDB and CouchDB database servers, HNS is no longer just an IoT botnet, but a cross-platform botnet now.


Malware Samples


We analyzed following samples:


c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner



Network Scanning and Exploits


HNS botnet looks for potential victims by initiating a network scanning. In this scanning, HNS borrows code from mirai botnet, and shares the same characters.


The scanning target ports include fixed TCP port 80/8080/2480/5984/23 and other random ports.





These ports and their corresponding well known services are:


23    Telnet
80    HTTP Web Service
2480  OrientDB
5984  CouchDB
8080  HTTP Web Service
Random-Port   NA



HNS will try to implant itself on these ports, utilizing the following exploits. In these exploits, 1 and 2 are listed in bitdefender original report. The other 5 are newly integrated.


 1. TPLink-Routers RCE
 2. Netgear RCE
 3. new: AVTECH RCE
 4. new: CISCO Linksys Router RCE
 5. new: JAW/1.0 RCE
 6. new: OrientDB RCE
 7. new: CouchDB RCE


171 Hard-coded P2P peer


HNS node contacts to other P2P peers with the following 3 methods, in which, 2 and 3 are listed in bitdefender original report.


 1. From a hard-coded built-in list of 171 peer addresses
 2. From the command-line args
 3. From the other P2P peers


These 171 peers will interact during the check-in and following interaction process


The Check-in Process


When started with no command-line args, HNS node will send lots of UPD check-in packets. IP addresses of these packets are randomized, while some others are set based on the build-in list. Part of the list is shown as follows, with a full list can be seen in the IoC section.





The Interaction Process


HNS has the following characteristics when doing P2P interaction between its nodes:


 * The check-in packet is a UDP packet with random length and content. So no significant feature here. The stands out is in the second packet from the upstream nodes, which has a length of 2 and the first byte is the uppercase letter ‘O’. In addition, the second byte of the return packet is actually a checksum value calculated from the request packet, so as can also be used to ID HNS communications. The detailed verification algorithm is shown as below.
 * After joining into the P2P network, HNS needs to perform address synchronization constantly to ensure nodes connections. This synchronous operation has strong network characteristics. First, the downstream node sends a request packet with the length 1 with content "~" to the upstream node, and then the upstream node replies with a packet of length 8 with the initial letter "^".
 * HNS nodes interact frequently and have lots of data exchange. The request packet length is 69 with initial letter "y", and the reply packet has a length of 261 with initial letter uppercase "Y".


The algorithm for service repond packets, based on python 2.7


When sending the following request packet:


data_pointer = "5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b".replace("","").decode('hex')



The expected response packet from the upstream node would be:


ack="4f b6".replace(" ","").decode('hex')



Where chr(0x4f) is fixed and chr(0xb6) is calculated as follows:


def calc_crc(data_pointer):
    data_len_1 = len(data_pointer)-1
    tmp = 88
    for i in range(0,data_len_1):
        tmp += ord(data_pointer[i])
        tmp = tmp &0xff
    tmp2 = tmp^0x3d
    print hex(tmp2),hex(ord(data_pointer[data_len_1]))
    if(tmp2 == ord(data_pointer[data_len_1])):
        return (2*tmp2&0xfe)
    return -1;



Contact Us


If readers have new discoveries, feel free to contact us on twitter.


IoC


Malware Sample md5


c1816d141321276cd4621abcd280ee40    #hns x86
0770ff1a6e90eb5d083c16452e45abd5    #hns arm
30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner



All 171 hard coded P2P peer address list is here.

{"version":"0.3.1","markups":[],"atoms":[],"cards":[["markdown",{"cardName":"card-markdown","markdown":"Author: Rootkiter, yegenshen\n\nHNS is an IoT botnet (Hide and Seek) originally discovered by BitDefender in January this year. In that [report](https://labs.bitdefender.com/2018/01/new-hide-n-seek-iot-botnet-using-custom-built-peer-to-peer-communication-spotted-in-the-wild/), the researchers pointed out that HNS used CVE-2016-10401, and other vulnerabilities to propagate malicious code and stole user information. The HNS communicates through the P2P mechanism, which is the second IoT botnet that we know uses P2P communication after Hajime.\n\nP2P-like botnets are hard to take down, and the HNS botnet has been continuously updated over the past few months, some major updates we see:\n\n- Added exploits for AVTECH devices (webcam, webcam), CISCO Linksys router, JAWS/1.0 web server, Apache CouchDB, OrientDB; with the two devices mentioned in the original report, HNS currently supports 7 exploiting methods all together\n- Hard-coded P2P node addresses have been increased to 171;\n- In addition, we observed that the HNS botnet adds a cpuminer mining program, it is not functioning properly yet.\n- In particular, with the added support of OrientDB and CouchDB database servers, HNS is no longer just an IoT botnet, but a cross-platform botnet now.\n\n#### Malware Samples\nWe analyzed following samples:\n\n```\nc1816d141321276cd4621abcd280ee40    #hns x86\n0770ff1a6e90eb5d083c16452e45abd5    #hns arm\n30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner\n```\n\n#### Network Scanning and Exploits\n\nHNS botnet looks for potential victims by initiating a network scanning. In this scanning, HNS borrows code from mirai botnet, and shares the same characters.\n\nThe scanning target ports include fixed TCP port 80/8080/2480/5984/23 and other random ports.\n\n![](__GHOST_URL__/content/images/2018/07/scanning-ports.png)\n\nThese ports and their corresponding well known services are:\n```\n23    Telnet\n80    HTTP Web Service\n2480  OrientDB\n5984  CouchDB\n8080  HTTP Web Service\nRandom-Port   NA\n```\n\nHNS will try to implant itself on these ports, utilizing the following exploits. In these exploits, 1 and 2 are listed in bitdefender original report. The other 5 are newly integrated.\n\n1. [TPLink-Routers RCE](https://sekurak.pl/tp-link-httptftp-backdoor/)\n2. [Netgear RCE](https://www.exploit-db.com/exploits/43055/)\n3. new: [AVTECH RCE](https://www.exploit-db.com/exploits/40500/)\n4. new: [CISCO Linksys Router RCE](https://vuldb.com/?id.12362)\n5. new: [JAW/1.0 RCE](https://www.pentestpartners.com/security-blog/pwning-cctv-cameras/)\n6. new: [OrientDB RCE](https://www.exploit-db.com/exploits/42965/)\n7. new: [CouchDB RCE](https://www.exploit-db.com/exploits/44913/)\n\n#### 171 Hard-coded P2P peer\n\nHNS node contacts to other P2P peers with the following 3 methods, in which, 2 and 3 are listed in bitdefender original report.\n\n1. From a hard-coded built-in list of 171 peer addresses\n2. From the command-line args\n3. From the other P2P peers\n\nThese 171 peers will interact during the check-in and following interaction process\n\n###### The Check-in Process\n\nWhen started with no command-line args, HNS node will send lots of UPD check-in packets. IP addresses of these packets are randomized, while some others are set based on the build-in list. Part of the list is shown as follows, with a full list can be seen in the IoC section.\n\n![](__GHOST_URL__/content/images/2018/07/hard-coded-peer.png)\n\n###### The Interaction Process\n\nHNS has the following characteristics when doing P2P interaction between its nodes:\n\n - The check-in packet is a UDP packet with random length and content. So no significant feature here. The stands out is in the second packet from the upstream nodes, which has a length of 2 and the first byte is the uppercase letter ‘O’. In addition, the second byte of the return packet is actually a checksum value calculated from the request packet, so as can also be used to ID HNS communications. The detailed verification algorithm is shown as below.\n - After joining into the P2P network, HNS needs to perform address synchronization constantly to ensure nodes connections. This synchronous operation has strong network characteristics. First, the downstream node sends a request packet with the length 1 with content \"~\" to the upstream node, and then the upstream node replies with a packet of length 8 with the initial letter \"^\".\n - HNS nodes interact frequently and have lots of data exchange. The request packet length is 69 with initial letter \"y\", and the reply packet has a length of 261 with initial letter uppercase \"Y\".\n\nThe algorithm for service repond packets, based on python 2.7\n\nWhen sending the following request packet:\n```\ndata_pointer = \"5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b\".replace(\"\",\"\").decode('hex')\n```\n\nThe expected response packet from the upstream node would be:\n```\nack=\"4f b6\".replace(\" \",\"\").decode('hex')\n```\n\nWhere chr(0x4f) is fixed and chr(0xb6) is calculated as follows:\n```\ndef calc_crc(data_pointer):\n    data_len_1 = len(data_pointer)-1\n    tmp = 88\n    for i in range(0,data_len_1):\n        tmp += ord(data_pointer[i])\n        tmp = tmp &0xff\n    tmp2 = tmp^0x3d\n    print hex(tmp2),hex(ord(data_pointer[data_len_1]))\n    if(tmp2 == ord(data_pointer[data_len_1])):\n        return (2*tmp2&0xfe)\n    return -1;\n```\n#### Contact Us\nIf readers have new discoveries, feel free to contact us on [twitter](https://twitter.com/360netlab).\n\n#### IoC\nMalware Sample md5\n```\nc1816d141321276cd4621abcd280ee40    #hns x86\n0770ff1a6e90eb5d083c16452e45abd5    #hns arm\n30ebaaeb61a4ecae3ade7d1d4e5c7adb    #hns_miner\n```\n\nAll 171 hard coded P2P peer address list is [here](__GHOST_URL__/file/hns_hardcoded_peer_list.txt).\n"}]],"sections":[[10,0]],"ghostVersion":"3.0"}