{
	"id": "114bd172-ea8c-4cf0-b00f-d6232412b1ed",
	"created_at": "2026-04-06T00:10:42.516312Z",
	"updated_at": "2026-04-10T03:22:04.013553Z",
	"deleted_at": null,
	"sha1_hash": "2856ccbd6b4c621075358eb2e2cc5818d2ee644c",
	"title": "Necurs Proxy Module With DDOS Features",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2116794,
	"plain_text": "Necurs Proxy Module With DDOS Features\r\nBy Sofia Luis\r\nPublished: 2017-02-24 · Archived: 2026-04-05 20:55:26 UTC\r\nWritten by Sofia Luis\r\nMarketing Manager, EMEA \u0026 APAC\r\nNecurs is a malware that is mainly known for sending large spam campaigns, most notably the Locky\r\nransomware. However, Necurs is not only a spambot, it is a modular piece of malware that is composed of a main\r\nbot module, a userland rootkit and it can dynamically load additional modules.\r\nHaving been around for a few years, this malware has been subject to a lot of great research that has covered many\r\nof its aspects including the rootkit, the DGA, the communication protocol and the spam module. However, there\r\nhas not been much public information on any modules loaded by Necurs besides the spam module.\r\nAbout six months ago we noticed that besides the usual port 80 communications, a Necurs infected system was\r\ncommunicating with a set of IPs on a different port using, what appeared to be, a different protocol. The following\r\nimage shows an example of this network traffic.\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 1 of 13\n\nRecently, while decrypting the C2 communication of the a Necurs bot, we observed a request to load two different\r\nmodules, each with a different parameter list. The following is the decrypted translation of the modules section of\r\nthe C2 response:\r\nThe first one was the spam module for which Necurs is most known, and the parameters are the C2 addresses\r\nfrom which it can receive new spam campaigns. The second one was an unknown module and, judging by the\r\nparameter values, it was the one responsible for the communication we were seeing to port 5222.\r\nWe noticed this module in September 2016 and the compilation timestamp on the module is “Aug 23 2016”,\r\nwhich suggests the module started being used around then. However, it is possible that another version of the\r\nsame module had been deployed before, without being noticed.\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 2 of 13\n\nWe downloaded the module and reverse engineered it to try to understand exactly what it was. At first look, it\r\nseemed to be a simple SOCKS/HTTP proxy module, but as we looked at the commands the bot would accept from\r\nthe C2 we realized that there was an additional command, that would cause the bot to start making HTTP or UDP\r\nrequests to an arbitrary target in an endless loop, in a way that could only be explained as a DDOS attack. This is\r\nparticularly interesting considering the size of the Necurs botnets (the largest one, where this module was being\r\nloaded, has over 1 million active infections each 24 hours, we blogged about it here). A botnet this big can likely\r\nproduce a very powerfull DDOS attack.\r\nPlease notice that we have not seen Necurs being used for DDOS attacks, we simply saw that it has that\r\ncapability in one of the modules that it has been loading.\r\nThe rest of this post contains the results of a technical analysis of this module, detailing its C2 protocol, the\r\nSOCKS/HTTP proxy features, and the DDOS attack features.\r\nModule start/initialization\r\nOnce the module is loaded by the bot, it performs the following initialization actions:\r\nParses the parameters and stores them in an internal list of C2 addresses;\r\nFills a memory structure (see botsettings struct definition below) with:\r\nThe BotID - Generated through gathering unique system characteristics;\r\nThe internal IP address - Obtained by checking the outbound sockets IP address when connecting\r\nto google.com;\r\nThe external IP address - Obtained trough HTTP from ipv4.icanhazip.com or checkip.dyndns.org;\r\nThe available bandwidth - Obtained by measuring the download speed of the Windows 7 Service\r\nPack 1 file from microsoft;\r\nThe (socks/http) proxy service port - The port of the service listening on a random port above\r\n1024;\r\nChecks if the system is behind NAT - By checking if the outbound socket IP is not a local address and\r\nthat it matches the external IP;\r\nIf the system is not behind NAT, the bot starts a SOCKS/HTTP proxy service listening on a random port\r\nabove 1024.\r\nThe botsettings struct can be defined as follows:\r\nC2 communication protocol\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 3 of 13\n\nAfter initialization, the bot will enter the main C2 connection loop, where it will attempt to connect to the current\r\nC2 every 10 seconds, unless instructed otherwise. If the connection to the current C2 fails, it will fetch another\r\nfrom the address list and try again.\r\nThe communication protocol is binary and encrypted/obfuscated using a custom algorithm. Messages to, and\r\nfrom, the server have a very similar structure (see struct botmsg and c2msg definitions below) and contain the\r\nfollowing data:\r\nKey - A 32 bit encryption key;\r\nEncrypted header - A header structure (see struct botmsgheader and c2msgheader definitions below),\r\nencrypted with the key and containing:\r\nMessage type - A byte that defines the type of message/command being sent;\r\nPayload length - The length of the payload being sent;\r\nHeader hash - A hash of the first bytes of the message (key, msgtype, unknown and datalength);\r\nData hash - A hash of the payload, used for integrity checking;\r\nEncrypted payload - An array of data being sent, encrypted with the reverse value of the key.\r\nThere are three types of messages sent by the bot to the C2, that can be distinguished by the msgtype byte in the\r\nheader:\r\nBeacon (msgtype 0) - This is the main message that is sent by the bot every 10 seconds. It sends the\r\nbotsettingsstruct described previously as a payload;\r\nConnectivity check (msgtype 1) - This is a simple dummy message that contains no data besides the\r\nencrypted message header. It is sent in case a timeout occurs to the current C2 to make sure it is no longer\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 4 of 13\n\navailable;\r\nProxybackconnect (msgtype 2) - This message is sent in case the bot receives the command to start a\r\nsocks backconnect. This will start a connection to the C2 that will be reused for the SOCKS/HTTP proxy\r\nconnection, proceeding as if it had been initiated by the proxy client.\r\nAs a response to the beacon, there are also three types of messages (or commands) sent by the C2 to the bot, that\r\ncan be distinguished by the msgtype byte in the header:\r\nStart Proxybackconnect (msgtype 1) - This command tells the bot to start a backconnect proxy session by\r\nsending a proxybackconnect message from the bot to the C2. This connection’s socket will be reused and\r\nallows the bot to be used as a proxy even behind a firewall and without establishing a direct connection to\r\nit;\r\nSleep (msgtype 2) - This will cause the bot to sleep for 5 minutes;\r\nStart DDOS (msgtype 5) - This command will start a DDOS attack against the target specified in the\r\nmessage payload using one of two available attack modes:\r\nHTTPFlood: If the first bytes of the message payload are the string “http:/”, the bot will start an\r\nHTTP flood attack against the target;\r\nUDPFlood: If the first bytes of the message payload are not the string “http:/”, the bot will start an\r\nUDP flood attack against the target.\r\nProxy features\r\nThe SOCKS/HTTP proxy service and command, allows the botnet owners to use the compromised bots as proxies\r\n(HTTP, SOCKSv4 and SOCKSv5 protocols), relaying connections through them in two modes of operation\r\n(direct proxy and proxy backconnect).\r\nIn direct proxy mode, the client connects to the proxy service, which will forward the communication to the\r\ndestination, as in the following image:\r\nThis is only possible if the bot is not protected behind NAT or a firewall, which is not the case in the vast majority\r\nof the botnet.\r\nIn proxy backconnect mode, the client connects to the proxy controller, that will then obtain an outbound proxy\r\nfrom a pool of available proxies and relay the connection through it. The following diagram illustrates the system:\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 5 of 13\n\nThere are several advantages to this operation mode. The main ones being that it works even if the infected system\r\nis behind NAT and it will allow a connection to internal network resources as if it came from the infected\r\nmachine. Another common use for these kind of proxies is to have a constantly changing IP address, by constantly\r\nand automatically changing the bot serving as proxy.\r\nTaking a brief view at how this is implemented, the following image shows part of the function that processes the\r\nC2 commands.\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 6 of 13\n\nIn case the bot receives a startproxybackconnect command (msgtype 1), the bot will send a proxybackconnect\r\nmessage to the C2 (msgtype 2) and then the same socket that is used in the C2 communication (globalsocket) to\r\nthe startprocessincoming function that does the actual proxying work. This means that the same connection used\r\nfor C2 communication will then be used to proxy the connections.\r\nThe processincomming function reads 2 bytes from the incoming connection (direct or through backconnect) and\r\nchecks if the first has the value 5 (Socks v5 protocol), 4 (Socks v4 protocol) or if it is alphanumeric (HTTP\r\nProxy). It then calls the appropriate function that does the actual proxying work for each of the supported\r\nprotocols.\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 7 of 13\n\nDDOS attack features\r\nPossibly the most interesting, and unexpected, feature of this module is the DDOS attack mode. The module\r\ncontains two very basic DDOS attack modes, that don’t have special features like origin IP address spoofing or\r\namplification techniques. However, given the size of the Necurs botnets (more than 1M IP/24 hours in the largest\r\nbotnet), even the most basic techniques should produce a very powerful attack.\r\nTaking a brief look at how it is implemented, if the bot receives the startDDOS command (msgtype 5) the payload\r\nportion of message is parsed looking for the string “http:/”. If it is found, the HTTPflood function is called, if not,\r\nthe UDPFlood function is called, as shown in the following image:\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 8 of 13\n\nThe HTTP attack works by starting 16 threads that perform an endless loop of HTTP requests. The following\r\nimages show the 16 threads being queued and the section of the code that sends the HTTP request:\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 9 of 13\n\nThe HTTP request is built using the following format string:\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 10 of 13\n\nThe UDP flood attack works by repeatedly sending a random payload with size between 128 and 1024 bytes. The\r\nfunction contains a 0.1 second sleep that may be triggered depending on the available bandwidth (calculated\r\nduring bot initialization), possibly to avoid losing access to the bot during a DDOS attack. The following image\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 11 of 13\n\nshows the UDPFlood main loop:\r\nAlthough known mainly for its spam module, Necurs is a modular malware that can be used for many different\r\npurposes. In this blog post we detailed a module that adds SOCKS/HTTP proxy and DDOS capabilities to this\r\nmalware. Although we have not seen Necurs being used to perform DDOS attacks, this capability is currently\r\ndeployed in the infected systems and taking into account the size of the botnet it could produce a powerful attack.\r\nFor more information about the Necurs Botnet, check out the following links:\r\nhttps://www.virusbulletin.com/virusbulletin/2014/04/curse-necurs-part-1\r\nhttps://www.virusbulletin.com/virusbulletin/2014/05/curse-necurs-part-2\r\nhttps://www.virusbulletin.com/virusbulletin/2014/06/curse-necurs-part-3\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 12 of 13\n\nhttps://www.johannesbader.ch/2015/02/the-dgas-of-necurs/\r\nhttp://www.malwaretech.com/2016/02/necursp2p-hybrid-peer-to-peer-necurs.html\r\nhttps://www.cert.pl/en/news/single/necurs-hybrid-spam-botnet/\r\nAnalysed module sample:\r\nf3aeafe50880cb9dd584b3669800c017de561f8f9654440f62c51319fda0e970\r\nSource: https://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nhttps://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.bitsighttech.com/blog/necurs-proxy-module-with-ddos-features"
	],
	"report_names": [
		"necurs-proxy-module-with-ddos-features"
	],
	"threat_actors": [],
	"ts_created_at": 1775434242,
	"ts_updated_at": 1775791324,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2856ccbd6b4c621075358eb2e2cc5818d2ee644c.pdf",
		"text": "https://archive.orkl.eu/2856ccbd6b4c621075358eb2e2cc5818d2ee644c.txt",
		"img": "https://archive.orkl.eu/2856ccbd6b4c621075358eb2e2cc5818d2ee644c.jpg"
	}
}