{
	"id": "26aa7c28-58e2-4b82-9ce5-3c0bbc444617",
	"created_at": "2026-04-06T00:19:58.288882Z",
	"updated_at": "2026-04-10T03:21:25.186342Z",
	"deleted_at": null,
	"sha1_hash": "dff6b382daa307cd7fb212184b082c17ec24ca80",
	"title": "Black DDoS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 442789,
	"plain_text": "Black DDoS\r\nBy Dmitry Tarakanov\r\nPublished: 2010-07-15 · Archived: 2026-04-05 17:02:29 UTC\r\nCybercriminals use a variety of bots to conduct DDoS attacks on Internet servers. One of the most popular tools is\r\ncalled Black Energy. To date, Kaspersky Lab has identified and implemented detection for over 4,000\r\nmodifications of this malicious program. In mid-2008 malware writers made significant modifications to the\r\noriginal version, creating Black Energy 2 (which Kaspersky Lab detects as Backdoor.Win32.Blakken). This\r\nmalicious program is the subject of this article.\r\nStep-by-step: the bot components\r\nThe bot has several main functions: it hides the malware code from antivirus products, infects system processes\r\nand, finally, offers flexible options for conducting a range of malicious activities on an infected computer when\r\ncommands are received from the botnet command-and-control (C\u0026C) center. Each task is performed by a\r\ndifferent component of the malicious program.\r\nFigure 1. A step-by-step guide to how Black Energy 2 works\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 1 of 11\n\nThe protective layer\r\nLike most other malicious programs, Black Energy 2 has a protective layer that hides the malicious payload from\r\nantivirus products. This includes encryption and code compression; anti-emulation techniques can also be used.\r\nOnce the Black Energy 2 executable is launched on a computer, the malicious application allocates virtual\r\nmemory, copies its decryptor code to the memory allocated and then passes control to the decryptor.\r\nExecution of the decryptor code results in code with dropper functionality being placed in memory. Once the\r\ndropper code is executed, a decryptor driver with a random name, e.g. “EIBCRDZB.SYS”, is created in\r\nsystem32drivers. A service (which also has a random name) associated with the driver is then created and started:\r\nFigure 2. The launch of the malicious decryptor driver\r\nLike the original executable, this driver is, in effect, a ‘wrapper’ that hides the most interesting part of the\r\nmalware.\r\nThe infector\r\nThe code of the decryptor driver contains a block of encrypted and packed data:\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 2 of 11\n\nFigure 3. Encrypted data within the decryptor driver\r\nThe data block has the following structure:\r\nFigure 4. Encrypted data structure\r\nThe key from this block is used to create another key, 100h bytes in size, which is used to decrypt the archive. The\r\nencryption is based on the well-known RC4 algorithm. If the archive size is equal to the data size, it means that\r\nthe data is not packed. However, if the two do not coincide, the encrypted archive has to be unpacked.\r\nThe decrypted data is an infector driver which will inject a DLL into the svchost.exe user-mode process. In order\r\nto launch the infector driver, the decryptor driver allocates memory, copies the decrypted code to that memory\r\narea, remaps address offset fixups and passes control to it. The malicious DLL is stored in the .bdata section of the\r\ninfector driver. This data block has the same structure as that described above. The infector driver locates the\r\nsvchost.exe process and allocates memory in its address space. The malicious DLL is then copied to this memory\r\narea and address offsets are remapped according to the relocation table. The injected library’s code is then\r\nlaunched from kernel mode as shown below:\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 3 of 11\n\nFigure 5. Launching the DLL injected into svchost.exe\r\nThis method uses APC queue processing. First, an APC with the address of the DllEntry function for the library\r\ninjected is initialized, then the APC is queued using KeInsertQueueApc APC. As soon as svchost.exe is ready to\r\nprocess the APC queue (which is almost immediately), a thread from the DllEntry address is launched in its\r\ncontext.\r\nThe injected DLL\r\nThe DLL which is injected into svchost.exe is the main controlling factor in launching a DDoS attack from an\r\ninfected computer. Like the infector driver, the DLL has a .bdata section; this includes a block of encrypted data,\r\nwhich has the same structure as that shown above. The data makes up an xml document that defines the bot’s\r\ninitial configuration. This screenshot gives an example:\r\nFigure 6. The bot’s initial settings\r\nThe address of the botnet’s C\u0026C is of course the most important information. In this case, two addresses are given\r\nfor the sake of reliability: if one server is down and the bot is unable to contact it, the bot can attempt to connect to\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 4 of 11\n\nits owner using the backup address.\r\nThe bot sends a preformed http request to the C\u0026C address; this is a string containing data which identifies the\r\ninfected machine. A sample string is shown below:\r\nid=xCOMPUTERNAME_62CF4DEF\u0026ln=ru\u0026cn=RU\u0026nt=2600\u0026bid=3\r\nThe id parameter, which is the infected machine’s identifier, includes the computer name and the serial number of\r\nthe hard disk on which the C: drive is located. This is followed by operating system data: system language, OS\r\ninstallation country and system build number. The build identifier for the bot ( ‘build_id’ in the initial\r\nconfiguration options xml document) completes the string.\r\nThe format of the request string is used as confirmation that the request actually comes from the bot. In addition,\r\nthe C\u0026C center also uses the user-agent header of the http request as a password of sorts.\r\nIf the C\u0026C accepts the request, it responds with a bot configuration file which is also an encrypted xml document.\r\nRC4 is also used to encrypt this file, with the infected machine’s identifier (the id parameter of the request string,\r\nin the example above – xCOMPUTERNAME_62CF4DEF) serving as a key.\r\nHere is an example of such instructions:\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 5 of 11\n\nFigure 7. Configuration file – instructions from the C\u0026C\r\nThe section tells the bot which modules are available on the owner’s server to set up a DDoS attack. If the bot\r\ndoes not have a particular module or if a newer version is available on the server, the bot will send a plug-in\r\ndownload request to the server, e.g.:\r\ngetp=http\u0026id=xCOMPUTERNAME_62CF4DEF \u0026ln=ru\u0026cn=RU\u0026nt=2600\u0026bid=3\r\nA plug-in is a DLL library, which is sent to the bot in an encrypted form. If the key used to encrypt a plugin differs\r\nfrom the value of the id parameter, it will be specified in the field of the configuration file. Once the plug-in DLL\r\nhas been received and decrypted, it will be placed in the memory area allocated. It is then ready to begin a DDoS\r\nattack as soon as the appropriate command is received.\r\nPlug-ins will be regularly downloaded to infected machines: as soon as the malware writer updates their attack\r\nmethods, the Black Energy 2 bot will download the latest version of the relevant plugin.\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 6 of 11\n\nThe downloaded plug-ins are saved to the infected computer’s hard drive as str.sys in system32drivers. Str.sys is\r\nencrypted, with the id parameter being used as the key. Prior to encryption, the str.sys data looks like this:\r\nFigure 8. Unencrypted contents of str.sys: plug-in storage\r\nEach plug-in has an exported function, DispatchCommand, which is called by the main module – the DLL\r\ninjected into the svchost.exe process. A parameter (one of the commands from the section in the bot configuration\r\nfile) is passed to the DispatchCommand function. The plug-in then executes the command.\r\nThe main plug-ins\r\nThe main plug-ins for Black Energy 2 are ddos, syn and http. A brief description of each is given below.\r\nThe ddos plug-in\r\nThe server address, protocol and port to be used in an attack are the input for the ddos plug-in. The plug-in\r\ninitiates mass connections to the server, using the port and protocol specified. Once a connection is established, a\r\nrandom data packet is sent to the server. The following protocols are supported: tcp, udp, icmp and http.\r\nBelow is an example of a “ddos_start udp 80” command being carried out:\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 7 of 11\n\nFigure 9. Creating a socket, UDP protocol\r\nFigure 10-1. Sending data: sendto and the stack\r\nFigure 10-2. Sending data: sendto and the stack\r\nFigure 10-3. What data is sent: a random set of bytes\r\nWhen the http protocol is specified in the command, the ddos plugin uses the socket, connect and send functions\r\nto send a GET request to the server.\r\nThe syn plug-in\r\nUnlike the other plug-ins described in this article, the syn plugin includes a network driver. When the plugin’s\r\nDllEntry function is called, the driver is installed to system32drivers folder as synsenddrv.sys. The driver sends all\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 8 of 11\n\nthe network packets. As can be easily guessed, the DispatchCommand function waits for the main DLL to send it\r\nthe following parameter: “syn_start ” or “syn_stop “. If the former parameter is received, the plugin begins an\r\nattack, if the latter is received, the attack is stopped. An attack in this case consists of numerous connection\r\nrequests being made to the server, followed by so-called ‘handshakes’, i.e. the opening of network sessions.\r\nFigure 11. SYN attack: SYN-\u003eACK-\u003eRST\r\nNaturally, if numerous requests are made from a large number of infected computers, this creates a noticeable load\r\non the server.\r\nThe http plug-in\r\nThe DDoS attack methods described above are often combated by using redirects: a server with online resources\r\nis hidden behind a gateway that is visible to the outside world, with the gateway redirecting requests to the server\r\nhosting the resources. The gateway can use a variety of techniques to fend off DDoS attacks and taking it down is\r\nnot easy. Since the ddos and syn plugins target IP addresses and have no features which allow them to recognize\r\ntraffic redirects, they can only attack the gateway. Hence, the network flooding that they generate simply does not\r\nreach the server hosting Internet resources. This is where the http plugin comes in.\r\nHaving received the http_start command, the http plugin creates a COM object named “Internet Explorer(Ver\r\n1.0)” with an IWebBrowser2 interface. The Navigate method is called by the http_start command with the\r\nparameter, resulting in the Internet Explorer(Ver 1.0) object navigating to the URL specified. The Busy method is\r\nthen used by the malicious program which waits until the request is completed.\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 9 of 11\n\nFigure 12-1. Creating a COM object\r\nFigure 12-2. Pointer to CLSID\r\nFigure 12-3. Pointer to the interface ID\r\nFigure 13. Calling the Navigate method\r\nFigure 14. Calling the Busy method\r\nUsing these steps, the malicious program imitates an ordinary user visiting a particular page. The only difference\r\nis that, unlike a user, the malicious program makes many ‘visits’ to the same address within a short period of time.\r\nEven if a redirecting gateway is used, the http request is redirected to the protected server hosting web resources,\r\nthus creating a significant load on the server.\r\nGeneral commands\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 10 of 11\n\nIn addition to downloading plug-ins and executing plug-in commands, Black Energy 2 ‘understands’ a number of\r\ngeneral commands that can be sent by the C\u0026C server:\r\nrexec – download and execute a remote file;\r\nlexec – execute a local file on the infected computer;\r\ndie – terminate bot execution;\r\nupd – update the bot;\r\nsetfreq – set the frequency with which the bot will contact the C\u0026C server;\r\nhttp – send http request to the specified web page.\r\nConclusion\r\nInitially, the Black Energy bot was created with the aim of conducting DDoS attacks, but with the implementation\r\nof plugins in the bot’s second version, the potential of this malware family has become virtually unlimited.\r\n(However, so far cybercriminals have mostly used it as a DDoS tool). Plugins can be installed, e.g. to send spam,\r\ngrab user credentials, set up a proxy server etc. The upd command can be used to update the bot, e.g. with a\r\nversion that has been encrypted using a different encryption method. Regular updates make it possible for the bot\r\nto evade a number of antivirus products, any of which might be installed on the infected computer, for a long time.\r\nThis malicious tool has high potential, which naturally makes it quite a threat. Luckily, since there are no publicly\r\navailable constructors online which can be used online to build Black Energy 2 bots, there are fewer variants of\r\nthis malware than say, ZeuS or the first version of Black Energy. However, the data we have shows that\r\ncybercriminals have already used Black Energy 2 to construct large botnets, and these have already been involved\r\nin successful DDoS attacks.\r\nIt is difficult to predict how botnet masters will use their botnets in the future. It’s not hard for malware writers to\r\ncreate a plug-in and get it downloaded to infected user machines. Furthermore, any plug-in code is only present in\r\nan infected computer’s memory; in all other instances the malicious modules are encrypted, whether this is during\r\ntransmission or when stored on a hard drive.\r\nIn addition, Black Energy 2 plugins are not executable (.exe) files. Plugins are loaded directly onto an infected\r\nmachine, which means that they will not be distributed using mass propagation techniques and antivirus vendors\r\nmay not come across new plugins for extended periods of time. However, it is the plug-ins that ultimately meet the\r\ncybercriminals’ goal, i.e. delivering the malicious payload which is the ultimate aim of infecting victim machines\r\nwith the Black Energy 2 bot.\r\nConsequently, it’s essential to track the plug-ins. Kaspersky Lab monitors which Black Energy 2 plugins are\r\navailable for download to track the evolution of this malicious program. We’ll keep you posted.\r\nSource: https://securelist.com/black-ddos/36309/\r\nhttps://securelist.com/black-ddos/36309/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securelist.com/black-ddos/36309/"
	],
	"report_names": [
		"36309"
	],
	"threat_actors": [],
	"ts_created_at": 1775434798,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dff6b382daa307cd7fb212184b082c17ec24ca80.pdf",
		"text": "https://archive.orkl.eu/dff6b382daa307cd7fb212184b082c17ec24ca80.txt",
		"img": "https://archive.orkl.eu/dff6b382daa307cd7fb212184b082c17ec24ca80.jpg"
	}
}