{ "id": "7617c2d4-e14c-437d-b79e-b36d10cda135", "created_at": "2026-04-06T00:22:00.65201Z", "updated_at": "2026-04-10T03:20:52.513623Z", "deleted_at": null, "sha1_hash": "a722a2512dac691789cd79d6d297032eb09f97a8", "title": "HNS Botnet Recent Activities", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 365405, "plain_text": "HNS Botnet Recent Activities\r\nBy RootKiter\r\nPublished: 2018-07-06 · Archived: 2026-04-05 20:15:56 UTC\r\nAuthor: Rootkiter, yegenshen\r\nHNS is an IoT botnet (Hide and Seek) originally discovered by BitDefender in January this year. In that report, the\r\nresearchers pointed out that HNS used CVE-2016-10401, and other vulnerabilities to propagate malicious code\r\nand stole user information. The HNS communicates through the P2P mechanism, which is the second IoT botnet\r\nthat we know uses P2P communication after Hajime.\r\nP2P-like botnets are hard to take down, and the HNS botnet has been continuously updated over the past few\r\nmonths, some major updates we see:\r\nAdded exploits for AVTECH devices (webcam, webcam), CISCO Linksys router, JAWS/1.0 web server,\r\nApache CouchDB, OrientDB; with the two devices mentioned in the original report, HNS currently\r\nsupports 7 exploiting methods all together\r\nHard-coded P2P node addresses have been increased to 171;\r\nIn addition, we observed that the HNS botnet adds a cpuminer mining program, it is not functioning\r\nproperly yet.\r\nIn particular, with the added support of OrientDB and CouchDB database servers, HNS is no longer just an\r\nIoT botnet, but a cross-platform botnet now.\r\nMalware Samples\r\nWe analyzed following samples:\r\nc1816d141321276cd4621abcd280ee40 #hns x86\r\n0770ff1a6e90eb5d083c16452e45abd5 #hns arm\r\n30ebaaeb61a4ecae3ade7d1d4e5c7adb #hns_miner\r\nNetwork Scanning and Exploits\r\nHNS botnet looks for potential victims by initiating a network scanning. In this scanning, HNS borrows code from\r\nmirai botnet, and shares the same characters.\r\nThe scanning target ports include fixed TCP port 80/8080/2480/5984/23 and other random ports.\r\nhttps://blog.netlab.360.com/hns-botnet-recent-activities-en/\r\nPage 1 of 4\n\nThese ports and their corresponding well known services are:\r\n23 Telnet\r\n80 HTTP Web Service\r\n2480 OrientDB\r\n5984 CouchDB\r\n8080 HTTP Web Service\r\nRandom-Port NA\r\nHNS will try to implant itself on these ports, utilizing the following exploits. In these exploits, 1 and 2 are listed in\r\nbitdefender original report. The other 5 are newly integrated.\r\n1. TPLink-Routers RCE\r\n2. Netgear RCE\r\n3. new: AVTECH RCE\r\n4. new: CISCO Linksys Router RCE\r\n5. new: JAW/1.0 RCE\r\n6. new: OrientDB RCE\r\n7. new: CouchDB RCE\r\n171 Hard-coded P2P peer\r\nHNS node contacts to other P2P peers with the following 3 methods, in which, 2 and 3 are listed in bitdefender\r\noriginal report.\r\n1. From a hard-coded built-in list of 171 peer addresses\r\n2. From the command-line args\r\n3. From the other P2P peers\r\nThese 171 peers will interact during the check-in and following interaction process\r\nThe Check-in Process\r\nhttps://blog.netlab.360.com/hns-botnet-recent-activities-en/\r\nPage 2 of 4\n\nWhen started with no command-line args, HNS node will send lots of UPD check-in packets. IP addresses of these\r\npackets are randomized, while some others are set based on the build-in list. Part of the list is shown as follows,\r\nwith a full list can be seen in the IoC section.\r\nThe Interaction Process\r\nHNS has the following characteristics when doing P2P interaction between its nodes:\r\nThe check-in packet is a UDP packet with random length and content. So no significant feature here. The\r\nstands out is in the second packet from the upstream nodes, which has a length of 2 and the first byte is the\r\nuppercase letter ‘O’. In addition, the second byte of the return packet is actually a checksum value\r\ncalculated from the request packet, so as can also be used to ID HNS communications. The detailed\r\nverification algorithm is shown as below.\r\nAfter joining into the P2P network, HNS needs to perform address synchronization constantly to ensure\r\nnodes connections. This synchronous operation has strong network characteristics. First, the downstream\r\nnode sends a request packet with the length 1 with content \"~\" to the upstream node, and then the upstream\r\nnode replies with a packet of length 8 with the initial letter \"^\".\r\nHNS nodes interact frequently and have lots of data exchange. The request packet length is 69 with initial\r\nletter \"y\", and the reply packet has a length of 261 with initial letter uppercase \"Y\".\r\nThe algorithm for service repond packets, based on python 2.7\r\nWhen sending the following request packet:\r\ndata_pointer = \"5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b\".replace(\"\",\"\").decode('hex')\r\nThe expected response packet from the upstream node would be:\r\nack=\"4f b6\".replace(\" \",\"\").decode('hex')\r\nWhere chr(0x4f) is fixed and chr(0xb6) is calculated as follows:\r\nhttps://blog.netlab.360.com/hns-botnet-recent-activities-en/\r\nPage 3 of 4\n\ndef calc_crc(data_pointer):\r\n data_len_1 = len(data_pointer)-1\r\n tmp = 88\r\n for i in range(0,data_len_1):\r\n tmp += ord(data_pointer[i])\r\n tmp = tmp \u00260xff\r\n tmp2 = tmp^0x3d\r\n print hex(tmp2),hex(ord(data_pointer[data_len_1]))\r\n if(tmp2 == ord(data_pointer[data_len_1])):\r\n return (2*tmp2\u00260xfe)\r\n return -1;\r\nContact Us\r\nIf readers have new discoveries, feel free to contact us on twitter.\r\nIoC\r\nMalware Sample md5\r\nc1816d141321276cd4621abcd280ee40 #hns x86\r\n0770ff1a6e90eb5d083c16452e45abd5 #hns arm\r\n30ebaaeb61a4ecae3ade7d1d4e5c7adb #hns_miner\r\nAll 171 hard coded P2P peer address list is here.\r\nSource: https://blog.netlab.360.com/hns-botnet-recent-activities-en/\r\nhttps://blog.netlab.360.com/hns-botnet-recent-activities-en/\r\nPage 4 of 4\n\nThe algorithm When sending for service repond the following packets, based request packet: on python 2.7\ndata_pointer = \"5b 02 d7 ff 52 02 61 e9 a5 7e 0b 07 c5 43 5b\".replace(\"\",\"\").decode('hex')\nThe expected response packet from the upstream node would be:\nack=\"4f b6\".replace(\" \",\"\").decode('hex') \nWhere chr(0x4f) is fixed and chr(0xb6) is calculated as follows:\n Page 3 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.netlab.360.com/hns-botnet-recent-activities-en/" ], "report_names": [ "hns-botnet-recent-activities-en" ], "threat_actors": [], "ts_created_at": 1775434920, "ts_updated_at": 1775791252, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a722a2512dac691789cd79d6d297032eb09f97a8.pdf", "text": "https://archive.orkl.eu/a722a2512dac691789cd79d6d297032eb09f97a8.txt", "img": "https://archive.orkl.eu/a722a2512dac691789cd79d6d297032eb09f97a8.jpg" } }