{
	"id": "3918eccd-2126-4ae9-b2e4-ab3dffa6aace",
	"created_at": "2026-04-06T00:14:11.699618Z",
	"updated_at": "2026-04-10T13:11:31.443274Z",
	"deleted_at": null,
	"sha1_hash": "8e71d4930076b8e1ac6a8057750d8f4b91be6f90",
	"title": "Notes on Linux/Xor.DDoS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 567858,
	"plain_text": "Notes on Linux/Xor.DDoS\r\nArchived: 2026-04-05 17:44:08 UTC\r\nIn this post we'll be focusing on a certain kind of malware: Linux/Xor.DDoS (also known as DDoS.XOR or\r\nXorddos). As usual, we'll break the post down in several points:\r\nBackground\r\nDiagnosis\r\nAnalysis\r\nDisinfection\r\nPrevention\r\nConclusion\r\nThe variant discussed in this blog post is an older variant, so certain infection mechanisms may have changed, as\r\nwell as C\u0026C's. The point of this post is to familiarize yourself with ELF malware in a better way - how to\r\ndiagnose, analyse, remove and finally prevent malware from infecting your Linux machines. A lot of malware is\r\ngoing around and it's not (all) exclusively for Windows machines.\r\nBackground\r\nYou may have heard about Linux/Xor.DDoS already, a Linux Trojan with rootkit capabilities (belonging to the\r\ncategory of 'ELF malware'). What exactly is an ELF file? According to Wikipedia:\r\nIn computing, the Executable and Linkable Format (ELF, formerly called Extensible Linking Format) is\r\na common standard file format for executables, object code, shared libraries, and core dumps.\r\nSource\r\nIn other words: ELF is to Linux as PE (.exe, .com, .scr, ...) is to Windows and Mach-O to OS X.\r\nThere's a nice mini poster available by Corkami as well:\r\nMore information about the ELF format can also be found at the Resources section.\r\nIf you haven't heard about Linux/Xor.DDoS itself already, be sure to read the initial post by MalwareMustDie\r\nuncovering this malware:\r\nFuzzy reversing a new China ELF \"Linux/XOR.DDoS\"\r\nIn short: Xor.DDoS is a multi-platform, polymorphic malware for Linux OS and its ultimate goal is to DDoS other\r\nmachines. The name Xor.DDoS stems from the heavy usage of XOR encryption in both malware and network\r\ncommunication to the C\u0026Cs (command and control servers).\r\nThere have been other write-ups about this malware as well, which will be mentioned throughout this article or\r\nreferenced in the Resources section.\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 1 of 12\n\nDiagnosis\r\nHow do you know you're infected with Xor.DDoS?\r\nFirst and foremost (and obviously), you'll be conducting DDoS attacks from your machine(s) to targets chosen by\r\nthe malware authors.\r\nSending of large SYN packets (Source)\r\nYou may use netstat to print any current network/internet connections. Use tcpdump to get a more detailed\r\nanalysis of which packets you are sending out.\r\nSecondly, another indication is seeing processes running with random names and sudden new executable files\r\ncreated in /etc/init.d/ or /usr/bin/ (see example below). New entries will be/are added to your crontab as well\r\n(/etc/crontab).\r\nMalware running and its related files\r\nYou may use any command based on top or on ps to check for running malicious processes. We will see more in\r\nthe Disinfection part of this blog post.\r\nThirdly, if you are running the standard OpenSSH server you may see an unauthorised but successful login and\r\nimmediate logout afterwards.\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 2 of 12\n\nThese symptoms should be very clear, even more so if you've already implemented several measures to protect\r\nyourself from potential intruders. If not, then it'll be harder to track the infection origin as well. (but more often\r\nthan not the SSH credentials of the root users are brute forced.)\r\nTo ensure your machines will not get pwned, be sure to read the Prevention part of this blog post.\r\nAnalysis\r\nFirst off, we have to identify\r\nhow\r\nthe malware entered the system. Usually, a weak root password is used (like admin or 123456, see here for a list of\r\ntried passwords. Note: huge .txt file!) or the attackers are brute forcing their way in. (brute forcing the SSH\r\ncredentials of the root user) Another, but less common possibility, is exploiting a vulnerable service that you have\r\nrunning (Apache for example).\r\nThis figure is an excellent visual representation on how it all happens:\r\nThis variant copies itself over to /lib/libgcc.so, then creates a copy in /etc/init.d and a symbolic link to /usr/bin.\r\nAfterwards a new cron script is created and added to the crontab.\r\nWe will now take a look at one of the samples created - named bmtsfnlgxu.\r\n(SHA1: b34b6f0ec42a0153c043b0665ec47bf6e5aac894)\r\nEasiest way on Linux is to just use the \"file\" command:\r\nWe can see it's an ELF 32-bit executable for i386 - and it's\r\nnot\r\nstripped.\r\nWhy is that last part important? strip allows you to remove symbols and sections from choosen files, which in turn\r\nmakes it harder to reverse engineer (disassemble) as well. In this case, the file doesn't seem to be stripped, great!\r\nFor example, we can see the source files and get an idea of what this malware does:\r\n(this will also be shown later on in the video below, using IDA)\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 3 of 12\n\nMoving on, we will start by using readelf for some further investigation of the file. We know, thanks to the file\r\ncommand, it's an ELF 32-bit executable for i386. Using readelf and parameter -h we will be able to gather more\r\ninformation:\r\nThis gives us more information already, for example; the magic (7F 45 4C 46 for ELF files, 4D 5A for MZ files) \r\n2's complement, little endian,  the exact type of the file (an executable; other types for ELF files may be a\r\nrelocatable file, a shared object, a core file or processor specific) but most importantly here being the Entry point\r\naddress, or the start of the program.\r\nIn regards to readelf, using parameter -a we can dump a ton of information, you can find the output of this\r\ncommand on our malware on Pastebin: Xor.DDoS - \"readelf -a\" output\r\nNote that VirusTotal has added (since November 2014) detailed ELF information in reports as well, which is more\r\nor less similar to readelf's output.\r\nTo disassemble the file, we can use objdump which allows us to disassemble only those sections which are\r\nexpected to contain instructions (-d parameter) or to disassemble the contents of all sections (-D parameter).\r\nHowever, to dive a bit deeper into the malware code, we will be using IDA, a multi-processor disassembler and\r\ndebugger and Radare, a well-known (portable) reversing framework. Note that it will still be a quick glance, as\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 4 of 12\n\nMalwareMustDie has already reported extensively  about it as well [1][2][3][4]. Note also that it's always a good\r\nidea to analyse malware in a virtual environment (VM).\r\nWe will be using both tools on Windows, but you can just as easily run them on Linux or Mac.\r\nI've made an instruction video on how to use IDA Pro Free to take a quick peek into the file discussed:\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nDownload IDA Pro Free for Windows from here. If you're interested in working more with IDA, there's a handy\r\nlist of IDA plugins available here.\r\n... And just the same for Radare, where we will discover a bit more - namely the C\u0026C of the malware:\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nDownload radare2 for Windows from here. More documentation about Radare can be found here. There's also a\r\nhandy cheat sheet available here.\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 5 of 12\n\nNote that the Xor.DDoS variant discussed in this blog uses 2 XOR keys for its (network) communication, they are\r\nthe following:\r\nBB2FA36AAA9541F0\r\nECB6D3479AC3823F\r\nIf you like GUIs, then I have another useful utility: ELFparser. It will perform a scoring based on several factors,\r\nsuch as shell commands, HTTP functionality and process manipulation. For example, for our file:\r\nYou can see it's scored pretty highly. I wonder what it has to say about the hardcoded IP addresses..:\r\nYou can also see 8.8.8.8, Google's DNS server\r\nand likely used to resolve the C\u0026C domains\r\nGreat, it was able to extract our C\u0026C servers:\r\n103.25.9.228 - VirusTotal - IPvoid - DomainTools (whois)\r\n103.25.9.229 - VirusTotal - IPvoid - DomainTools (whois)\r\nUsing ELFparser you can also look at the ELF header, sections, but also all of its capabilities like Information\r\nGathering and Network Functions for example. It's a handy second-opinion tool.\r\nFinally, one last tool which should not be missed when analysing ELF files: a sandbox. We will be using detux, a\r\nmultiplatform Linux sandbox.\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 6 of 12\n\nConnections to wangzongfacai.com and dsaj2a1.org\r\nYou have Network Analysis (IPs connected and DNS queries) and Static Analysis (Elf Info and Strings). In our\r\nexample we have connections to wangzongfacai.com, not an unfamiliar domain. View the complete report made\r\nby Detux on our file here.\r\nIt's worth noting that several months ago, I already sent a file to Detux (and VirusTotal) which yielded similar\r\nresults:\r\n3000uc.com, another familiar player - and again dsaj2aX\r\nDetux report of that file here. When I sent the latter file to VirusTotal several months ago, it only had 12\r\ndetections, after re-submitting it had 19 detections. That's better but we're still not there.\r\nJust a visual representation of detection difference. Read this for info.\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 7 of 12\n\nYou may find an overview of all gathered files as well as most common/recurring domains and their IPs they\r\nconnect to/download from here, available via AlienVault's OTX.\r\nThat's it for our Analysis section, let's move on to Disinfection.\r\nDisinfection\r\nMost importantly, you'd of course like to remove/disinfect this malware completely. Some pointers:\r\nIdentify malicious processes: run ps ef (ps stands for process status) to see which processes are running.\r\nAlternatively, you can use top or again ps with other parameters, for example ps ej or ps aux for a more\r\ncomplete, human readable table. Look for processes with random names; in our example it started with S90\r\nand random letters afterwards, linked to files with all random names, as is the case in our example malware\r\nnamed bmtsfnlgxu.\r\nOnce you've identified the malicious process(es), you can use the following command to find related files\r\nas well: for pid in $(ps -C -o pid=); do ls -la /proc/$pid/fd; done\r\nWhere is the name of the suspicious process. This command will display any open, related files. For\r\nexample, for bmtsfnlgxu it would be:\r\nfor pid in $(ps -C bmtsfnlgxu -o pid=); do ls -la /proc/$pid/fd; done\r\nIdentify malicious files: look for newly created files in /etc/init.d/, /boot/ and /usr/bin/. Again, look for\r\nfiles with random names. You may also use the command ls -lat | head to view recently changed files.\r\nCheck your crontab (/etc/crontab). Delete the malicious cron jobs, more specifically the cron.hourly jobs\r\nand in the case of Xor.DDoS they will be the following:\r\n*/3 * * * * root /etc/cron.hourly/cron.sh\r\n*/3 * * * * root /etc/cron.hourly/udev.sh\r\nDelete these two lines from your crontab. Don't forget to save. Delete the related files, located in\r\n/etc/cron.hourly. In our case, their content was as follows:\r\ncron.sh\r\n         udev.sh\r\nAs said earlier, delete these files manually, as well as the file(s) mentioned in the scripts. (in this case:\r\n/lib/libgcc.so.bak, /lib/libgcc.so and /lib/libgcc4.4.so.) Note that these files are\r\nnot\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 8 of 12\n\nrelated to GCC's runtime library and thus can be safely deleted. It's just another way how the malware tries to hide\r\nitself.\r\nAlso double-check there are no malicious files or scripts in /etc/rc.d. If so, remove them as well.\r\nStop and kill malicious processes: identify the parent process; usually it will be the one consuming the\r\nmost CPU (which you can verify using any of the earlier commands, top being the easiest). Firstly, be sure\r\nto stop the parent process and wait for the child processes to die. Use the command: kill -STOP $pid\r\nWhen the child processes are dead, kill the parent by using: kill -9 $pid\r\nNote: in case you see any other malicious processes, go through the last 2 commands again.\r\nDelete any leftover malicious files: locations where the malware may reside have been indicated before,\r\nbut to be complete:\r\n/ (root directory, in rare cases)\r\n/bin/\r\n/boot/\r\n/etc/init.d/\r\n/etc/rc.d\r\n/etc/rcX.d (where X is a number)\r\n/lib/\r\n/lib/udev/\r\n/sbin/\r\n/tmp/\r\n/usr/bin/\r\nThat's it. Some additional tips and tricks: \r\nUse rm -rf to permanently remove a file. Be careful with this command.\r\nHaving troubles removing a file? Are you root? If not, try killing a process or deleting a file using root by\r\nprepending sudo before your command. For example: sudo kill -STOP $pid\r\nMalicious process keeps coming back? Go over the steps again, but this time note down where the malware\r\nresides. Make that directory and its files unmodifiable by making use of the chattr command. For example,\r\nmalware is being recreated in /usr/bin/. Use the command: chattr -R +i /usr/bin/ Then, stop the parent,\r\nwait for the children to die and kill the parent. Remove the files. Don't forget to use chattr again after you\r\ncleaned the infection. (in our example: chattr -R -i /usr/bin/)\r\nIt's also possible the malware is temporarily storing files into /tmp/ while you are trying to kill its\r\nprocesses. When that happens, use the same chattr command on the /tmp/ directory and start over. If you\r\nare in doubt, use that chattr command on all aforementioned directories and start over.\r\nVery important: do not forget to use chattr -R -i on them afterwards!\r\nIn rare cases, the attacker may still be connected to your box. If possible, cut the internet connection and go\r\nover the disinfection steps. If this is not possible, firstly stop SSH by entering the command:\r\nsudo /etc/init.d/ssh stop\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 9 of 12\n\nThen, use iptables to drop any connection to the IPs the malware is connecting to (use netstat for example,\r\nsee also Diagnosis) and to drop any connection from the attacker or cybercriminal. How to do this:\r\nIn our example, we learned that our C\u0026C's were 103.25.9.228 and 103.25.9.229. Thus, type or copy/paste\r\nthese 2 commands:\r\niptables -A OUTPUT -d 103.25.9.228 -j DROP\r\niptables -A OUTPUT -d 103.25.9.229 -j DROP\r\nTo block connection(s) from the attacker (you can find the attacker's IP using netstat for example):\r\niptables -A INPUT -s $attackerIP -j DROP\r\nDon't forget to save your freshly created iptables rules by using the command\r\n/etc/init.d/iptables save\r\nAfterwards, change all passwords. (SSH, your user, root)\r\nBest case scenario here is obviously:\r\nrestoring from a backup \r\nif the machine is virtual, restore to a previous snapshot\r\nWhen you have either of these available, don't forget to change all passwords afterwards to prevent re-infection -\r\nand patch your machine(s)!\r\nSome Xor.DDoS variants may also incorporate a rootkit. In that case, hope you have a \"best case scenario\"\r\navailable to you. Once a box is fully compromised, it may be hard to reinstate it back to normal or its original\r\nstate.\r\nFor double-checking for rootkits and other malware, you may want to check out chkrootkit or alternatively,\r\nrkhunter. Additionally, you may download and install an antivirus, for example ClamAV.\r\nIf you perform manual clean-up as indicated above and have confirmed all is in order again, you can install\r\nClamAV and perform an extra scan to be sure. Better be safe than sorry. Then, follow the prevention tips below to\r\nstay safe.\r\nPrevention\r\nUse strong passwords for SSH or use keys instead of passwords for authentication. You can read how to do\r\nthat here. In the unlikely event of you not needing SSH to a particular machine, disable it on that machine\r\nby:\r\nsudo apt-get remove openssh-server\r\nTo disable it from starting up you can use:\r\nupdate-rc.d -f ssh remove\r\nDon't open the incoming SSH port (default 22) to ANY, but rather restrict it to trusted IP addresses.\r\nFor more information about safely using SSH, see: SSH: Best practices\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 10 of 12\n\nUse a strong firewall. In Linux there are many options, iptables is a solid choice. A good basic iptables\r\nhowto can be found here. In a network or if you need to protect several machines, you may want to\r\nconsider a seperate hardware appliance as your firewall/UTM/... of choice.\r\nIptables can do a very decent job once properly configured. In case you want to do less manual work, I\r\nadvise to check out sshguard or artillery. Both can monitor and alert you when something funky happens.\r\nIn the context of our blog post, it also looks for \u0026 protects against SSH bruteforce attempts. Another\r\napplication to consider is fail2ban. An additional tool is snort. For more information about these tools, refer\r\nto their pages.\r\nConsider using SELinux. Security-Enhanced Linux is a compulsory access control security mechanism\r\nprovided in the kernel.\r\nConsider locking down cron jobs to only certain users. To deny all users from using cron you can use:\r\necho ALL \u003e\u003e/etc/cron.deny\r\nConsider disabling remote root login. Read how to do that here.\r\nIf you browse a lot, consider using NoScript as well.\r\nKeep your software and applications up-to-date, as on any system.\r\nConsider installing an antivirus as second opinion or at least as an additional layer. This is not a necessity\r\nbut may come in handy. I recommend ClamAV.\r\nDon't forget to protect other appliances that may be running on *nix systems, for example your router (and\r\nnowadays, IoT devices). Upgrade the firmware as soon as possible and change the default root/admin\r\npassword(s). Install updates/patches for your particular firewall/UTM/... as well.\r\nFor even more (general) tips on hardening your Linux system (not against Xor.DDoS in particular):\r\n20 Linux Server Hardening Security Tips\r\nConclusion\r\nDon't be fooled: Linux malware very much exists and starts to become more prevalent. Other prevalent Linux\r\nmalware nowadays is:\r\nEvery ELF malware made by the ChinaZ actor or group (Linux/ChinaZ.DDoS, Linux/Kluh, ...)\r\nLinux/Aes.DDoS (Dofloo, MrBlack)\r\nLinux/Bash0day (Shellshock, Bashdoor)\r\nLinux/BillGates (Gates.B)\r\nLinux/Elknot (DnsAmp)\r\nLinux/GoARM (Ramgo, Goram)\r\nLinux/IptabLes and Linux/IptabLex\r\nNote that this list is not complete and new ELF malware may pop up every day. (it's not a question of if, but when\r\nit will pop up) You can find a list of (interesting) Linux malware here.\r\nHopefully you have learned new things along the way of this blog post. For any specific questions, don't hesitate\r\nto leave a comment or contact me on Twitter: @bartblaze\r\nTo conclude this blog post, some acknowledgements and resources/references:\r\nAcknowledgements\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 11 of 12\n\nMy colleague from Panda France, Julien Gourlaouen for informing me about this incident.\r\nEveryone who helped, helps and will help in battling creators of ELF malware, in particular @MalwareMustDie\r\nfor their excellent research and increasing awareness about these threats.\r\nLast but not least, thank you for reading my blog post. \r\nResources\r\nAlienVault - Xor.DDoS hashes, IPs and domains (see also related pulses)\r\nAvast -  Linux DDoS Trojan hiding itself with an embedded rootkit\r\nCisco -  Threat Spotlight: SSHPsychos\r\nFireEye - Anatomy of a Brute Force Campaign: The Story of Hee Thai Limited\r\nKernelMode - Linux/Xor.DDoS (samples)\r\nKernelMode - List of Linux Malware\r\nMalwareMustDie - Fuzzy reversing a new China ELF \"Linux/XOR.DDoS\"\r\nMalwareMustDie - Linux/XorDDoS infection incident report (CNC: HOSTASA.ORG)\r\nMalwareMustDie - A bad Shellshock \u0026 Linux/XOR.DDoS CNC \"under the hood\"\r\nMalwareMustDie - Polymorphic in ELF malware: Linux/Xor.DDOS\r\nYale - ELF Format (PDF)\r\nSource: https://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nhttps://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html"
	],
	"report_names": [
		"notes-on-linuxxorddos.html"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434451,
	"ts_updated_at": 1775826691,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8e71d4930076b8e1ac6a8057750d8f4b91be6f90.pdf",
		"text": "https://archive.orkl.eu/8e71d4930076b8e1ac6a8057750d8f4b91be6f90.txt",
		"img": "https://archive.orkl.eu/8e71d4930076b8e1ac6a8057750d8f4b91be6f90.jpg"
	}
}