{
	"id": "20674ff1-ca67-4616-aa8b-784a6ce31a18",
	"created_at": "2026-04-06T00:11:05.950559Z",
	"updated_at": "2026-04-10T13:12:14.733041Z",
	"deleted_at": null,
	"sha1_hash": "51a66436fe6d5894bb6c10181e1ddf28ad74a160",
	"title": "Is Hajime botnet dead?",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 403757,
	"plain_text": "Is Hajime botnet dead?\r\nBy RootKiter\r\nPublished: 2017-09-20 · Archived: 2026-04-05 19:41:31 UTC\r\nOverview\r\nThe mysterious Hajime botnet was first discovered by Rapiditynetworks in Oct 2016, and it was all over the news\r\nearlier this year, but it seems that nobody talks about it any more now, is this botnet gone?\r\nThe answer is no, our team has been tracking this botnet for quite some time, and we have recently noticed the\r\nnumber of infections has been going up, and a very interesting feature, an x64 config has been added in the\r\ncode(is the botnet author eying PC platform as the next target? Or key leaked?).\r\nUnlike the traditional Hajime-runs-in-sandbox solution, which really has no control over the bot besides merely\r\nobserving it(a good example, researcher cannot ask the bot in sandbox to go over all the peering nodes and pull all\r\nthe files).\r\nOur team was able to figure out the key exchange scheme of this botnet so we are able to participate in the Hajime\r\nnetwork with full control of the bot behaviors, with that, we have been able to gain more insights. The visibility of\r\nthis botnet is fairly poor in security research field, with the two observations above, we decide to talk about this\r\nbotnet a little bit and also start a public accessible Hajime tracking project here\r\nHow Hajime works\r\nFor some basic concepts of Hajime botnet, we suggest readers to take a good look at the Rapiditynetworks paper\r\nhere so we don’t need to repeat known facts here.\r\nOverall framework\r\nHajime’s implementation follows the modular programming paradigm. There are two common executable\r\nmodules: \"execution module” (also known as stage2 or .i module) and “propagation module\" (also known as atk\r\nmodule).\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 1 of 10\n\nIn the propagation module (.i module), the Hajime nodes will establish a P2P network based on the DHT protocol.\r\nOn top of this P2P network, Hajime nodes can perform inter-node negotiation, control command transmission and\r\nfile synchronization. Any node can obtain the control instructions from the administrator without direct\r\ncommunication to the administrator. This not only provides protection for the administrator, but also maintains the\r\nstability of the botnet itself. Once the network is set up, it is extremely difficult to take it down.\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 2 of 10\n\nIn the DHT network, Hajime encodes the config file as a special infohash value. This is a 160 bit binary number,\r\nchanged daily. By indexing the infohash value, Hajime can get the latest config file.\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 3 of 10\n\nThe above figure shows a config file in August 12, 2017. You can see it is a text file. The modules field contains\r\nthe module file name for different CPU architectures. The peers field specifies the entry domain name for the\r\nDHT network. The two domain names are both valid and publicly accessible. The configuration file will direct\r\nHajime to synchronize to the latest \"propagation module (atk module)\" or “execution module (.i module)\".\r\nFile synchronization\r\nIn a DHT network, each Hajime node can correspond to a peer. By searching in the DHT network, the Hajime\r\nnode can easily get the address information of other Hajime nodes. During file synchronization, it will traverse\r\nother nodes sequentially and perform synchronization on each node. The inter-node communication relies on the\r\nuTP protocol. This protocol implements mechanisms such as three-way handshake, session retransmission and\r\nsession interruption based on UDP to ensure trusted communication between Hajime nodes.\r\nKey exchange\r\nOn the channel provided by uTP, Hajime made the RC4 communication encryption for each session to ensure that\r\nothers could not restore the content by packet capture. Besides, Hajime uses a key negotiation algorithm to ensure\r\nthat the RC4 key is not stealable.\r\nHajime uses ECDH as the key exchange protocol and selects a key exchange algorithm based on Curve25519\r\nelliptic curve. Although there are many open ECDH implementations on the Internet, the author of Hajime did not\r\nuse the existing code directly. He has implemented a more efficient key exchange process. This implementation\r\nfeatures on projecting points from the original elliptical space to the new one-dimensional series. Besides, in the\r\n\"double point\" calculation process, it only calculates the X coordinates, without considering the Y coordinates.\r\nTherefore he can improve the computational efficiency.\r\nReference for Curve25519 can be found at: https://cr.yp.to/ecdh.html\r\nThe fundamentals for the new key exchange algorithm can be found at https://cr.yp.to/ecdh/curvezero-20060726.pdf\r\nDocument Signature\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 4 of 10\n\nIn P2P networks, nodes are untrustworthy, and anyone can fake a Hajime node at a very low cost. To ensure that\r\nthe Hajime network is completely controllable and not stolen by others, Hajime nodes need to verify the signature\r\nof each synchronized file before acceptance and execution. Hajime adopts a public digital signature algorithm\r\ncalled ED25519 and uses A55CEED41FECB3AC66B6515AB5D383791B00FEC166A590D7626A04C2466B3F54 as public key,\r\nwhich is integrated into each Hajime's execution module. Thus every Hajime nodes can verify the integrity of an\r\nnew synchronized file.\r\nCurrent status\r\nThe following diagram shows daily active hijime nodes since the beginning of July.\r\nDaily active nodes\r\nBelow shows the number of daily active IPs:\r\nIt is not difficult to spot that in the second half of July, Hajime infection went down. Correspondently there were\r\nno botnet file update during that period(did the author go for vacation?) Starting from August, the author started to\r\nupdate the Hajime files, and the bot numbers started to going up, noticeably on 2017-08-06 and 2017-08-12, with\r\nthe author pushing update, the botnet climbed up really quickly. Subsequently, Hajime completed several updates\r\non 2017-08-18, 2017-08-19, 2017-08-22 and 2017-09-04. This opened the new normality of frequent updates.\r\nGeographical distribution\r\nThe following figure shows the geographical activity of Hajime in the past two months:\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 5 of 10\n\nThe deeper the color, the more serious the affected area.\r\nUpdate frequency\r\nHajime was not updated frequently in July, and there was a two-week break. However, after August 5, Hajime\r\nbegan to regain activity:\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 6 of 10\n\nIn fact, all updates in the past month are patches on the existing code. There’s no dramatic change.\r\nUpdate on bot propagation\r\nOriginally,Hajime propagated mainly thought TR_069 vulnerability and weak telnet account, as time goes by,\r\nmore vulnerabilities have been added, and the following is the newest vulnerability breakdown.\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 7 of 10\n\n2017-01-17 atk.arm5.1481380646 2487b4ed4a2f55bfd743b2e6b98f8121\r\n2017-05-29 atk.arm5.1496096402 a238462e1e758792c5d1f04b82f4a6a0\r\nhttp://console-cowboys.blogspot.com/2013/01/swann-song-dvr-insecurity.html\r\nhttps://gist.github.com/ylluminate/fcee91965b58695460ce849c424488f7\r\nhttps://twitter.com/masafuminegishi/status/870182653797871617\r\nCPU Architecture Distribution of Hajime Node\r\nThe propagation of Hajime is limited among a small number of different CPUs. Our analysis on 18433 Hajime\r\nnodes shows that the Mipseb CPU is affected the most.\r\nMore Observations on Hajime\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 8 of 10\n\nSupport for x64 platform?\r\nOur tracking system captured a special config file b8a5082689606ea20a557883dbff7d10 on 2017-08-29.\r\nThis config file can be verified successfully and contained settings for X64 CPU, which indicated that Hajime\r\nauthor is planning to support PC platforms.\r\nThe config file is shown as followed:\r\nHowever there are some doubts in this config file:\r\nWe can only get two modules (atk.mipseb/.i.mipseb) listed in the config file while other CPU architecture's\r\nmodules are unavailable in Hajime network.\r\nThe \"info\" field, which contains the author's whitehat declaration, is missing in this config file. This is\r\nquite abnormal according to author's previous habit.\r\nSo we have two possibilities here:\r\nThe author has intention to support x64 platform. As mentioned before, all Hajime files are signed by the\r\nprivate key and need to be verified before any Hajime node takes the update.\r\nThe private key has been leaked, someone else is trying to poison the Hajime network.\r\nWe prefer the first scenario at this point, and it will be big change for Hajime itself if it is moving to the pc\r\nbattleground. We will keep a close eye on what will unfold in the future.\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 9 of 10\n\n1: https://x86.re/blog/hajime-a-follow-up/\r\n2: https://github.com/Psychotropos/hajime_hashes\r\n3: https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf\r\n4: https://securelist.com/hajime-the-mysterious-evolving-botnet/78160/\r\nSource: http://blog.netlab.360.com/hajime-status-report-en/\r\nhttp://blog.netlab.360.com/hajime-status-report-en/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://blog.netlab.360.com/hajime-status-report-en/"
	],
	"report_names": [
		"hajime-status-report-en"
	],
	"threat_actors": [],
	"ts_created_at": 1775434265,
	"ts_updated_at": 1775826734,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/51a66436fe6d5894bb6c10181e1ddf28ad74a160.pdf",
		"text": "https://archive.orkl.eu/51a66436fe6d5894bb6c10181e1ddf28ad74a160.txt",
		"img": "https://archive.orkl.eu/51a66436fe6d5894bb6c10181e1ddf28ad74a160.jpg"
	}
}