Friday, September 25, 2015

Notes on Linux/Xor.DDoS

In this post we'll be focusing on a certain kind of malware: Linux/Xor.DDoS (also known as DDoS.XOR or Xorddos). As usual, we'll break the post down in several points:


The variant discussed in this blog post is an older variant, so certain infection mechanisms may have changed, as well as C&C's. The point of this post is to familiarize yourself with ELF malware in a better way - how to diagnose, analyse, remove and finally prevent malware from infecting your Linux machines. A lot of malware is going around and it's not (all) exclusively for Windows machines.

You may have heard about Linux/Xor.DDoS already, a Linux Trojan with rootkit capabilities (belonging to the category of 'ELF malware'). What exactly is an ELF file? According to Wikipedia:

In computing, the Executable and Linkable Format (ELF, formerly called Extensible Linking Format) is a common standard file format for executables, object code, shared libraries, and core dumps.
In other words: ELF is to Linux as PE (.exe, .com, .scr, ...) is to Windows and Mach-O to OS X.

There's a nice mini poster available by Corkami as well:


More information about the ELF format can also be found at the Resources section.

If you haven't heard about Linux/Xor.DDoS itself already, be sure to read the initial post by MalwareMustDie uncovering this malware:
Fuzzy reversing a new China ELF "Linux/XOR.DDoS"

In short: Xor.DDoS is a multi-platform, polymorphic malware for Linux OS and its ultimate goal is to DDoS other machines. The name Xor.DDoS stems from the heavy usage of XOR encryption in both malware and network communication to the C&Cs (command and control servers).

There have been other write-ups about this malware as well, which will be mentioned throughout this article or referenced in the Resources section.

How do you know you're infected with Xor.DDoS?

First and foremost (and obviously), you'll be conducting DDoS attacks from your machine(s) to targets chosen by the malware authors.

Sending of large SYN packets (Source)

You may use netstat to print any current network/internet connections. Use tcpdump to get a more detailed analysis of which packets you are sending out.

Secondly, another indication is seeing processes running with random names and sudden new executable files created in /etc/init.d/ or /usr/bin/ (see example below). New entries will be/are added to your crontab as well (/etc/crontab).

Malware running and its related files

You may use any command based on top or on ps to check for running malicious processes. We will see more in the Disinfection part of this blog post.

Thirdly, if you are running the standard OpenSSH server you may see an unauthorised but successful login and immediate logout afterwards.

These symptoms should be very clear, even more so if you've already implemented several measures to protect yourself from potential intruders. If not, then it'll be harder to track the infection origin as well. (but more often than not the SSH credentials of the root users are brute forced.)

To ensure your machines will not get pwned, be sure to read the Prevention part of this blog post.

First off, we have to identify how the malware entered the system. Usually, a weak root password is used (like admin or 123456, see here for a list of tried passwords. Note: huge .txt file!) or the attackers are brute forcing their way in. (brute forcing the SSH credentials of the root user) Another, but less common possibility, is exploiting a vulnerable service that you have running (Apache for example).

This figure is an excellent visual representation on how it all happens:


This variant copies itself over to /lib/, then creates a copy in /etc/init.d and a symbolic link to /usr/bin. Afterwards a new cron script is created and added to the crontab.

We will now take a look at one of the samples created - named bmtsfnlgxu.
(SHA1: b34b6f0ec42a0153c043b0665ec47bf6e5aac894)

Easiest way on Linux is to just use the "file" command:

We can see it's an ELF 32-bit executable for i386 - and it's not stripped.

Why is that last part important? strip allows you to remove symbols and sections from choosen files, which in turn makes it harder to reverse engineer (disassemble) as well. In this case, the file doesn't seem to be stripped, great! For example, we can see the source files and get an idea of what this malware does:
(this will also be shown later on in the video below, using IDA)

Moving on, we will start by using readelf for some further investigation of the file. We know, thanks to the file command, it's an ELF 32-bit executable for i386. Using readelf and parameter -h we will be able to gather more information:

This gives us more information already, for example; the magic (7F 45 4C 46 for ELF files, 4D 5A for MZ files)  2's complement, little endian,  the exact type of the file (an executable; other types for ELF files may be a relocatable file, a shared object, a core file or processor specific) but most importantly here being the Entry point address, or the start of the program.

