{
	"id": "7ed2e3fa-2e20-4124-81b4-e8dfd881c99f",
	"created_at": "2026-04-06T00:19:44.431437Z",
	"updated_at": "2026-04-10T03:20:18.394844Z",
	"deleted_at": null,
	"sha1_hash": "3b0c597524e21aa4adebee9a676e1df1a385abd6",
	"title": "Necurs.P2P – A New Hybrid Peer-to-Peer Botnet",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 220184,
	"plain_text": "Necurs.P2P – A New Hybrid Peer-to-Peer Botnet\r\nBy Marcus Hutchins\r\nPublished: 2016-02-22 · Archived: 2026-04-05 19:13:36 UTC\r\nLast week I received a tip about a sample displaying some indication that it could be peer-to-peer (a large amount\r\nof UDP traffic being sent to residential IPs), after a couple days of analysis I was able to confirm that not only was\r\nit peer-to-peer but also currently active. The person who tipped me off was friend and researcher R136a1 who\r\nseems to be on a roll lately (not only did he find this, but was also the one who found ZeroAccess3 as well as the\r\nidentities of the authors), you should definitely follow him if you haven’t already.After a bit of searching I was\r\nable to find a SANS blog post from May 2015 about a Necurs sample with similarities to ours; however, there was\r\nno mention of what the UDP traffic was for. I was also able to find a much older post by blue coat from September\r\n2013 which detailed a Necurs variant using .bit (Namecoin) domains for the C\u0026C. I’m not 100% certain, but I\r\nbelieve this to be a variant of the original Necurs, that is, before the rootkit was sold to groups like the one behind\r\nZeus GameOver.\r\nInstallation Process\r\nUpon install…\r\nhttps://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nPage 1 of 5\n\n…nevermind.\r\nAfter a quick check we can see that the cause of the BSOD is anti-virtualization code embedded with the malware,\r\nthough the way it’s caused is strange. Upon detection of a virtual environment, the malware begins injecting all\r\nprocesses with a simple routine which sets up an exception handler and executes the VMCPUID.\r\nWhat’s interesting is the VMCPUID instruction is only implemented on some virtual machines and will return the\r\nVM’s CPUID, if unimplemented it will generate an invalid instruction exception which will need to be caught by\r\nan exception handler. When the function is injected into every process it is unable to set up a correct exception\r\nhandler because the exception context is stored in the .rdata section of the bot’s process and isn’t copied along\r\nwith the function; as a result, if the system is detected as a VM but doesn’t implement VMCPUID every process\r\nwill crash and the system will BSOD. My guess is the coders were trying to implement some kind of injectable\r\nVM check but it kept crashing the VM, so they just left it as an obscure anti-virtualization measure (though it\r\nshouldn’t crash any VMs that implement the VMCPUID instruction).\r\nUpon successful execution the bot elevates itself using CVE-2010-4398 then copies it’s executable to\r\nC:Installers{BotGUID}syshost.exe and driver to C:Drivers{RandomName}.sys. The executable is set as an auto-start service and the driver is set as a boot device (if required, the bot will enable TESTSIGNING mode to allow\r\nloading of unsigned drivers), afterwards the system is rebooted.\r\nAfter reboot the bot will attempt to use the netsh.exe to whitelist it’s own process in the firewall (on Windows XP\r\nit will just disable the firewall completely). |\r\nhttps://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nPage 2 of 5\n\n| |—| | Attempting to whitelist itself using netsh.exe |\r\nPeer-to-Peer Communication\r\nThis C\u0026C structure is something referred to as “hybrid P2P” because commands are sent from centralized C\u0026C\r\nservers just like in a regular botnet; however, because new C\u0026C server addresses can be pushed to all bots via the\r\npeer-to-peer network at any time, the botnet maintains the usability of a traditional botnet, but with the resilience\r\nof a peer-to-peer one.In order to enable P2P communication a random port number is generated and stored into the\r\nregistry; this port is then bound on both the UDP and TCP protocol allowing P2P communication to work over\r\neither, though udp is the most dominant. The bot has over 1000 IP and port combinations stored within the initial\r\nconfig which will be contacted one by one at a rate of one per second until a reply is received, after that the rate is\r\nadjusted to one per minute. Strangely before every request a random number from 0 to 4 is chosen: if the number\r\nis 0 the bot will attempt to connect to the remote host over TCP, otherwise it will fire off a UDP packet, resulting\r\nin a UDP:TCP ratio of around 4:1 (I’m unsure as to what the purpose of this is). |\r\nhttps://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nPage 3 of 5\n\n| |—| | P2P protocol\r\nhandling routine |\r\nAll peers reply to requests with a payload signed by the botmaster’s 2048-bit RSA key (preventing anyone other\r\nthan them from introducing new response payloads). P2P payloads can contain any or all of 3 block types:\r\nDNS Block – A list of Namecoin DNS servers which will allow the bot to use Namecoin’s .bit domains to\r\nresolve C\u0026C servers.\r\nC\u0026C Block – A list of C\u0026C server IPs.\r\nUpdate Block – Allows updates to be sent over the P2P network (likely only used in the case that all other\r\nC\u0026C methods are offline).\r\nNotably there is no peer exchange functionality in the P2P protocol, which is because instead of trusting peers to\r\nshare peer information among themselves, the botmasters have opted to generate peer lists themselves and publish\r\nthem via the C\u0026C server. By distributing peers this way it is easier to prevent poisoning attacks as the list can be\r\nhttps://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nPage 4 of 5\n\nchecked for IPs belonging to datacenters or security companies which would likely harm the botnet. The main\r\ndrawback of this specific implementation is the botmasters send out a huge peer list with ~2000 IPs to replace the\r\nprevious one each time, so rather than keeping track of online IPs the bots just iterate the peer list until they find\r\nan online peer, which generates a lot of failed connections and is a good indicator of infection. If the bot is unable\r\nto connect to any peers within 5 minutes of booting up, it begins the DGA routine and starts spamming DNS\r\nrequests (in my tests it took at least 15 minutes to successfully connect to a peer, so DGA always began\r\nexecution).\r\nPayloads Storage\r\nAnything downloaded from the C\u0026C or P2P network gets stored in the temp folder with a UUID for the file name\r\nand .tmp for the extension; the UUID is generated by SHA1 hashing the bot identifier with a static 64-bit integer\r\n(used to identify the content of the file). |\r\n| |—| | File name generator |\r\nFiles are encrypted with RC4 using a key derived with the same function as above, except a randomly generated\r\nvariables is hashed alongside the data and then stored at the end of the file, making generating file signatures\r\nimpossible.\r\nSource: https://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nhttps://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html"
	],
	"report_names": [
		"necursp2p-hybrid-peer-to-peer-necurs.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434784,
	"ts_updated_at": 1775791218,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3b0c597524e21aa4adebee9a676e1df1a385abd6.pdf",
		"text": "https://archive.orkl.eu/3b0c597524e21aa4adebee9a676e1df1a385abd6.txt",
		"img": "https://archive.orkl.eu/3b0c597524e21aa4adebee9a676e1df1a385abd6.jpg"
	}
}