{
	"id": "e24edc06-a1ea-4d3f-948c-7c667e456d95",
	"created_at": "2026-04-06T00:12:54.637727Z",
	"updated_at": "2026-04-10T03:20:47.068403Z",
	"deleted_at": null,
	"sha1_hash": "72e188e1148d2e1e98964624fce85b311ef4351a",
	"title": "The Mostly Dead Mozi and Its’ Lingering Bots",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 999743,
	"plain_text": "The Mostly Dead Mozi and Its’ Lingering Bots\r\nBy Alex.Turing\r\nPublished: 2021-08-30 · Archived: 2026-04-05 15:43:36 UTC\r\nBackground\r\nIt has been nearly 2 years since we (360NETLAB) first disclosed the Mozi botnet in December 2019, and in that\r\ntime we have witnessed its development from a small-scale botnet to a giant that accounted for an extremely\r\nhigh percentage of IOT traffic at its peak .\r\nNow that Mozi's authors have been taking custody by law enforcement agencies, in which we provided\r\ntechnical assistance throughout, we don't think it will continue to be updated for quite some time to come. But we\r\nknow that Mozi uses a P2P network structure, and one of the \"advantages\" of a P2P network is that it is robust, so\r\neven if some of the nodes go down, the whole network will carry on, and the remaining nodes will still infect\r\nother vulnerable devices, that is why we can still see Mozi spreading.\r\nMany security vendors have tracked and analyzed Mozi, but from our point of view, there are some omissions and\r\neven mistakes. So here is our provide some updates to complement the security community's analysis; and to\r\nconclude our ongoing focus on the Mozi botnet.\r\nThis article will answer the following questions.\r\n1: Does Mozi have any functional nodes other than the Bot node?\r\n2: Are there any new features in the Mozi Bot module?\r\n3: Is the Mozi botnet still being updated?\r\nWhat are the other functional nodes in the Mozi botnet besides the Bot?\r\nAs we all know, each node in the Mozi botnet is driven by a configuration file called Config issued by the Botnet\r\nMaster to perform specific tasks. The following figure is a classic Config file, where the [ss] field describes the\r\nfunction of the node, in this case the Bot node , the main function is DDoS attacks.\r\nWhat puzzled us was that, in addition to the Bot node's Config, the following forms of Config files were captured\r\nas well, indicating that there were also nodes named sk,ftp,sns,ssh in the Mozi botnet.\r\n[ss]sk[/ss][hp]88888888[/hp][count]http://ia.51.la/go1?id\r\n[ss]ftp[/ss][hp]88888888[/hp][count]http://ia.51.la/go1?id\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 1 of 15\n\n[ss]sns[/ss][hp]88888888[/hp][count]http://ia.51.la/go1?id\r\n[ss]ssh[/ss][hp]88888888[/hp]\r\nSo what exactly are they?\r\n0x1: FTP node\r\nOn January 20, 2020, a Windows PE file named \"photo.scr\" (a9d4007c9419a6e8d55805b8f8f52de0) generated\r\nnetwork traffic that matched our Mozi signature. At first we thought it was a false alarm, but after analyzing it, we\r\ndetermined that it was exactly the Mozi ftp node sample we had in mind. In order to distinguish the samples\r\nfrom the different functional nodes in the Mozi botnet, we started to use the Mozi_\"ss value\" internally, so this\r\nsample was named Mozi_ftp .\r\nIn short, Mozi_ftp is a pyinstaller-packaged mining trojan that spreads through FTP weak password, and it joins\r\nthe Mozi P2P network and waits to execute the Config issued by Botnet Master. the wallet address is shown\r\nbelow:\r\n47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV\r\nThe module named back.jpg is responsible for joining the Mozi network as well as pulling the Config file, and its\r\nbasic information is shown as follows.\r\nFilename:back.jpg\r\nMD5:4ae078dd5085e97d3605f20dc079412a\r\nPE32 executable for MS Windows (DLL) (console) Intel 80386\r\nPacker: upx\r\nSome of the tags supported by Mozi_ftp Config can be clearly seen in the unpacked sample.\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 2 of 15\n\nLike Mozi_bot, Mozi_ftp also has an encrypted raw Config file embedded, which is decrypted by XOR as follows\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 3 of 15\n\nAs with Mozi_bot, Mozi_ftp checks the signature of the Config with the following code snippet\r\nThe XOR key used, and the two public_keys are as follows.\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\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 4 of 15\n\n27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65\r\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\nTheir values are the same as those used by Mozi_bot. According to the characteristics of the ECDSA384 elliptic\r\nalgorithm, this means that Mozi_ftp and Mozi_bot use the same private key, and excluding the possibility of\r\nprivate key leakage, we can conclude that they are from the same author.\r\nIn back.jpg , we can see that Mozi_ftp's Config supports the following basic tags.\r\n[hp]\r\n[cpu]\r\n[cpux]\r\n[ss]\r\n[ssx]\r\n[nd]\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 5 of 15\n\nIn the script of ftpcrack.py , there is the following code snippet.\r\nThis shows that Mozi_ftp also implements the following 4 special tags of its own.\r\n[mdf]\r\n[mdr]\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 6 of 15\n\n[mud]\r\n[mrn]\r\n0x2: SSH node\r\nMozi uses the 51la, public service platform for its own statistics, In September 2020, we were able to tape into\r\nMozi's backend statistics, on which we see not only the statistics of the Mozi_bot node, but also a set of unseen\r\nreporting entries as shown below.\r\nOn August 18, 2021, security vendor QiAnxin and Sangfor issued threat reports describing a mining Trojan\r\nnamed WorkMiner was spreading through weak SSH password, and it has P2P network behavior. We took a look\r\nand were surprised to find that this is exactly the SSH node in the Mozi botnet, and it has direct link to the\r\naforementioned 51la urls. Here we will call it Mozi_ssh .\r\nThe basic information of the sample we selected for analysis is shown below.\r\nFilename:work64\r\nMD5:429258270068966813aa77efd5834a94\r\nELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped\r\nPacker:upx\r\nIn brief, Mozi_ssh is a mining trojan that spreads worm-like through SSH weak password, and became active\r\naround October 2020 (based on the sample's time on VT, which may not be accurate), with the wallet address\r\nshown below, which shows that Mozi_ssh and Mozi_ftp use the same wallet.\r\n47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV\r\nMozi_ssh is compiled from a mix of GO code and C code. The GO code is responsible for SSH-related\r\npropagation and the handling of Config, while the C code handles joining the Mozi P2P network and pulling\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 7 of 15\n\nConfig.\r\nMozi_ssh is implemented by the following code snippet calling the C code (dht_task) to add to the P2P network.\r\nThe function dht_task handles the same logic as Mozi_bot, and the embedded Config is decrypted as shown\r\nbelow.\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 8 of 15\n\nLike Mozi_ftp, the XOR key used to decrypt the Config, and the two public_keys used to check the signature of\r\nthe Config are the same as the ones used in Mozi_bot, which means that Mozi_ssh and Mozi_bot come from the\r\nsame author.\r\nIn the dht_task function, it can be seen that the Config of Mozi_ssh supports the following basic tags.\r\n[hp]\r\n[ver]\r\n[cpu]\r\n[ss]\r\n[sv]\r\n[nd]\r\nFor the Config that passes the test, Mozi_ssh uses to process it through the function main_deal_conf, for example,\r\nthe following code snippet is processing the swan tag. Compared to Mozi_bot, Mozi_ssh supports not only basic\r\ntags, but also implements many of its own special tags.\r\nThe special tags supported by Mozi_ssh are shown below.\r\n[slan]\r\n[swan]\r\n[spl]\r\n[sdf]\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 9 of 15\n\n[sud]\r\n[ssh]\r\n[srn]\r\n[sdr]\r\n[scount]\r\n0x3: Summary\r\nThe discovery of Mozi_ftp, Mozi_ssh gives us clear evidence that the Mozi botnet is also trying to profit from\r\nmining. From the samples of bot, ftp, and ssh nodes , we can see that their authors have used the\r\n\"DHT+Config\" model as a basic module, and by reusing this module and designing different special tag\r\ncommands for different functional nodes, they can quickly develop the programs needed for new functional nodes,\r\nwhich is very convenient. This convenience is one of the reasons for the rapid expansion of the Mozi botnet.\r\nWhat are the changes in Mozi bot v2s?\r\nThe Mozi botnet was mostly made of mozi_bot nodes. On January 07, 2020, we captured the bot sample with a\r\nversion number v2s (1bd4f62fdad18b0c140dce9ad750f6de), and this version has been active since then and has\r\nattracted a lot of attention from the security community, and although many security vendors have analyzed it, we\r\nfound that there are still missing parts.\r\nAccording to statistics, the samples of mozi v2s bot are mainly ARM and MIPS CPU architectures, and the\r\nsamples of ARM architecture are selected below for analysis.\r\nMD5:b9e122860983d035a21f6984a92bfb22\r\nELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped\r\nLib: uclibc\r\nPacker:UPX\r\nThe v2s bot sample has many changes from the v2 sample we initially analyzed, the most intuitive of which is\r\nreflected in the tags supported by Config. v2s has added two new tags [cnc], [hj], in addition to the new external\r\nnetwork address acquisition, upnp port mapping and other features, the following section we will go over the\r\nchanges brought by these features to Mozi_bot, note Microsoft published an article on the [hj] tag on August\r\n19, 2021 here.\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 10 of 15\n\n0x1: [cnc] tag\r\nThe Mozi botnet's \"DHT+Config\" design has its convenience, but it also has a drawback that all Bot nodes have\r\ninefficiency in synchronizing Config , which indirectly leads to inefficiency in DDoS. To solve this problem,\r\nMozi authors designed the tag [cnc], which corresponds to the new DDoS attack subtask.\r\nThe whole subtask reuses the code of Mirai, specifying C2 by the [cnc] keyword, and the Bot node waits for the\r\ncommand sent by C2 to perform DDos attack after establishing communication with C2 through Mirai protocol.\r\nAfter adding this subtask, when Mozi wants to carry out an attack, it no longer needs to obtain the attack target by\r\nsynchronizing Config one at a time, but only needs to synchronize Config once to get the specified C2, which\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 11 of 15\n\ngreatly improves the attack efficiency of Bot nodes, and the corresponding network structure is shown as follows.\r\nThe following is the code snippet to obtain C2:PORT.\r\nThe following is the code snippet for sending online packets.\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 12 of 15\n\nThe following is the code snippet for sending heartbeats.\r\nThe following is the supported attack vector, there are 12 methods, the number 11 is written twice, so in reality\r\nMozi's Bot node only supports 11 attack methods.\r\nIf you are familiar with Mirai, you will smile when you see the following screenshot. Because of the extensive use\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 13 of 15\n\nof Mirai code, this batch of Mozi samples are marked as Mirai by a large number of antivirus producers.\r\nhttp://ipinfo.io/ip is called to get the internet address during the telnet \u0026exploit procdures.\r\nAfter adding this feature there will be no more cases where intranet ip is being used to spread the payload.\r\n0x3: upnp port mapping\r\nWhen the infected device is accessing the network through NAT, the HTTP sample download service opened by\r\nMozi_bot on the device through the listening port is not directly accessible by the external network. The new\r\nversion of Mozi implements port mapping on the router through upnp's AddPortMapping to ensure normal access\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 14 of 15\n\nto the service.\r\n0x4: Summary\r\nWe can see that these updates to Mozi bot are all about efficiency: efficiency of DDoS attacks, efficiency of\r\nspreading infections. The abandonment of Gafgyt's attack code in favor of the more efficient Mirai. the separation\r\nof control nodes through [cnc] subtasking, refactoring DDoS attack functionality, and achieving separation of\r\ncontrol nodes from bot nodes greatly increases Mozi's network resilience. This separation means that the botnet's\r\ncontrol function is decoupled from the actual bot functions, allowing Mozi's authors to not only conduct DDos\r\nattacks themselves, but also make it possible to lease the network to other groups.\r\nAre Mozi bots still being updated?\r\nThe Mozi botnet samples have stopped updating for quite some time, but this does not mean that the threat posed\r\nby Mozi has ended. Since the parts of the network that are already spread across the Internet have the ability to\r\ncontinue to be infected, new devices are infected every day. Overall we expect it to oscillate downward in size on\r\na weekly basis but might keep alive for a long time, just like several other botnets that have been terminated by\r\nlaw enforcement agencies in the past.\r\nSource: https://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nhttps://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/\r\nPage 15 of 15\n\nAs with Mozi_bot, The XOR key used, Mozi_ftp checks and the two the signature public_keys are of the Config as follows. with the following code snippet\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\n   Page 4 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.netlab.360.com/the-mostly-dead-mozi-and-its-lingering-bots/"
	],
	"report_names": [
		"the-mostly-dead-mozi-and-its-lingering-bots"
	],
	"threat_actors": [],
	"ts_created_at": 1775434374,
	"ts_updated_at": 1775791247,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/72e188e1148d2e1e98964624fce85b311ef4351a.pdf",
		"text": "https://archive.orkl.eu/72e188e1148d2e1e98964624fce85b311ef4351a.txt",
		"img": "https://archive.orkl.eu/72e188e1148d2e1e98964624fce85b311ef4351a.jpg"
	}
}