In regards to readelf, using parameter -a we can dump a ton of information, you can find the output of this command on our malware on Pastebin: Xor.DDoS - "readelf -a" output

Note that VirusTotal has added (since November 2014) detailed ELF information in reports as well, which is more or less similar to readelf's output.

To disassemble the file, we can use objdump which allows us to disassemble only those sections which are expected to contain instructions (-d parameter) or to disassemble the contents of all sections (-D parameter).

However, to dive a bit deeper into the malware code, we will be using IDA, a multi-processor disassembler and debugger and Radare, a well-known (portable) reversing framework. Note that it will still be a quick glance, as MalwareMustDie has already reported extensively  about it as well [1][2][3][4]. Note also that it's always a good idea to analyse malware in a virtual environment (VM).

We will be using both tools on Windows, but you can just as easily run them on Linux or Mac.

I've made an instruction video on how to use IDA Pro Free to take a quick peek into the file discussed:

Download IDA Pro Free for Windows from here. If you're interested in working more with IDA, there's a handy list of IDA plugins available here.

... And just the same for Radare, where we will discover a bit more - namely the C&C of the malware:

Download radare2 for Windows from here. More documentation about Radare can be found here. There's also a handy cheat sheet available here.

If you like GUIs, then I have another useful utility: ELFparser. It will perform a scoring based on several factors, such as shell commands, HTTP functionality and process manipulation. For example, for our file:

You can see it's scored pretty highly. I wonder what it has to say about the hardcoded IP addresses..:

You can also see, Google's DNS server
and likely used to resolve the C&C domains

Great, it was able to extract our C&C servers: - VirusTotal - IPvoid - DomainTools (whois) - VirusTotal - IPvoid - DomainTools (whois)

Using ELFparser you can also look at the ELF header, sections, but also all of its capabilities like Information Gathering and Network Functions for example. It's a handy second-opinion tool.

Finally, one last tool which should not be missed when analysing ELF files: a sandbox. We will be using detux, a multiplatform Linux sandbox.

Connections to and

You have Network Analysis (IPs connected and DNS queries) and Static Analysis (Elf Info and Strings). In our example we have connections to, not an unfamiliar domain. View the complete report made by Detux on our file here.

It's worth noting that several months ago, I already sent a file to Detux (and VirusTotal) which yielded similar results:, another familiar player - and again dsaj2aX

Detux report of that file here. When I sent the latter file to VirusTotal several months ago, it only had 12 detections, after re-submitting it had 19 detections. That's better but we're still not there.
Just a visual representation of detection difference. Read this for info.

You may find an overview of all gathered files as well as most common/recurring domains and their IPs they connect to/download from here, available via AlienVault's OTX.

That's it for our Analysis section, let's move on to Disinfection.

Most importantly, you'd of course like to remove/disinfect this malware completely. Some pointers:

  • Identify malicious processes: run ps ef (ps stands for process status) to see which processes are running. Alternatively, you can use top or again ps with other parameters, for example ps ej or ps aux for a more complete, human readable table. Look for processes with random names; in our example it started with S90 and random letters afterwards, linked to files with all random names, as is the case in our example malware named bmtsfnlgxu.

    Once you've identified the malicious process(es), you can use the following command to find related files as well: for pid in $(ps -C -o pid=); do ls -la /proc/$pid/fd; done
    Where is the name of the suspicious process. This command will display any open, related files. For example, for bmtsfnlgxu it would be:
    for pid in $(ps -C bmtsfnlgxu -o pid=); do ls -la /proc/$pid/fd; done

  • Identify malicious files: look for newly created files in /etc/init.d/, /boot/ and /usr/bin/. Again, look for files with random names. You may also use the command ls -lat | head to view recently changed files.

    Check your crontab (/etc/crontab). Delete the malicious cron jobs, more specifically the cron.hourly jobs and in the case of Xor.DDoS they will be the following:

    */3 * * * * root /etc/cron.hourly/
    */3 * * * * root /etc/cron.hourly/

    Delete these two lines from your crontab. Don't forget to save. Delete the related files, located in /etc/cron.hourly. In our case, their content was as follows:

