{
	"id": "39043b0f-267e-4b1e-8276-82eb3cc015f7",
	"created_at": "2026-04-06T00:10:18.068694Z",
	"updated_at": "2026-04-10T03:20:56.348139Z",
	"deleted_at": null,
	"sha1_hash": "043fa6a320306de65290cb472005ad3930032bee",
	"title": "P2P Botnets: Review - Status - Continuous Monitoring",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1337504,
	"plain_text": "P2P Botnets: Review - Status - Continuous Monitoring\r\nBy 360Netlab\r\nPublished: 2022-11-03 · Archived: 2026-04-05 20:29:37 UTC\r\nOrigins\r\nP2P networks are more scalable and robust than traditional C/S structures, and these advantages were recognized\r\nby the botnet authors early on and used in their botnets. In terms of time, Storm, which appeared in 2007, can be\r\nconsidered the progenitor of this area, when botnet threats were first known to the public. after Storm, there have\r\nbeen Karen, ZeroAccess, GameOver, Hijime, mozi and other kinds of P2P botnes, P2P botnets come and go, and\r\nsome, for example, Mozi keep on going even though the author had been caught.\r\nThe early P2P botnets mainly targeted Windows machines, such as Storm, ZeroAccess and GameOver, which\r\nwere infected with the Windows operating system. after Mirai appeared in 2016, Linux IoT devices, which exist in\r\nlarge numbers on the network and lack some basic security defense, started to become the target of many botnets.\r\nFor example, Hijime, mozi, pink all target Linux devices.\r\nBecause of the \"centerless\" nature of P2P networks, it is somewhat difficult to assess their size using traditional\r\nmeans. To try to solve this problem, security researchers have invented P2P crawler technology, which can track a\r\nP2P botnet and obtain node IPs, download links and configuration information for scale assessment and targeted\r\nremoval.\r\nOur team(360 netlab) has been focusing on discovering and tracking active botnets for a long time, and P2P\r\nbotnets are surely on our radar. For example, we first disclosed the mozi botnet in 2019. In order to gain better\r\nvisibility, we built an industrial-level tracking system for P2P botnets, with the goal of covering major active P2P\r\nbotnets, This blog article will briefly analyze the current status of the following 5 families based on the tracking\r\ndata generated by this system.\r\n(In addition to the 5 families mentioned in this article, readers are also welcomed to leave comments below about\r\nnew|active families of interest, and we will look into them accordingly)\r\nOverview of tracking Strategy\r\nThis section will briefly introduce the main tracking strategies used in our tracking system.\r\nTracking Goals\r\nThe main goal of the system is to record the IPs of all the p2p nodes, we “create” a node by simulating the\r\ncommunication protocol, so it can join the corresponding P2P network to participate in the data message\r\nexchange. Every time a message exchange is successfully completed, the IP of the other party is recorded, this\r\ngoes on and on and finally the majority of the nodes from the target P2P network would be recorded.\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 1 of 10\n\nMethods\r\nThe protocol design of each P2P family varies, but following are some common strategies, normally at least one\r\nof these would be selected as the tracking method.\r\nActive Probe: This strategy is somewhat similar to a public network scanner in terms of working principle. It first\r\nfeeds probe messages to the target node, then parses the received reply messages, and identifies the peer as a peer\r\nnode when the returned message format matches the family characteristics. In practice, we will first delineate a\r\nprobe range and then probe the nodes within this range (where the probe range may consist of a suspicious\r\nnetwork segment or suspicious nodes generated from other policies).\r\nRecent communications：Common P2P families maintain a \"recent communications list\" of recent peers in each\r\nnode's memory. In some families, this list is also available to other nodes via specific commands, and would\r\ncommonly be used as a seed list when the node “boots up”, so that they can quickly join the P2P network. In this\r\ncase, we can discover more peer nodes by traversing this \"recent communication list\".\r\nNode heartbeat: When a node maintains a \"recent communication list\", it will send heartbeat messages to the\r\nnodes on the list periodically to declare its online status. Based on this, we can add the \"fake node\" to the other\r\nnode's active list to get the active status of the corresponding node at any time. In some cases, we also send\r\nheartbeat messages to ensure that we don’t get kicked out by the network.\r\nWait and see: \"Hajime\" and \"Mozi\", for example, use \"Distributed Hash Table\" to implement their P2P network\r\nstructure. This technique is designed to speed up data lookup by adding a rule of information-to-node distance and\r\nprioritizing the information to be stored on those nodes that are closer. Based on this rule, we can forge a “we-are-more-closer” node then wait for the arrival of other nodes. When other nodes try to obtain the information of the\r\ncorresponding family from the forged node, we can directly record the other IP as the tracking result.\r\nHow to read the Data\r\nTracking family selection basis\r\nWe consider the following two dimensions to screen the appropriate families for tracking to ensure the relative\r\nobjectivity of the final results.\r\nBased on size: When selecting families, the most priority indicator is that the size of the botnet has to be large, or\r\nonce historically large enough, in this case \"Hajime\"/\"Mozi\"/ “pink\" all stand out.\r\nRecent Disclosures: The next choice is the newly emerged ones that have been active at lease for a little while,\r\nbased on this, we have chosen \"panchan\" and \"frizefrog\" as they are newly discovered this year.\r\nSize of the infected bot nodes\r\nDepending on the type of the host device, the number of bot IPs does not necessarily reflect the true number of\r\ninfected devices.\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 2 of 10\n\nBots are servers: In order to provide stable services, the public IPs of servers usually do not change, so the\r\nnumbers are more accurate.\r\nBots are IoT devices: These devices are usually found in the residential network. We all know that the IP addresses\r\nof residents devices change frequently. This can lead to a large uncertainty in the mapping relationship between\r\nthe public IP and the device. Multiple devices might share a common public IP (NAT scenario), and devices can\r\nswitch to different IPs multiple times within a time window (dial-up Internet scenario).\r\nDaily activity of each family\r\nAs a comparison, if we take the daily activity of each Monday since August as a sample to plot the medium- and\r\nlong-term tracking graph, the following is shown.\r\nWe can clearly see the order of the family size:\r\nPink \u003e Hajime \u003e Mozi \u003e\u003e FritzFrog \u003c\u003e Panchan\r\nWe can see that the daily activity data of each family has not changed much over the three months period (see the\r\ndiscussion below for Pink's fluctuations in August)\r\nStatistics by family\r\nPink\r\nAt one point, the Pink family had infected more than one million devices in China, it has some cleverly designed\r\ncommand and control protocols. For time sensitive instructions, the control commands are pushed to the bots\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 3 of 10\n\nthrough a centralized mechanism, On the other hand, if the instructions are not urgent, P2P would be used. For\r\nmore information, please refer to our previous report.\r\n《Pink, a botnet that competed with the vendor to control the massive infected devices》\r\nGeographical distribution\r\nAs shown in the figure, Pink's scope of influence is mainly domestic IoT devices, and the following is its\r\ndistribution in China.\r\nDaily activity fluctuation\r\nIt is worth mentioning in particular that the daily activity data of the family has fluctuated greatly since July, first\r\ndropping by an order of magnitude in a week starting on July 12, reaching a daily activity of about 20,000, then\r\nreturning to zero for about 10 days after August 20, and then returning to 20,000 in September. The fluctuation of\r\ndaily activity can be seen in the following chart.\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 4 of 10\n\nNow let’s take a look at daily activity data of July 12, July 26 and September 1. It is easy to tell that the number of\r\ndaily activities in most provinces decreased significantly with time goes by.\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 5 of 10\n\nSo, it is very likely that starting from July, the major device vendor carried out a national wide clean up effort,\r\nresulting in a significant decrease in the number of infected devices.\r\nThe fluctuations in late August, on the other hand, are likely due to a national wide C2 blocking action in place.\r\nHajime\r\nHajime, which emerged in the same year as MIRAI, less than a few months apart, has been claimed to be run by\r\n\"white hats\" in its alert messages, and its components function with the primary goal of self-propagation. The\r\ncommunication and management between its components makes extensive use of asymmetric encryption and\r\ndecryption algorithms, making it an extremely classic P2P botnet family. We have covered this botnet in our\r\nprevious blog.\r\n《Is Hajime botnet dead?》\r\nGeographical distribution\r\nIran tops the list\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 6 of 10\n\nWe normally don’t see Iran on our security event list, but with Hajime infection, Iran is leading the pack, which is\r\npretty interesting. Please leave comments below if you have more insights.\r\nCPU distribution in Hajime\r\nHajime is a P2P network built on file exchanging and each Hajime bot tries to find the latest version of .i.xxx and\r\natk.xxx files (e.g. atk.arm7/.i.arm7) when it runs. This gives us an opportunity to evaluate the CPU distribution in\r\nthe \"Hajime network\". When the Hajime node asks us which nodes contain the corresponding files, we gets a\r\nDHT.search count. When a Hajime node asks us to download the corresponding file, we gets a uTP.Request count.\r\nPutting these two types of files and two types of counts together, we would have the following four pie charts:\r\nBased on the above pie charts, we can see that MIPS based bots are the majority in the Hajime network, far\r\nexceeding the sum of the other types of hosts, while MIPSEL has the fewest host nodes.\r\nIf we consider that Hajime had integrated a large number of vulnerabilities for propagation, this data can even\r\nreflect to some extent the distribution of each type of CPU in smart devices.\r\nMozi\r\nMozi started out as a P2P family performing DDoS attacks for profits, and later added a mining component. Its\r\nnetwork topology is built on the basis of the DHT protocol. More information can be found in our previously\r\npublished reports.\r\n《Mozi, Another Botnet Using DHT》\r\n《The Mostly Dead Mozi and Its’ Lingering Bots》\r\nGeographical Distribution\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 7 of 10\n\nFritzFrog\r\nFritzFrog is a mining P2P family which relies on SSH services to build P2P networks. It was first disclosed by\r\nakamai. More details can be found in the following report (interestingly, FritzFrog wallet address is related to\r\nMozi).\r\n《FritzFrog: P2P Botnet Hops Back on the Scene》\r\nGeographical Distribution\r\nAccount Passwords in FritzFrog\r\nSince FritzFrog's P2P is based on SSH implementation, the password of the infected nodes are reflected in the\r\ncrawled data, the following are the top passwords.\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 8 of 10\n\nThe No.1 weak password starts with 1 , can anyone take a guess what it is?\r\nPanchan\r\nPanchan is a mining P2P botnet developed in Go language, it also uses SSH weak passwords for propagation. Its\r\ncode contains a lot of Japanese katakana, which suggests that Panchan's developers are fluent in Japanese. Another\r\ninteresting point is that it implements an interactive console on the listening port, using the idea of protocol reuse,\r\nallowing administrators to perform some simple queries and management of the nodes from the network. More\r\ndetailed information can be found in the following Akamai report.\r\n《Panchan’s Mining Rig: New Golang Peer-to-Peer Botnet Says “Hi!”》\r\nGeographic Distribution\r\nConclusion\r\nNormally we end our blog with some conclusion, do we have one here? Not really, we just want to shout out to\r\nour readers again: if you have seen some interesting p2p botnet, leave a comment, shoot us an\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 9 of 10\n\nemail(netlab[at]360.cn) or on twitter.\r\nSource: https://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nhttps://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.netlab.360.com/p2p-botnets-review-status-continuous-monitoring/"
	],
	"report_names": [
		"p2p-botnets-review-status-continuous-monitoring"
	],
	"threat_actors": [],
	"ts_created_at": 1775434218,
	"ts_updated_at": 1775791256,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/043fa6a320306de65290cb472005ad3930032bee.pdf",
		"text": "https://archive.orkl.eu/043fa6a320306de65290cb472005ad3930032bee.txt",
		"img": "https://archive.orkl.eu/043fa6a320306de65290cb472005ad3930032bee.jpg"
	}
}