What it is
XorDDoS takes over Linux servers and devices and uses them to flood websites and networks with traffic on command (a DDoS attack). It runs on several kinds of processor and has also been found on exposed Docker servers. Some versions load a kernel module (an add-on that runs inside the core of the operating system) that works as a rootkit, a tool that hides an attacker's presence: it hides files, processes and network ports. Because of that hiding, a server with XorDDoS can't be trusted to check itself.
How it gets in
By guessing weak SSH passwords on Linux machines reachable from the internet. One report also describes it reaching Docker servers whose management interface was left open.
Close the door: Disable SSH password login for root and use key-based authentication; where possible restrict SSH to trusted networks. Never expose the Docker daemon API without TLS client-certificate authentication or SSH. Where supported, enforce Secure Boot and signed kernel modules, which the cited report says can block the rootkit's installation.
How to tell if you have it
Signs published for this threat. One sign alone proves little: names get reused, and newer versions change them. Look for several together.
| Kind | Sign |
|---|---|
| File location | /lib/libudev.so |
| File location | /var/run/gcc.pid |
| File location | /etc/cron.hourly/gcc.sh |
| File location | /proc/rs_dev |
| File name | libudev.so |
| File name | gcc.pid |
| File name | gcc.sh |
| Scheduled task line | /etc/cron.hourly/gcc.sh |
| Startup entry | /etc/init.d/HFLgGwYfSC.elf |
| Startup entry | /etc/rc<run_level>.d/S90<base_file_name> |
These commands only look. They change nothing.
Look for the known file locations:
sudo ls -la /etc/cron.hourly/gcc.sh /etc/init.d/HFLgGwYfSC.elf /lib/libudev.so /proc/rs_dev /var/run/gcc.pid 2>/dev/nullSearch for the known file names (slow on big disks):
sudo find / -xdev \( -name 'libudev.so' -o -name 'gcc.pid' -o -name 'gcc.sh' \) 2>/dev/nullList running programs that live in a temporary folder (real software almost never does):
sudo ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/(tmp|var/tmp|dev/shm)/'Check every scheduled task for the known lines:
sudo grep -rnF -e '/etc/cron.hourly/gcc.sh' /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/nullFingerprint a suspect file and compare it with the list below:
sudo sha256sum /path/to/suspect-fileKnown file fingerprints (SHA-256). A match identifies that exact file; newer builds differ.
How sure these signs are: Some versions hide files, processes and ports, so a check run on the infected server can miss it, and finding nothing does not prove the server is clean. libudev.so and gcc.sh copy real names: the real libudev lives in a different folder with a version number, so only a file at exactly /lib/libudev.so is a sign. /proc/rs_dev only exists while the rootkit is loaded, and the rootkit hides itself, so not seeing it proves nothing. Startup script names change with each copy: /etc/init.d/HFLgGwYfSC.elf is one example, so look for S90 links in /etc/rc1.d to /etc/rc5.d pointing at scripts you don't recognise. It changes each copy of itself so every file has a different fingerprint, which means a fingerprint that doesn't match proves nothing. These signs come from 2022 to 2023 reports, and one report saw it still active in February 2025.
How to deal with it
Removing it in place isn't safe. Here is what to do instead, in order:
- Don't try to clean it in place. Plan to rebuild the server from a fresh install.
- Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence: /etc/cron.hourly/gcc.sh and the line in /etc/crontab that runs it, the scripts in /etc/init.d and their S90 links, /lib/libudev.so, /var/run/gcc.pid, and the SHA-256 fingerprint of each suspect file. If you can, collect them from a rescue disk, because the infected system can hide things from you.
- Copy off your data: databases, website files and documents. Don't copy programs, startup scripts, scheduled tasks or kernel modules; any of those could bring it back.
- Reinstall from a fresh image, install all updates, then restore only the data you copied and checked.
- From a clean computer, change every SSH key, password and token that was on the server, and cancel the old ones.
- Before you reconnect, turn off password logins for root over SSH and use keys instead, and allow SSH only from networks you trust. Never leave Docker's management interface open without certificate logins or SSH. Where your system supports it, turn on Secure Boot and allow only signed kernel modules; the report says this can stop the rootkit installing. Keep checking for the signs above.
What Minaki Scan does about it
Minaki Scan looks for this threat and reports it only when at least two signs agree. It never tries to remove it: it tells you to back up your data and rebuild.
Minaki Scan checks your server every day for this and the other threats in this wiki. $1 per server a month. Downloads open soon.
Sources
This page is written by MinakiLabs in our own words. The facts above come from this published research; credit and thanks to its authors.
- Unmasking the new XorDDoS controller and infrastructure, Cisco Talos (2025-04-17)
- Protect the Docker daemon socket, Docker Inc.
- SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
- Blocking Dedicated Attacking Hosts Is Not Enough: In-Depth Analysis of a Worldwide Linux XorDDoS Campaign, Palo Alto Networks Unit 42 (2023-10-16)
- Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices, Microsoft Security Blog (2022-05-19)