{
	"id": "c817188c-c395-4707-bb32-05f182b129bd",
	"created_at": "2026-04-06T00:14:22.528431Z",
	"updated_at": "2026-04-10T03:21:01.940049Z",
	"deleted_at": null,
	"sha1_hash": "63d680203478168ff7cff7e7a8c7265bd077100a",
	"title": "Mozi, Another Botnet Using DHT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1891577,
	"plain_text": "Mozi, Another Botnet Using DHT\r\nBy Alex.Turing\r\nPublished: 2019-12-23 · Archived: 2026-04-05 21:40:11 UTC\r\nMozi Botnet relies on the DHT protocol to build a P2P network, and uses ECDSA384 and the xor algorithm to\r\nensure the integrity and security of its components and P2P network. The sample spreads via Telnet with weak\r\npasswords and some known exploits\r\nOverview\r\nOn September 03, 2019, a suspicious file was tagged by our new threat monitoring system and a quick checking\r\non VT shows most engines flagged it as Gafgyt. The sample does reuse part of the Gafgyt code, but it is not really\r\nGafgyt.\r\nThe sample represents a brand new P2P botnet implemented based on the DHT protocol, the last botnet which\r\nuses DHT is the Hajime, and we call it Mozi according to the characteristics of its propagation sample file name\r\nMozi.m , Mozi.a .\r\nMozi Botnet relies on the DHT protocol to build a P2P network, and uses ECDSA384 and the xor algorithm to\r\nensure the integrity and security of its components and P2P network. The sample spreads via Telnet with weak\r\npasswords and some known exploits (see the list below). In terms of functions, the execution of the instructions of\r\neach node in the Mozi botnet is driven by a Payload called Config issued by the Botnet Master. The main\r\ninstructions include:\r\nDDoS attack\r\nCollecting Bot Information\r\nExecute the payload of the specified URL\r\nUpdate the sample from the specified URL\r\nExecute system or custom commands\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 1 of 15\n\nThe overall network structure is shown in the following figure:\r\nSample Spread\r\nMozi infects new devices through weak telnet passwords and exploits.The infection process is as follows:\r\nThe current Bot node randomly uses a local port to start the http service to provide sample downloads or\r\nreceives the sample download address in the Config file issued by the Botnet Master.Provides a sample\r\ndownload address for future infected targets.\r\nThe current Bot node logs in to the target device with a weak password, writes the downloader file in echo\r\nmode and runs it, and downloads the sample file from the sample download address provided by the\r\ncurrent Bot node. Or use a vulnerability to exploit the target, and then obtain a sample file from the sample\r\ndownload address provided by the current Bot node.\r\nRun the Mozi Bot sample on the infected target device, join the Mozi P2P network to become the new\r\nMozi Bot node and continue to infect other new devices.\r\nThe vulnerabilities used by Mozi Botnet are shown in the following table:\r\nVulnerability Affected Aevice\r\nEir D1000 Wireless Router RCI Eir D1000 Router\r\nVacron NVR RCE Vacron NVR devices\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 2 of 15\n\nVulnerability Affected Aevice\r\nCVE-2014-8361 Devices using the Realtek SDK\r\nNetgear cig-bin Command Injection Netgear R7000 and R6400\r\nNetgear setup.cgi unauthenticated RCE DGN1000 Netgear routers\r\nJAWS Webserver unauthenticated shell command execution MVPower DVR\r\nCVE-2017-17215 Huawei Router HG532\r\nHNAP SoapAction-Header Command Execution D-Link Devices\r\nCVE-2018-10561, CVE-2018-10562 GPON Routers\r\nUPnP SOAP TelnetD Command Execution D-Link Devices\r\nCCTV/DVR Remote Code Execution CCTV DVR\r\nAt present, we do not know the exact scale of the Botnet, we do manage to become a node to join the DHT\r\nnetwork and are tracking some baseline numbers, we will share more details probably in another blog later on.\r\nAnd from other data we have collected, we can also see the number of infection has been increasing.The picture\r\nbelow shows the Mozi bot infection based on the log collected by our honeypot.\r\nSample Reverse Analysis\r\nThere are three versions of Mozi Botnet, which can be distinguished by their slightly different telnet propagation\r\nmethods.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 3 of 15\n\nOur analysis is mainly focus on the latest version v2, and this blog will cover the key elements such as\r\npropagation method, Config structure and its DHT network.\r\nSample Information\r\nMD5:eda730498b3d0a97066807a2d98909f3\r\nELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped\r\nPacker: NO\r\nLibrary:uclibc\r\nVersion: v2\r\nIt is worth mentioning that in the first version Mozi(sample md5: 849b165f28ae8b1cebe0c7430f44aff3 ) used upx\r\npacking. But instead of using the common upx magic number to defeat unpacking, it used a novel method, to\r\nerase the value of p_filesize \u0026 p_blocksize to zero, with that change, researcher need to patch the upx source code\r\nthen unpacking is possible.\r\nCommon Functions\r\nMozi doesn't have much characteristics in the host behavior level. It reuses Gafgyt's code to implements many\r\ncommon functions, such as single instance, process name modification, and ACL modification.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 4 of 15\n\nPerform Specific Tasks\r\nAfter Mozi establishes the p2p network through the DHT protocol, the config file is synchronized, and the\r\ncorresponding tasks are started according to the instructions in the config file.In P2P networks, nodes are\r\nuntrusted, and anyone can fake a Mozi node at a very low cost.In order to ensure that the Mozi network is\r\ncompletely controllable and cannot be stolen by others, Mozi needs to perform signature verification on each\r\nsynchronized config, and only if it can pass the signature verification can it be accepted and executed by the Mozi\r\nnode.\r\nDocument \u0026 Instruction Inspection\r\nMozi uses the ECDSA384 algorithm to verify the legitimacy of files and instructions. Each sample integrates two\r\nxor-encrypted public keys, which are used to sign encrypted and decrypted config files, respectively.\r\n xor key:4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E\r\n------------------------------------------------------------------\r\nxored publickey A\r\n4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F\r\n69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B\r\n38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 A1\r\nafter decryption:\r\n02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21\r\n27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 5 of 15\n\n76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea ef\r\n-------------------------------------------------------------------\r\nxored publickey B\r\n4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8\r\nE9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53\r\n22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 88\r\nafter decryption:\r\n02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6\r\na7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d\r\n6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 c6\r\nConfig File\r\nEach sample integrates an xor-encrypted initial config file with a length of 528 bytes. Its structure is data (428\r\nbytes), sign (96 bytes), flag (4 bytes). The sign field is a digital signature and the flag field controls if the config\r\nfile is updated or not.There are many control fields in the config file. After receiving the config, the Mozi node\r\nparses the field content and executes the corresponding subtasks.The original config file is as follows.\r\nThe decryption process is shown in the following figure, where the xor key is 4E 66 5A 8F 80 C8 AC 23 8D AC\r\n47 06 D5 4F 6F 7E\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 6 of 15\n\nThe decrypted config is as follows.\r\nThe supported keywords are as follows, which can be divided into three categories: declaration, control, and\r\nsubtask.\r\n1：declaration\r\n[cpu]　　cpu arch or os\r\n[cpux] cpu arch or os\r\n[ss] bot role\r\n[ssx] bot role\r\n[nd] new node info which help to join DHT\r\n2:control\r\n[ver] verify\r\n[sv] update Config\r\n[hp] DHT id prefix\r\n[dip] URL or ip:port list which can get Mozi sample\r\n3:subtask\r\n[atk] DDOS attack\r\n[ud] update\r\n[dr] exec payload from specific URL\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 7 of 15\n\n[rn] exec system or customized cmds\r\n[idp] report bot info\r\nBot Function\r\nDDOS， [atk] field trigger, reuse Gafgyt attack code, support HTTP, TCP, UDP and other attacks.\r\nCommand\r\n-----------------------------------------\r\nS\r\nT\r\nU\r\nKT\r\nHTTP\r\nReport Bot information, [idp] field trigger, the content reported are Bot ID, IP, PORT, file name (full\r\npath), gateway, cpu architecture.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 8 of 15\n\nThe payload of the specified URL is executed, and the [dr] field is triggered.\r\nUpdate from the specified URL, the [ud] field is triggered. Close the current node's network connection\r\nand related processes, download the new version from the specified URL, save DHT node, ID and other\r\ndata, and provide them as parameters for the new version.\r\nExecute system or Bot custom command, [rn] field trigger.\r\nDHT\r\nMozi Botnet uses its own extended DHT protocol to build a P2P network. There are two benefits to this. One is to\r\nuse standard DHT to quickly establish a network, and the other is to use its own extension to hide the valid\r\npayload in the vast amount of normal DHT traffic so detection is impossible without proper knowledge. Mozi uses\r\n8 sets of public nodes and the nodes specified in the [nd] field of the Config file as bootstrap nodes, toguide new\r\nnodes to join their DHT network.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 9 of 15\n\nPublic node, sample embedded\r\ndht.transmissionbt.com:6881\r\nrouter.bittorrent.com:6881\r\nrouter.utorrent.com:6881\r\nbttracker.debian.org:6881\r\n212.129.33.59:6881\r\n82.221.103.244:6881\r\n130.239.18.159:6881\r\n87.98.162.88:6881\r\n[nd] Specified in the Config file\r\nID Generation\r\nThe ID is 20 bytes and consists of the prefix 888888 embedded in the sample or the prefix specified by the\r\nconfig file [hp], plus a randomly generated string.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 10 of 15\n\nNode Recognition\r\nIn order to distinguish regular traffic with its own traffic, Mozi uses 1:v4:flag(4 bytes) such an identifier to\r\nidentify whether the traffic is sent by its node. The meaning of the flag byte is as follows.\r\nflag means is as follows\r\nflag(4 bytes)\r\n----------------------------------------------\r\noffset:\r\n0 -----random\r\n1 ----- hard-code(0x42) or from [ver]\r\n 2 -----calc by algorithm\r\n 3 -----calc by algorithm\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 11 of 15\n\nThe first byte is randomly generated. The second byte is hard-coded 0x42 or specified by the [ver] field in the\r\nconfig file.\r\nThe 3rd and 4th bytes are obtained by the algorithm.\r\nver algorithm\r\n----------------------------------------------\r\nint first,sec;\r\nstring ver=\"\\x31\\x3a\\x76\\x34\\x3a\\x00\\x00\"s;\r\ncout \u003c\u003c \"Please input the two number: (0x00-0xff)\" \u003c\u003c endl;\r\ncin.unsetf(ios::hex);\r\ncin \u003e\u003e hex \u003e\u003e first \u003e\u003e sec;\r\nver[5] = char(first);\r\nver[6] = char(sec);\r\nuint32_t va = 0;\r\nfor(int i = 0; i \u003c 7; i++)\r\n{\r\nuint32_t tmp = int(ver[i]);\r\ntmp = tmp \u003c\u003c 8;\r\ntmp ^= va;\r\nint rnd = 8;\r\nwhile (rnd--)\r\n{\r\nif ((tmp \u0026 0xffff) \u003e 0x8000)\r\n{\r\ntmp *= 2;\r\ntmp ^= 0xffff8005;\r\n}\r\nelse\r\ntmp *= 2;\r\n}\r\nva = tmp\u00260xffff;\r\n}\r\ncout \u003c\u003c hex \u003c\u003c \"Final \" \u003c\u003c va \u003c\u003c endl;\r\nPlease input the two number: (0x00-0xff)\r\n0x44 0x42\r\nFinal 1f71\r\nEnter 0x44 0x42, and get the 0x1f71 same result as in the packet.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 12 of 15\n\nNetwork Request\r\nThe network requests received by Mozi nodes can be divided into two categories, DHT requests and non-DHT\r\nrequests. 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\r\nget_peers. For non-DHT requests, there are two types based on whether the network packet length is greater than\r\n99 or not.\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 13 of 15\n\nFor Mozi, Different requests have different processing logic, see below\r\nraw data, first 128 bytes:\r\n00000000 64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38 |d1:rd2:id20:8888|\r\n00000010 38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69 |8888·..fáq.åM\u003ei|\r\n00000020 35 3a 6e 6f 64 65 73 36 32 34 3a 15 15 29 d2 f3 |5:nodes624:..)Òó|\r\n00000030 a3 f7 0c fe df 1a 5d bd 3f 32 46 76 5e 62 b7 b8 |£÷.þß.]½?2Fv^b·¸|\r\n00000040 f0 94 78 a2 c4 37 5b 8e 2c 00 0b 20 12 07 e7 f4 |ð.x¢Ä7[.,.. ..çô|\r\n00000050 bc dc 19 a2 83 2e 67 fb 7a 5e 50 22 07 75 e8 ef |¼Ü.¢..gûz^P\".uèï|\r\n00000060 f9 93 4a e9 91 75 36 e4 76 57 4b 7c 51 7c ff f5 |ù.Jé.u6ävWK|Q|ÿõ|\r\n00000070 f5 c4 57 f9 dc 62 35 b4 6a 5d 18 6b 54 3c ed e1 |õÄWùÜb5´j].kT\u003cíá|\r\n00000080 a1 c8 56 a3 cf 28 6b fa 14 06 1a 3e 3b 01 a0 e3 |¡ÈV£Ï(kú...\u003e;.ã|\r\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\r\nraw data:\r\n00000000 64 31 3a 72 64 32 3a 69 64 32 30 3a 38 38 38 38 |d1:rd2:id20:8888|\r\n00000010 38 38 38 38 b7 96 a0 9e 66 e1 71 98 e5 4d 3e 69 |8888·..fáq.åM\u003ei|\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 14 of 15\n\n00000020 35 3a 6e 6f 64 65 73 36 32 34 3a |5:nodes624:\r\nconfiguration:\r\n00000000 5b 73 73 5d 73 6b 5b 2f 73 73 5d 5b 68 70 5d 38 |[ss]sk[/ss][hp]8|\r\n00000010 38 38 38 38 38 38 38 5b 2f 68 70 5d 5b 63 6f 75 |8888888[/hp][cou|\r\n00000020 6e 74 5d 68 74 74 70 3a 2f 2f 69 61 2e 35 31 2e |nt]http://ia.51.|\r\n00000030 6c 61 2f 67 6f 31 3f 69 64 3d 32 30 31 39 38 35 |la/go1?id=201985|\r\n00000040 32 37 26 70 75 3d 68 74 74 70 25 33 61 25 32 66 |27\u0026pu=http%3a%2f|\r\nSuggestions\r\nWe recommend that users update the patch in a timely manner, and determine whether they are infected by\r\nlooking up the process and file name, and HTTP, DHT network connection characteristics created by Mozi Botnet.\r\nReaders are always welcomed to reach us on twitter, WeChat 360Netlab or email to netlab at 360 dot cn.\r\nIoC list\r\nSample MD5:\r\neda730498b3d0a97066807a2d98909f3\r\n849b165f28ae8b1cebe0c7430f44aff3\r\nSource: https://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nhttps://blog.netlab.360.com/mozi-another-botnet-using-dht/\r\nPage 15 of 15\n\nMozi uses the ECDSA384 xor-encrypted public algorithm keys, which to verify the are used to sign legitimacy of files encrypted and and instructions. decrypted config Each sample files, respectively. integrates two\nxor key:4E 66 5A 8F 80 C8 AC 23 8D AC 47 06 D5 4F 6F 7E\n------------------------------------------------------------------   \nxored publickey A  \n4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F\n69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B\n38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 A1\nafter decryption:   \n02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21\n27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65\n   Page 5 of 15\n\n0x44 0x42 Final 1f71    \nEnter 0x44 0x42, and get the 0x1f71 same result as in the packet.\n    Page 12 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.netlab.360.com/mozi-another-botnet-using-dht/"
	],
	"report_names": [
		"mozi-another-botnet-using-dht"
	],
	"threat_actors": [],
	"ts_created_at": 1775434462,
	"ts_updated_at": 1775791261,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/63d680203478168ff7cff7e7a8c7265bd077100a.pdf",
		"text": "https://archive.orkl.eu/63d680203478168ff7cff7e7a8c7265bd077100a.txt",
		"img": "https://archive.orkl.eu/63d680203478168ff7cff7e7a8c7265bd077100a.jpg"
	}
}