{
	"id": "924f18c9-f17a-4b6e-b54e-17ed969cf985",
	"created_at": "2026-04-06T00:11:30.133025Z",
	"updated_at": "2026-04-10T03:19:56.293142Z",
	"deleted_at": null,
	"sha1_hash": "155f18ad371dc1ce941701d45f11fcd5a9b7787d",
	"title": "The stealthiness of Linux/Cdorked: a clarification",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 39917,
	"plain_text": "The stealthiness of Linux/Cdorked: a clarification\r\nBy Stephen Cobb\r\nArchived: 2026-04-05 17:35:26 UTC\r\nMalware\r\nWe clarify that the Linux/Cdorked backdoor malware leaves no traces on the hard drive \"other than its modified\r\nhttpd binary\" which can be scanned for detection in several ways.\r\n02 May 2013  •  , 3 min. read\r\nWe wanted to clarify that the Linux/Cdorked backdoor malware we reported on last week, and which has been\r\nwidely reported in the press this week, leaves no traces on the hard drive other than its modified httpd binary.\r\nWe said this explicitly in the original post but some reports have suggested that the malware leaves no trace at all\r\non the hard drive. While that is not the case, we do think \"stealthy\" is still an appropriate term to use with respect\r\nto Linux/Cdorked.\r\nHow stealthy is Linux/Cdorked?\r\nFew blog posts on We Live Security have attracted the amount of attention accorded to Linux/Cdorked.A: New\r\nApache backdoor being used in the wild to serve Blackhole which Pierre-Marc Bureau and his team posted last\r\nFriday. Their analysis of malware which they dubbed Linux/Cdorked.A, revealed \"a sophisticated and stealthy\r\nbackdoor meant to drive traffic to malicious websites.\"\r\nAfter reports of the malware appeared in numerous publications, questions were raised about just how stealthy it\r\nwas. Pierre-Marc and his team are preparing a follow-up post with additional details about Linux/Cdorked and we\r\nthink that will address a number of key questions, but in the meantime we wanted to clarify the stealth factor. Here\r\nis what the original blog post said:\r\nThe backdoor leaves no traces of compromised hosts on the hard drive other than its modified httpd\r\nbinary, thereby complicating forensics analysis. All of the information related to the backdoor is stored\r\nin shared memory. The configuration is pushed by the attacker through obfuscated HTTP requests that\r\naren’t logged in normal Apache logs. This means that no command and control information is stored\r\nanywhere on the system.\r\nNow, I think you will agree that's pretty stealthy. Nowhere on the hard drive of the infected server will you find\r\nthe Linux/Cdorked payload, that is, the malicious code that the bad guys want to run. In the sample we analyzed,\r\nthe payload--which resides in memory, not on the hard drive--was redirecting web traffic, from the web server\r\ninfected by Linux/Cdorked, to websites that seek to infect visitors via the Blackhole Exploit kit.\r\nWe also noted that the messages used by the bad guys to remotely activate and modify the payload are not logged\r\nin normal Apache logs. Furthermore, rebooting the system removes all trace of the payload. However, as stated\r\nhttps://www.welivesecurity.com/2013/05/02/the-stealthiness-of-linuxcdorked-a-clarification/\r\nPage 1 of 3\n\nearlier, we did not say that there is no trace of Linux/Cdorked.A on the server's hard drive. We said there were no\r\ntraces on the hard drive \"other than its modified httpd binary\". In other words, there is a trace of this infection\r\nthat can be detected by monitoring changes to binaries on the server, or by scanning the files on the server with an\r\nanti-malware program that can spot Linux/Cdorked.A (such a scan, for example with ESET File Security for\r\nLinux, will flag the httpd binary).\r\nAn open Apache range\r\nSomething that emerged in the many valuable comments on Dan Goodin's widely read article about\r\nLinux/Cdorked in Ars Technica is the differing levels of expertise and resources applied to administering Apache\r\nweb servers in different contexts.\r\nOn the one hand you have experienced sysadmins who were quick to point out that changes to httpd would be\r\ndetected by something like Tripwire, software that detects unauthorized changes to files by creating checksums of\r\nthem in a known good state, then routinely comparing those checksums to production files. Some folks in this\r\ncamp can't imagine running an Apache server without such security measures in place (including storing copies of\r\nthe checksums somewhere other than the server).\r\nOn the other hand there are potentially millions of websites running on Apache servers that come preconfigured\r\nfrom hosting providers in ways that seriously complicate the use of such security measures by the server\r\n\"owners,\" many of whom have little knowledge of the finer points of managing a Linux server. I would not be\r\nsurprised to find that this particular subset of Apache servers is being targeted by bad guys who well understand\r\nthe implications: greater probability of successful and persistent compromise.\r\nPlease stay tuned for more coverage.\r\nLet us keep you\r\nup to date\r\nSign up for our newsletters\r\nhttps://www.welivesecurity.com/2013/05/02/the-stealthiness-of-linuxcdorked-a-clarification/\r\nPage 2 of 3\n\nSource: https://www.welivesecurity.com/2013/05/02/the-stealthiness-of-linuxcdorked-a-clarification/\r\nhttps://www.welivesecurity.com/2013/05/02/the-stealthiness-of-linuxcdorked-a-clarification/\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.welivesecurity.com/2013/05/02/the-stealthiness-of-linuxcdorked-a-clarification/"
	],
	"report_names": [
		"the-stealthiness-of-linuxcdorked-a-clarification"
	],
	"threat_actors": [],
	"ts_created_at": 1775434290,
	"ts_updated_at": 1775791196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/155f18ad371dc1ce941701d45f11fcd5a9b7787d.pdf",
		"text": "https://archive.orkl.eu/155f18ad371dc1ce941701d45f11fcd5a9b7787d.txt",
		"img": "https://archive.orkl.eu/155f18ad371dc1ce941701d45f11fcd5a9b7787d.jpg"
	}
}