As said earlier, delete these files manually, as well as the file(s) mentioned in the scripts. (in this case: /lib/, /lib/ and /lib/ Note that these files are not related to GCC's runtime library and thus can be safely deleted. It's just another way how the malware tries to hide itself.

Also double-check there are no malicious files or scripts in /etc/rc.d. If so, remove them as well.

  • Stop and kill malicious processes: identify the parent process; usually it will be the one consuming the most CPU (which you can verify using any of the earlier commands, top being the easiest). Firstly, be sure to stop the parent process and wait for the child processes to die. Use the command: kill -STOP $pid

    When the child processes are dead, kill the parent by using: kill -9 $pid
    in case you see any other malicious processes, go through the last 2 commands again.

  • Delete any leftover malicious files: locations where the malware may reside have been indicated before, but to be complete:
    /etc/rcX.d (where X is a number)

That's it. Some additional tips and tricks: 
  • Use rm -rf to permanently remove a file. Be careful with this command.
  • Having troubles removing a file? Are you root? If not, try killing a process or deleting a file using root by prepending sudo before your command. For example: sudo kill -STOP $pid
  • Malicious process keeps coming back? Go over the steps again, but this time note down where the malware resides. Make that directory and its files unmodifiable by making use of the chattr command. For example, malware is being recreated in /usr/bin/. Use the command: chattr -R +i /usr/bin/ Then, stop the parent, wait for the children to die and kill the parent. Remove the files. Don't forget to use chattr again after you cleaned the infection. (in our example: chattr -R -i /usr/bin/)

    It's also possible the malware is temporarily storing files into /tmp/ while you are trying to kill its processes. When that happens, use the same chattr command on the /tmp/ directory and start over. If you are in doubt, use that chattr command on all aforementioned directories and start over. Very important: do not forget to use chattr -R -i on them afterwards!
  • In rare cases, the attacker may still be connected to your box. If possible, cut the internet connection and go over the disinfection steps. If this is not possible, firstly stop SSH by entering the command:
    sudo /etc/init.d/ssh stop

    Then, use iptables to drop any connection to the IPs the malware is connecting to (use netstat for example, see also Diagnosis) and to drop any connection from the attacker or cybercriminal. How to do this:

    In our example, we learned that our C&C's were and Thus, type or copy/paste these 2 commands:
    iptables -A OUTPUT -d -j DROP
    iptables -A OUTPUT -d -j DROP

    To block connection(s) from the attacker (you can find the attacker's IP using netstat for example):
    iptables -A INPUT -s $attackerIP -j DROP

    Don't forget to save your freshly created iptables rules by using the command
    /etc/init.d/iptables save

    Afterwards, change all passwords. (SSH, your user, root)

Best case scenario here is obviously:

  • restoring from a backup 
  • if the machine is virtual, restore to a previous snapshot
When you have either of these available, don't forget to change all passwords afterwards to prevent re-infection - and patch your machine(s)!

Some Xor.DDoS variants may also incorporate a rootkit. In that case, hope you have a "best case scenario" available to you. Once a box is fully compromised, it may be hard to reinstate it back to normal or its original state.

For double-checking for rootkits and other malware, you may want to check out chkrootkit. Alternatively, you can download and install an antivirus, for example ClamAV.

If you perform manual clean-up as indicated above and have confirmed all is in order again, you can install ClamAV and perform an extra scan to be sure. Better be safe than sorry. Then, follow the prevention tips below to stay safe.

  • Use strong passwords for SSH or use keys instead of passwords for authentication. You can read how to do that here. In the unlikely event of you not needing SSH to a particular machine, disable it on that machine by:
    sudo apt-get remove openssh-server

    To disable it from starting up you can use:
    update-rc.d -f ssh remove
  • Don't open the incoming SSH port (default 22) to ANY, but rather restrict it to trusted IP addresses.
  • For more information about safely using SSH, see: SSH: Best practices
  • Use a strong firewall. In Linux there are many options, iptables is a solid choice. A good basic iptables howto can be found here. In a network or if you need to protect several machines, you may want to consider a seperate hardware appliance as your firewall/UTM/... of choice.
  • Iptables can do a very decent job once properly configured. In case you want to do less manual work, I advise to check out sshguard or artillery. Both can monitor and alert you when something funky happens. In the context of our blog post, it also looks for & protects against SSH bruteforce attempts. Another application to consider is fail2ban. An additional tool is snort. For more information about these tools, refer to their pages.
  • Consider using SELinux. Security-Enhanced Linux is a compulsory access control security mechanism provided in the kernel.

  • Consider locking down cron jobs to only certain users. To deny all users from using cron you can use:
    echo ALL >>/etc/cron.deny
  • Consider disabling remote root login. Read how to do that here.
  • If you browse a lot, consider using NoScript as well.
  • Keep your software and applications up-to-date, as on any system.
  • Consider installing an antivirus as second opinion or at least as an additional layer. This is not a necessity but may come in handy. I recommend ClamAV.
  • Don't forget to protect other appliances that may be running on *nix systems, for example your router (and nowadays, IoT devices). Upgrade the firmware as soon as possible and change the default root/admin password(s). Install updates/patches for your particular firewall/UTM/... as well.
  • For even more (general) tips on hardening your Linux system (not against Xor.DDoS in particular):
    20 Linux Server Hardening Security Tips

Don't be fooled: Linux malware very much exists and starts to become more prevalent. Other prevalent Linux malware nowadays is:

  • Every ELF malware made by the ChinaZ actor or group (Linux/ChinaZ.DDoS, Linux/Kluh, ...)
  • Linux/Aes.DDoS (Dofloo, MrBlack)
  • Linux/Bash0day (Shellshock, Bashdoor)
  • Linux/BillGates (Gates.B)
  • Linux/Elknot (DnsAmp)
  • Linux/GoARM (Ramgo, Goram)
  • Linux/IptabLes and Linux/IptabLex

Note that this list is not complete and new ELF malware may pop up every day. (it's not a question of if, but when it will pop up) You can find a list of (interesting) Linux malware here.

Hopefully you have learned new things along the way of this blog post. For any specific questions, don't hesitate to leave a comment or contact me on Twitter: @bartblaze

To conclude this blog post, some acknowledgements and resources/references:


My colleague from Panda France, Julien Gourlaouen for informing me about this incident.

Everyone who helped, helps and will help in battling creators of ELF malware, in particular @MalwareMustDie for their excellent research and increasing awareness about these threats.

Last but not least, thank you for reading my blog post. 


AlienVault - Xor.DDoS hashes, IPs and domains (see also related pulses)
Avast -  Linux DDoS Trojan hiding itself with an embedded rootkit
Cisco -  Threat Spotlight: SSHPsychos
FireEye - Anatomy of a Brute Force Campaign: The Story of Hee Thai Limited
KernelMode - Linux/Xor.DDoS (samples)
KernelMode - List of Linux Malware
MalwareMustDie - Fuzzy reversing a new China ELF "Linux/XOR.DDoS"
MalwareMustDie - Linux/XorDDoS infection incident report (CNC: HOSTASA.ORG)
MalwareMustDie - A bad Shellshock & Linux/XOR.DDoS CNC "under the hood"
MalwareMustDie - Polymorphic in ELF malware: Linux/Xor.DDOS
Yale - ELF Format (PDF)


  1. Hi Bart,

    Nice review, in fact we had this Maware on one of our linux router machine because of the weakness of the root password !
    Also a rule was allowing inbound connection and IPS was not enable so the brute force was possible !
    Fortunately this infection was not very hard to desactivate :) (thx to Jon Maeso).
    This Malware was allowing us to have an ssh connection during 2 min at the beginning of each connection then it shut down the router (RAM and Proc at 100%). The only way to retrieve the ssh connection was to reboot the router.
    A good lesson for everybody: Never think that you can let your door opened during few min (Almost change it by another port and Nat it to another one).
    Big thanks to Bart (even if my knowledge doesn't permit to decrypt you entire post :p) to take the time to analyse this threat and to decompile the Malware process. I promess that the next one will not be as simple as this one was ^^.


    Gourlaouen Julien

    1. Thanks for the additional information Julien! I've now added a hint to deny ANY incoming SSH traffic and rather only the IPs you know/trust.

      My pleasure and be sure to let me know if you find any other interesting incidents ;)


  2. Nice, i caught it on my honeypot.

    1. Interesting Ziemeck! Please do not hesitate to share any of your findings :)


  3. Thank`s.

    p.s. patch for rkhunter:

    1. You're welcome and thanks for the link!

  4. No problem :)

  5. Well 3 days ago my private home server got hit reinstalled it the first time as i thought the random network glitches were a network driver so i switched over to Ubuntu no problems but software was limited so i switched it back to Centos 6 and found the right drivers. Long story short i stumbled across the htop report durring a CPU spike. took another 3 hours yesterday to pinpoint the program it was bash. so i killed the process and uptime started spiking the CPU roughly every 3 minutes so i ran a pmap on the PID and gave me a randomly generated name in the /usr/sbin directory. lot more research led me here following the steps above i have determined 2 things: first off its a 70% match to the one you found, and second its smart enough to hide kill old tasks and replace all files after you have removed them also its be re-associated with a couple different IP addresses the initial log in to the system was from Japan after looking at wireshark and the network traffic i believe the C&C is in the US (or at the least a proxy server) i still havent figured out any removal techniques for this new generation. Ive chased it around my lenny box 100 times.
    More information on my findings:

    1. Good day,

      Is it possible you can share the sample you are describing? I cannot seem to find the hash on VirusTotal. Do you have the IP addresses?

      Have you tried using chattr? Let's see if we can get rid of this malware on your machine.


    2. I do have a sample i can upload it some where for retrieval, I will need to find a location for it. I have used a chmod a-x (remove all execute) however the virus promptly deleted the file that i changed and set up a new one in the /tmp directory and then moved it back to the /usr/bin removing the cron job and supporting scripts yielded the same results

    3. Hi Drew,

      You can upload it to Mega or FileDropper for example.

      Have you tried following the disinfection step-by-step as described above? I think in this case using the chattr command on the /tmp/ directory, along with the other steps, will clean the malware from your machine.


    4. The file in question can be found here
      I also had a snapshot of the machine and so i just reinstalled it. Killing the process ID as mentioned above just respawned new tasks which made the removal steps sort of hard to follow. However since i have a copy of the bug and a virtualbox to play with i think im going to do a little more experimentation and see if if the above steps will still work with this one with a little bit tweaking i might come up with something. Hope that file helps. Bart thanks again for the post its been really informative.

    5. Hi Drew,

      Unfortunately, the file seems unavailable. Is it possible to re-upload? If you want, you can also send me the downloadlink via email (or the file in attachment). See contact details here:

      If you use chattr on the /tmp/ directory and others where it writes to, then kill the process, then clean out the cron jobs, then clean all leftovers it should work normally.

      My pleasure and let me know should you need any other help!


  6. Hi, Bart --

    Supremely valuable and well-written post, this. I had a VPS set up for playing around and learning-by-doing that got compromised with a similar trojan; the combination of running `chattr -R -i` on the various file locations AND checking `/etc/rcX.d` made the difference. Many thanks.

    Very best regards,
    Iain Gillis

    1. Hi Ian!

      Happy to hear you were able to remove the malware by following these steps.

      For sure, playing around will teach you the most :)

      Have a great day.


  7. Excellent and very useful summary!! I've had the misfortune to stumble upon this as well. The malware was contacting an IP address reported by 'whois' as belonging to China Telecom. First I was angry at them but now I believe they were the victims, not the perpetrators.

    As I am not much of a security guy it took me five days to get rid of this malware. This included the time to enlighten myself - but now I at least know what you fine people are talking about.

    I am gonna follow this blog religiously. Thanks again.


    Franz M Krumenacker

    1. Hi Franz,

      Xor.ddos indeed 'phones home' or contacts several IP addresses to either contact the attacker or... To attack other people.

      Glad to be of help, let me know if you've any other questions.


  8. Hi Bart,

    Where can I download the Linux/Xor.DDoS code sample?

    I'm a student and want to use this malware for my security project, I plan to run this malware and build a script to detect it

    Thank You for you help

    1. Hi Muhammad!

      In the 'Resources' section you can find the link to some samples.

      Or, see directly here:


  9. Today I found a version of this malware running in my ARM linux cubietruck miniPC I use for audio/torrenting/storage. It caught my eye a /tmp/.javaxxx file running (hating java pays off, finally)
    lsof -p inmediatelly showed what I was fearing; here is the output.
    I am still perplex of how it got in since it is running Debian 8.x which ships ssh root logins disabled by default.
    I couldn't get /tmp/.javaxxx since it had deleted itself.

    I can see a ton of direct ssh root access, and sadly the initial infection login, if it brute forced its access is lost to logrotate.
    root@cubie:~# zgrep "Accepted password for root from " /var/log/auth.log*|wc -l
    Tinkering (cat, cut, sort, uniq) with the IPs in the auth.log files, I got
    root@cubie:~# wc -l /tmp/lista
    118 /tmp/lista
    unique IPs from where they got access at some point.

    However this seem to be different
    - I don't see any of the automatic starting methods you describe. Nothing at /etc/cron.*, crontabs, or init.d rc.d, etcs. I rebooted the server and nothing started by itself. No config files seem to be added or modified.
    - I found many different binary files at /root/
    # ls
    e38sd.1 e38sd.3 i9js i9os.1 i9os.3 i9os.5 i9os.7 i9os.8 s36oa s36oa.2
    e38sd e38sd.2 f6ho i9os i9os.2 i9os.4 i9os.6 i9os.7.1 i9os.8.1 s36oa.1 s36oa.3
    Odd enough they are i386 binaries
    # file e38sd.1
    e38sd.1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
    This is the VirusTotal analysis:

    - This particular strain seems to also do spam, since my exim is clogged with 60k emails that it was unable to deliver.

    Wait.. Now that I am piecing the pieces together, it might be that these are two different infections. Or maybe the pushing server compiles i386 and ARM at the same time. Who knows.
    I will update if I find something else.
    Thanks for the interesting post.

    1. Hi Sebastian,

      Thanks for your comment!

      Xor.DDoS gang is able to push binaries for several architectures to commit their DDoSing.

      Is it possible you can share the other binaries you uncovered, or their hash?

      Also, do you still have the list of IPs where they tried to bruteforce from?

      As in regards to the malware: check out all links to the binaries you found are gone, and be sure to block any malicious traffic and change passwords.

      Xor.DDoS communicates to its C2 with at least these IPs I posted here, but probably there are more, depending on the other binaries you have:

      Hope this helps.


    2. Hi Bart and Sebastian,

      I also discovered the same binary "/tmp/.javaxxx" on one of my test servers today.
      After analyzing sshd logs, we found out that one account had been bruteforced and was running this binary, which has been deleted since.
      We have a dump of the process memory as well as the output of "lsof" and "netstat".
      In our case, it seems that the attacker never got access to root.
      I read your article and the one from MMD, in both cases the malware has been written in C. In the memory dump we have, we see what looks like a Go binary.
      I was wondering what kind of additional information we could provide to help identify this in the future? And where to submit that information?

    3. Hi Karouf,

      Thanks for sharing! What you can do is upload the memory dump to VirusTotal and send the resulting link:

      This will do 2 things:
      1. Researchers with VirusTotal access can download and analyse the sample
      2. VirusTotal will automatically send the sample to AV vendors, to improve detections rates.

      For the output of the 2 log files, can you post these on Pastebin (or Cryptobin, if you wish) and send the link?

      If you do not wish to upload the file to VirusTotal, you can send it to me privately, read here how:
      --> This way I can have a look at the binary.

      Hope this helps.


  10. I find this on my Raspberry Pi. Im using edited Chinese kernel for working on my KeDeI v6 display..

    1. Thanks for your comment! Do you have any hashes to share by any chance? Cheers!

  11. Left a brand new Raspberry Pi 3 with port 22 open overnight -- found the ".javaxxx" described by other poster here running 24 hours later. Think I may have interrupted it in the act of rooting the system as its behaved very erratically while I've been trying to recover control...

    1. Hi Unknown,

      If it's brand new Pi, it may be desirable to simply reinstall the system.

      Be sure to follow the prevention tips here to stay safe.

      Hope this helps, cheers!