{
	"id": "c6ef3484-056d-42fc-b5cd-01f534c7082b",
	"created_at": "2026-04-06T00:14:05.960628Z",
	"updated_at": "2026-04-10T03:19:58.78865Z",
	"deleted_at": null,
	"sha1_hash": "a1b533fd7a903df5b1b0cb3c14b798a926db5399",
	"title": "Linux/Cdorked.A: New Apache backdoor being used in the wild to serve Blackhole",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 177827,
	"plain_text": "Linux/Cdorked.A: New Apache backdoor being used in the wild to\r\nserve Blackhole\r\nBy Pierre-Marc Bureau\r\nArchived: 2026-04-05 12:39:12 UTC\r\nLast week, our friends at Sucuri sent us a modified version of an Apache webserver redirecting some of its\r\nrequests to the infamous Blackhole exploit packs. Sucuri has published a blog post on this attack. (You can find\r\nmore about Blackhole here.)\r\nOur analysis of this malware, dubbed Linux/Cdorked.A, reveals that it is a sophisticated and stealthy backdoor\r\nmeant to drive traffic to malicious websites. We urge system administrators to check their servers and verify that\r\nthey are not affected by this threat. Detailed instructions to perform this check are provided below. (Update\r\n5/1/2013: An improved tool coded in C replaced the Python script we originally published.)\r\nIn fact, Linux/Cdorked.A is one of the most sophisticated Apache backdoors we have seen so far. Although we are\r\nstill processing the data, our Livegrid system reports hundreds of compromised servers. The backdoor leaves no\r\ntraces of compromised hosts on the hard drive other than its modified httpd binary, thereby complicating forensics\r\nanalysis. All of the information related to the backdoor is stored in shared memory. The configuration is pushed by\r\nthe attacker through obfuscated HTTP requests that aren't logged in normal Apache logs. This means that no\r\ncommand and control information is stored anywhere on the system.\r\nTechnical analysis of Linux/Cdorked\r\nHere we provide the first technical analysis of Linux/Cdorked, which seems to be affecting hundreds of\r\nwebservers right now. In the Linux/Cdorked binary all the important or suspicious strings are encrypted. As shown\r\nin the following image, a function is responsible for decrypting the strings on demand with a static XOR key.\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 1 of 7\n\nThe version of Linux/Cdorked that we have analyzed contains a total of 70 strings that are encoded this way. As\r\nshown in the following screenshot, the key used for encoding the data is\r\n27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F.\r\nAs mentioned before, Linux/Cdorked does not write any files on the disk. Instead, it allocates around six\r\nmegabytes of shared memory to keep its state and configuration information. This memory block, a POSIX shared\r\nregion of memory (shm), is used by all Apache subprocesses but can also be accessed by any other process since\r\nthe malware authors didn't limit its permission.  The following screenshot shows the (read, write for everyone)\r\npermission rights assigned to the shared memory region.\r\nThere are two ways the attacker can control the behavior of the backdoored server: through a reverse connect shell\r\nor through special commands, all of them are triggered via HTTP requests.\r\nThe Linux/Cdorked.A backdoor\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 2 of 7\n\nThe HTTP server is equipped with a reverse connect backdoor that can be triggered via a special HTTP GET\r\nrequest. It is invoked when a request to a special path is performed with a query string in a particular format,\r\ncontaining the hostname and port to connect. The client IP of the HTTP dialog is used as a key to decrypt the\r\nquery string as a 4 byte XOR key. Additionally, IP specified in X-Real-IP or X-Forwarded-For headers will\r\noverride the client IP as the XOR key. This means we can craft a X-Real-IP header that will in effect be a\r\n“\\x00\\x00\\x00\\x00” key. Query string also needs to be hex-encoded before sending.\r\nWhile the shell is used by the attacker, the HTTP connection creating it is hung (the backdoor code does not\r\nimplement forking). This implies that malicious shells can be found if one has access to the server and checks for\r\nlong-running HTTP connections. On the other hand, the HTTP request does not appear in Apache's log file due to\r\nthe way the malicious code is hooked into Apache.\r\nRedirection in Linux/Cdorked.A\r\nWhen redirecting a client, the malware adds base64 encoded string to the query containing information like the\r\noriginal visited URL and whether or not the request was originally to a javascript file so the server could provide\r\nthe right payload.\r\nAn example redirection looks like:\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 3 of 7\n\nLocation: hxxp://dcb84fc82e1f7b01. xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3\r\nZja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2\r\nZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG\r\n9hY3Vsb3VzLjEuOC4yLm1pbi5qcw==\r\nAfter decoding, the following parameters appear:\r\njs=1\u0026nvcbimuf=ccvckqju\u0026time=1304161827-360453650\u0026src=232\u0026surl=www.infectedserver\r\n.com\u0026sport=80\u0026key=13D90950\u0026suri=/forum/wcf/js/3rdParty/protoaculous.1.8.2.min.js\r\nThe \"surl\" parameter shows the infected host and the \"suri\" indicates what the original requested resource was.\r\nAfter the redirection, a web cookie is set on the client so it is not redirected again. This cookie is also set if a\r\nrequest is made to a page that looks like an administration page. The backdoor will check if the URL, the server\r\nname, or the referrer matches any of the following strings : '*adm*', '*webmaster*', '*submit*', '*stat*', '*mrtg*',\r\n'*webmin*', '*cpanel*', '*memb*', '*bucks*', '*bill*', '*host*', '*secur*', '*support*'.  This is probably done to\r\navoid sending malicious content to administrators of the website, making the infection harder to spot. The\r\nfollowing screenshot shows part of the code responsible for handling the web cookie.\r\nA few other conditions must be met before redirection happens; for example, a check is done for the presence of\r\nthe Accept-Language, Accept-Encoding, and Referrer header.\r\nOther Linux/Cdorked.A commands\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 4 of 7\n\nWe found 23 commands in Linux/Cdorked.A that can be sent to the server via a POST to a specially crafted URL.\r\nThe request must also contain a cookie header starting with \"SECID=\". The query string value must hold 2 hex\r\nencoded bytes that are encrypted with the client IP, using the same technique as the shell. The SECID cookie data\r\nwill be used as arguments to some of the commands. We believe that the URLs to redirect clients are sent to the\r\nbackdoor using this method. The redirection information will be stored encrypted in the allocated shared memory\r\nregion. We also believe that the conditions for redirection are set this way, for example, a white list of user agents\r\nto redirect can be preconfigured and a black list of IPs to avoid redirection.\r\nThis is the complete list of commands found in the binary we have analysed:  'DU', 'ST', 'T1', 'L1', 'D1', 'L2', 'D2',\r\n'L3', 'D3', 'L4', 'D4', 'L5', 'D5', 'L6', 'D6', 'L7', 'D7', 'L8', 'D8', 'L9', 'D9', 'LA', 'DA'.\r\nFinally, some information about the status of the backdoor is returned in the ETag HTTP header, as shown in the\r\nscreenshot below. We are still investigating the purpose of each of the commands and will publish our results as\r\nsoon as the analysis is completed. In short, they all either add content to, or remove it from, the configuration in\r\nthe shared memory region.\r\nLinux/Cdorked.A Remediation\r\nAs previously mentioned, the permissions on the shared memory allocation are loose. This allows other process to\r\naccess to memory. We have made a free tool to allow systems administrators to verify the presence of the shared\r\nmemory region and dump its content into a file (you can download dump_cdorked_config.c or copy and paste the\r\ncode from the listing below).\r\nWe also recommend using debsums for Debian or Ubuntu systems and `rpm --verify` for RPM based systems, to\r\nverify the integrity of your Apache web server package installation. (However, remember to temper this advice\r\nwith the reality that the package manifest could have been altered by an attacker.) Checking for the presence of the\r\nshared memory is the recommended way to make sure you are not infected. We would be interested in receiving\r\nany memory dumps for further analysis.\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 5 of 7\n\nAt the time of writing, the ESET Livegrid monitoring system is showing hundreds of webservers that seem to be\r\naffected by this backdoor with thousands of visitors being redirected to malicious content. We will publish more\r\ninformation on the scale and complexity of this operation in the days to come.\r\nThe following researchers contributed to this report: Olivier Bilodeau, François Chagnon, Alexis Dorais-Joncas, Sebastien Duquette and Marc-Étienne Léveillé.\r\nResources:\r\nSHA1 of the analyzed binary: 24e3ebc0c5a28ba433dfa69c169a8dd90e05c429\r\nCode for the shared memory dump tool: dump_cdorked_config.c\r\n// This program dumps the content of a shared memory block\r\n// used by Linux/Cdorked.A into a file named httpd_cdorked_config.bin\r\n// when the machine is infected.\r\n//\r\n// Some of the data is encrypted. If your server is infected and you\r\n// would like to help, please send the httpd_cdorked_config.bin\r\n// and your httpd executable to our lab for analysis. Thanks!\r\n//\r\n// Build with gcc -o dump_cdorked_config dump_cdorked_config.c\r\n//\r\n// Marc-Etienne M.Léveillé \u003cleveille@eset.com\u003e\r\n//\r\n#include \u003cstdio.h\u003e\r\n#include \u003csys/shm.h\u003e\r\n#define CDORKED_SHM_SIZE (6118512)\r\n#define CDORKED_OUTFILE \"httpd_cdorked_config.bin\"\r\nint main (int argc, char *argv[]) {\r\n int maxkey, id, shmid, infected = 0;\r\n struct shm_info shm_info;\r\n struct shmid_ds shmds;\r\n void * cdorked_data;\r\n FILE * outfile;\r\n maxkey = shmctl(0, SHM_INFO, (void *) \u0026shm_info);\r\n for(id = 0; id \u003c= maxkey; id++) {\r\n shmid = shmctl(id, SHM_STAT, \u0026shmds);\r\n if (shmid \u003c 0)\r\n continue;\r\n if(shmds.shm_segsz == CDORKED_SHM_SIZE) {\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 6 of 7\n\n// We have a matching Cdorked memory segment\r\n infected++;\r\n printf(\"A shared memory matching Cdorked signature was found.\\n\");\r\n printf(\"You should check your HTTP server's executable file integrity.\\n\");\r\n cdorked_data = shmat(shmid, NULL, 0666);\r\n if(cdorked_data != NULL) {\r\n outfile = fopen(CDORKED_OUTFILE, \"wb\");\r\n if(outfile == NULL) {\r\n printf(\"Could not open file %s for writing.\", CDORKED_OUTFILE);\r\n }\r\n else {\r\n fwrite(cdorked_data, CDORKED_SHM_SIZE, 1, outfile);\r\n fclose(outfile);\r\n printf(\"The Cdorked configuration was dumped in the %s file.\\n\\n\", CDORKED_OUTFILE);\r\n }\r\n }\r\n }\r\n }\r\n if(infected == 0) {\r\n printf(\"No shared memory matching Cdorked signature was found.\\n\");\r\n printf(\"To further verify your server, run \\\"ipcs -m -p\\\" and look\");\r\n printf(\" for a memory segments created by your http server.\\n\");\r\n }\r\n else {\r\n printf(\"If you would like to help us in our research on Cdorked, \");\r\n printf(\"please send the httpd_cdorked_config.bin and your httpd executable file \");\r\n printf(\"to our lab for analysis at leveille@eset.com. Thanks!\\n\");\r\n }\r\n return infected;\r\n}\r\nSource: https://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nhttps://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA",
		"MITRE"
	],
	"references": [
		"https://www.welivesecurity.com/2013/04/26/linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole/"
	],
	"report_names": [
		"linuxcdorked-new-apache-backdoor-in-the-wild-serves-blackhole"
	],
	"threat_actors": [],
	"ts_created_at": 1775434445,
	"ts_updated_at": 1775791198,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a1b533fd7a903df5b1b0cb3c14b798a926db5399.pdf",
		"text": "https://archive.orkl.eu/a1b533fd7a903df5b1b0cb3c14b798a926db5399.txt",
		"img": "https://archive.orkl.eu/a1b533fd7a903df5b1b0cb3c14b798a926db5399.jpg"
	}
}