{
	"id": "ebee1d67-e864-416c-9140-af0f91a9ba19",
	"created_at": "2026-04-06T00:13:44.116448Z",
	"updated_at": "2026-04-10T13:12:40.990252Z",
	"deleted_at": null,
	"sha1_hash": "a73c1e1f8651692ddbb892b46e5847a85220656d",
	"title": "Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2143669,
	"plain_text": "Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting\r\nLinux devices | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2022-05-19 · Archived: 2026-04-05 13:37:35 UTC\r\nUpdated September 12, 2022: New information has been added to the initial access and payload analysis sections in this\r\nblog, including details on a rootkit component that we found while investigating a XorDdos sample we saw in June 2022.\r\nIn the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in\r\n2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux\r\nendpoints and servers as well as its usage of XOR-based encryption for its communications.\r\nXorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed\r\non cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices,\r\nXorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to\r\nperform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated\r\nin August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can\r\nalso be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.\r\nBotnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force\r\nattacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables\r\nencrypted communications over insecure networks for remote system administration purposes, making it an attractive vector\r\nfor attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and\r\ninstalls XorDdos on the target device.\r\nXorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion\r\ncapabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based\r\nmalicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent\r\ncampaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also\r\nincludes various persistence mechanisms to support different Linux distributions. \r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 1 of 24\n\nFigure 1. A typical attack vector for XorDdos malware\r\nXorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other\r\ndangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the\r\nTsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and\r\ndistributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.\r\nMicrosoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular\r\nattacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our\r\nin-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy\r\nmalware.\r\nThis blog post covers the following topics:\r\nInitial access\r\nXorDdos payload analysis\r\nDetection evasion capabilities\r\nPersistence mechanisms\r\nArgument-based code-flow\r\nMalicious activity threads\r\nDDoS attack thread pool\r\nDefending against Linux platform threats\r\nDetection details\r\nHunting queries\r\nIndicators\r\nInitial access\r\nXorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential\r\ncombinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed\r\nsign-in attempts on devices successfully infected by the malware:\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 2 of 24\n\nFigure 2. Failed sign-in attempts on a device affected by XorDdos\r\nOur analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file\r\nto temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus\r\nconcealing the source of infection during forensic analysis.\r\nThe second method involves running a bash script that performs the following activities via the command line:\r\n1. Iterates the following folders to find a writable directory:\r\n/bin\r\n/home\r\n/root\r\n/tmp\r\n/usr\r\n/etc\r\n2. If a writable directory is found, changes the working directory to the discovered writable directory.\r\n3. Uses the curl command to download the ELF file payload from the remote location\r\nhxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as  ygljglkjgfg0.\r\n4. Changes the file mode to “executable”.\r\n5. Runs the ELF file payload.\r\n6. Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary.\r\nIn this case, it renames the Wget binary to good and moves the file to the following locations:\r\nmv /usr/bin/wget /usr/bin/good\r\nmv /bin/wget /bin/good\r\n7. Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.\r\n8. After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of\r\nthe following sensitive files with a newline character:\r\nSensitive File Description\r\n/root/.bash_history Contains the commands that were run earlier\r\n/var/log/wtmp Contains login related record for users\r\n/var/log/btmp Contains record of failed login attempt\r\n/var/log/lastlog Contains the recent login information for users\r\n/var/log/secure\r\nContains information related to security such as logs for authentication failure, sudo\r\nlogins, and authorization privileges\r\n/var/log/boot.log\r\nContains information related to system boot and message logged via system startup\r\nprocesses\r\n/var/log/cron Contains information related to cron job launch, success and failure error logs\r\n/var/log/dmesg\r\nContains information related to kernel ring buffer messages, hardware devices,\r\ndrivers, etc.\r\n/var/log/firewalld Contains logs related to firewall activities\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 3 of 24\n\nSensitive File Description\r\n/var/log/maillog Contains information related to a mail server running on the system\r\n/var/log/messages Contains generic system activity messages\r\n/var/log/spooler Contains messages from usenet\r\n/var/log/syslog Contains generic system activity messages\r\n/var/log/yum.log\r\nContains the package logs related to installation\\remove\\update activities done via\r\nyum utility\r\nFigure 3. Remote bash script command used for initial access\r\nWhichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos\r\nmalware. In the next section, we do a deep dive into the XorDdos payload.\r\nOther XorDdos variants that we recently saw in our investigations use this bash script installation method to either download\r\nor build its rootkit remotely. This installation method differentiates itself by matching the kernel build of the target device\r\nwith the rootkit available on the attacker’s command and control (C2) server.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 4 of 24\n\nFigure 4. XorDdos variant attack flow\r\nAfter enumerating the target device, the script communicates with the attacker’s C2 server, and checks if a rootkit that\r\nmatches the kernel build of the target device exists on the server. If it finds an existing rootkit that matches with the target\r\ndevice, the script downloads the rootkit. The following steps initiate the matching and downloading of the XorDdos malware\r\nand rootkit:\r\n1. The bash script gets the target device’s kernel-related information using the following sequence of commands and\r\nsends it to the attacker’s server:\r\nlsmod with tail to get the list of loaded Linux kernel modules\r\nModinfo extracts the vermagic number, a string containing information such as the kernel version number and\r\nCPU type used by the kernel module to load into kernel space. The vermagic number is gathered from the\r\nlisted kernel modules.\r\n2. The vermagic string is sent to the attacker’s server in encoded form.\r\nFigure 5. Screenshot of the ‘Modinfo’ command section that contains the ‘vermagic’ string in the rootkit\r\n3. If the rootkit binary specific to the kernel build exists on the server, it is downloaded along with the XorDdos ELF as\r\na compressed .tar file.\r\n4. The .tar file is further uncompressed in a new directory named after the string obtained by encoding the MD5 hash of\r\nthe vermagic string and created under the location /tmp on the target device. After the .tar file is uncompressed, the\r\nXorDdos ELF malware installs the XorDdos rootkit.\r\nIf the kernel build of the target device does not match any of the rootkits on the attacker’s server, the bash script initiates the\r\nfollowing steps to build and compile the rootkit remotely:\r\n1. The bash script prepares archived Linux kernel headers in the /tmp directory.  Linux kernel headers are defining C-language public kernel APIs and data structures to enable compilation of 3rd party kernel modules.\r\n2. The bash script downloads and launches the ELF binary uploader in /tmp. This binary uses an HTTP POST request to\r\nupload the archived kernel headers to the attacker’s server.\r\n3. The ELF binary removes the uploader component from /tmp to minimize XorDdos’ footprint.\r\n4. The uploaded archived kernel headers are used on the C2 server to build and compile the rootkit component. Thus,\r\nthe newly built rootkit component becomes available for download from the C2 server, also making it available for\r\nother future infections.\r\n5. The bash script then initiates the prior set of steps to download and install the XorDdos ELF malware, which installs\r\nthe rootkit into the target device.\r\nXorDdos payload analysis\r\nThe XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug\r\nsymbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier\r\nto debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 5 of 24\n\ncase, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part\r\nof the .strtab section in the ELF file:\r\ncrtstuff.c\r\nautorun.c\r\ncrc32.c\r\nencrypt.c\r\nexecpacket.c\r\nbuildnet.c\r\nhide.c\r\nhttp.c\r\nkill.c\r\nmain.c\r\nproc.c\r\nsocket.c\r\ntcp.c\r\nthread.c\r\nfindip.c\r\ndns.c\r\nThe above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.\r\nDetection evasion capabilities\r\nXorDdos contains modules with specific functionalities to evade detection, as detailed below.\r\nDaemon processes\r\nA daemon process is a process that runs in the background rather than under the control of users and detaches itself from the\r\ncontrolling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos\r\ntrojan uses daemon processes, as detailed below, to break process tree-based analysis:\r\n1. The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which\r\ninternally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the\r\ncalling process.\r\n2. After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is\r\nto ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be\r\nsuccessful. It then calls setsid() to detach itself from the controlling terminal.\r\n3. The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter\r\n__nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root\r\npartition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is\r\nstopped.  \r\n4. It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to\r\n/dev/null. It does this by calling dup2 on the file descriptor for /dev/null.\r\n5. The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the\r\ncurrent process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected.\r\nPerforming this evasive signal suppression helps stop the effects of standard libraries trying to write to standard\r\noutput or standard error, or trying to read from standard input, which could stop the malware’s child process. The API\r\nsignal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of\r\na programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the\r\nsignal corresponding to signum.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 6 of 24\n\nFigure 6. Ignore signals associated with the terminal-related operations\r\nXOR-based encryption\r\nAs its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode\r\nencoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated\r\ndata used across the malware’s various modules to conduct its activities.\r\nEncrypted strings Decoded value\r\nm7A4nQ_/nA /usr/bin/\r\nm [(n3 /bin/\r\nm6_6n3 /tmp/\r\nm4S4nAC/n\u0026ZV\\x1aA/TB /var/run/gcc.pid\r\nm.[$n__#4%\\C\\x1aB]0 /lib/libudev.so\r\nm.[$n3 /lib/\r\nm4S4nAC/nA /var/run/\r\n!#Ff3VE.-7\\x17V[_ cat resolv.conf\r\n\u003cEncrypted_Remote_URL\u003e hxxp://aa.hostasa[.]org/config.rar\r\nProcess name spoofing\r\nWhen a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument\r\nis always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and\r\noverrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 7 of 24\n\nFigure 7. Process name spoofing achieved by modifying memory associated with argument vectors.\r\nFigure 8. Output of the ‘ps -aef’ contains an entry for “cat resolv.conf”\r\nKernel rootkit\r\nSome XorDdos samples install a kernel rootkit, while others embed the rootkit in the XorDdos binary. Upon execution, the\r\nXorDdos binary drops the embedded rootkit component into the disk.\r\nA rootkit is a kernel module that hides the presence of malicious code by modifying kernel data structures. The XorDdos\r\nkernel rootkit generally has the following capabilities:\r\nProvide root access\r\nHide the kernel module\r\nHide the malware’s processes\r\nHide the malware’s network connections and ports\r\nBased on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by open-source projects\r\nlike Suterusu and Rooty.\r\nXorDdos attempts to hide itself by invoking its rootkit. The user mode malware calls the function getself(), which invokes\r\nreadlink() to fetch the location of the malware file image on disk.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 8 of 24\n\nFigure 9. Code used by XorDdos for self-replication.\r\nAfter this step, the malware tries to read the contents of its image file and loads it into a memory buffer, then sends a request\r\nto unhide() the process and deletes the image on disk. The technique allows XorDdos to bypass detection or minimize its\r\nmalicious footprint.\r\nThe XorDdos rootkit parses the in-kernel list of loaded modules to remove itself and the protected malware from the list.\r\nThis approach prevents tools like Ismod from listing kernel-loaded modules.\r\nFigure 10. __this_module refers to the current module that list_del tries to hide.\r\nThe following table describes the symbols found in the rootkit and their corresponding functionalities:\r\nFunction name   Description  \r\ngive_root  \r\nProvides a root privilege by setting a new set of credentials and assigning its UID,\r\nGID to “0”\r\nmodule_hide Hides the rootkit kernel module\r\nmodule_show Unhides the rootkit kernel module\r\nget_udp_seq_show\r\nHides the UDP4 connection by hooking /proc/net/udpHides the UDP6 connection\r\nby hooking /proc/net/udp6\r\nget_tcp_seq_show\r\nHides the TCP4 connection by hooking /proc/net/tcpHides the TCP6 connection\r\nby hooking /proc/net/tcp6\r\nhide_udp4_port Adds a provided port to a list of hidden UDP4 ports\r\nunhide_udp4_port Deletes a provided port from a list of hidden UDP4 ports\r\nhide_udp6_port Adds a provided port to a list of hidden UDP6 ports\r\nunhide_udp6_port Deletes a provided port from a list of hidden UDP6 ports\r\nhide_tcp4_port Adds a provided port to a list of hidden TCP4 ports\r\nunhide_tcp4_port Deletes a provided port from a list of hidden TCP4 ports\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 9 of 24\n\nFunction name   Description  \r\nhide_tcp6_port Adds a provided port to a list of hidden TCP6 ports\r\nunhide_tcp6_port Deletes a provided port from a list of hidden TCP6 ports\r\nunhide_allz Iterates list of all hidden ports and deletes all entries\r\nfirewall_acceptip Adds an IP address provided to accept_ips list\r\nunfirewall_acceptip Deletes a provided entry from accept_ips list\r\nfirewall_dropip Adds a provided IP address to drop_ips list\r\nunfirewall_dropip Deletes a provided IP address to drop_ips list\r\nhide_proc Adds a provided entry to hidden_procs list\r\nunhide_proc Deletes a provided entry to hidden_procs list\r\nProcess and port hiding\r\nThe malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in\r\nevading rule-based detections.\r\nThe /proc filesystem contains information related to all running processes. A user-mode process can get any process specific\r\ninformation by reading the /proc directory that contains the subdirectory for each running process on the system, such as:\r\n/proc/7728 – Contains process-id (PID) 7728-related information\r\n/proc/698 – Contains PID 698-related information\r\nRunning the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running\r\nprocesses as part of the ps command.\r\n\u003e strace -e open ps\r\nopen(“/proc/3922/status”, O_RDONLY) = 6\r\nopen(“/proc/4324/stat”, O_RDONLY) = 6\r\nopen(“/proc/4324/status”, O_RDONLY) = 6\r\nopen(“/proc/5559/stat”, O_RDONLY) = 6\r\nopen(“/proc/5559/status”, O_RDONLY) = 6\r\nopen(“/proc/5960/stat”, O_RDONLY) = 6\r\nopen(“/proc/5960/status”, O_RDONLY) = 6\r\nopen(“/proc/5978/stat”, O_RDONLY) = 6\r\nopen(“/proc/5978/status”, O_RDONLY) = 6\r\nIf the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.\r\nIn this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and\r\noutput control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate\r\nbetween the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its\r\nIOCTL calls from other IOCTL calls in the system.\r\nAlong with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the\r\nsecond entry stores the value to act on, such as $pid.\r\nCommand Usage\r\n0 Check if its rootkit driver is present\r\n1, 2 Hide or unhide \u003cPID\u003e\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 10 of 24\n\nCommand Usage\r\n3 Hide \u003cport\u003e\r\nHiding network connections\r\nThe rootkit also leverages kernel hooking to disrupt the regular invocation of various kernel system calls by substituting the\r\noriginal system call handler in the sys_call_table with its own. The hook functions ensure that the events associated with\r\nXorDdos’s malicious activity are filtered out, thus evading detection.\r\nThe /proc/net interface provides information about currently active TCP connections and is implemented by kernel APIs\r\ntcp4_seq_show() and tcp6_seq_show() .\r\nUtilities, such as netstat, acquire TCP/UDP connection information from files named /proc/net/tcp and /proc/net/udp. These\r\nfiles contain one entry per line, each indicating the source and destination port, the source and destination IP addresses, and\r\nother relevant information about the active connection.\r\nThe rootkit replaces the default read() system call with hook functions, filters the file read entries, and skips the port it\r\nintends to hide, further obfuscating C2 communications.\r\nThe following table lists kernel APIs and their hook names used by the rootkit:\r\nKernel API Hooked function by rootkit Function description\r\ntcp4_seq_show() n_tcp4_seq_show() Hiding /proc/net/tcp, TCPv4 connection\r\ntcp6_seq_show() n_tcp6_seq_show() Hiding /proc/net/tcp6, TCPv6 connection\r\nudp4_seq_show() n_ udp4_seq_show() Hiding /proc/net/udp, UDPv4 connection\r\nUdp6_seq_show() n_ udp6_seq_show() Hiding /proc/net/udp6, UDPv4 connection\r\nPersistence mechanisms\r\nXorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon\r\nsystem startup, as detailed below.\r\nInit script\r\nThe malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the\r\nsystem starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions,\r\nand dependencies.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 11 of 24\n\nFigure 11. Content of the init script dropped at the location /etc/init.d/HFLgGwYfSC.elf\r\nCron script\r\nThe malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the\r\nfollowing content:\r\nFigure 12. Content of the gcc.sh script\r\nIt then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:\r\nFigure 13. System command to delete the /etc/cron.hourly/gcc.sh entry from the /etc/crontab file and add a\r\nnew entry\r\nFigure 14. The content of the file /etc/crontab\r\nSystem V runlevel\r\nA runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style\r\noperating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system\r\nconfiguration and allows access to a different combination of processes. Some system administrators set a system’s default\r\nrunlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is\r\noperational. The /etc/rc\u003crun_level\u003e directory contains symbolic links (symlinks), which are soft links that point to the\r\noriginal file. These symlinks point to the scripts that should run at the specified runlevel.\r\nThe malware creates a symlink for the init script dropped at the location /etc/init.d/\u003cbase_file_name\u003e with the directories\r\nassociated with runlevels 1 through 5 at /etc/rc\u003crun_level\u003e.d/S90\u003cbase_file_name\u003e and\r\n/etc/rc.d/rc\u003crun_level\u003e.d/S90\u003cbase_file_name\u003e.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 12 of 24\n\nFigure 15. Installation of rc.d directory’s symlink scripts with /etc/init.d/\u003cbase_file_name\u003e\r\nAuto-start services\r\nThe malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s\r\nLinuxExec_Argv2 subroutine runs the system API with the provided arguments.\r\nThe commands chkconfig –add \u003cservice_name\u003e and update-rc.d then add a service that starts the daemon process at boot.\r\nFigure 16. chkconfig and update-rc.d commands install the startup service\r\nArgument-based code-flow\r\nXorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes\r\nits operation more robust and stealthy. The malware first runs without any argument and then later runs another instance\r\nwith different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.\r\nBefore handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its\r\nfull process path. The full path is used later to create auto-start service entries and read the file’s content.\r\nIn this section, we will cover the main tasks carried out as part of the different arguments provided:\r\n1: Standard code path without any provided arguments\r\nThis code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of\r\nthe entries created in system start-up locations.\r\nThe malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these\r\nlocations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.\r\nIt also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the\r\nfollowing steps, which modify the file hash to make every file unique:\r\nOpens the file for writing only\r\nCalls lseek (fd, 0, SEEK_END) to point at the last position in the file\r\nCreates a random 10-character string\r\nWrites the string at the end of the file with an additional null byte\r\nAfter modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 13 of 24\n\nFigure 17. The end of the malware file contains two random strings, ‘wieegnexuk’ and ‘yybrdajydg,’\r\nindicating that the original malware binary was modified twice\r\n2: Clean-up code path\r\nIn this code path, the malware runs with another argument provided as the PID, for example:\r\n/usr/bin/jwvwvxoupv 4849\r\nUsing the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check\r\nfor another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the\r\nfork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by\r\nthe init process, which disconnects it from the process tree and acts as an anti-forensic technique.\r\nAdditionally, it performs the following tasks on a provided $pid:\r\nFetches the process file name corresponding to the provided $pid\r\nDeletes the file for the provided $pid\r\nDeletes the installed init services:\r\nDeletes /etc/init.d/\u003cfile_name\u003e\r\nFor runlevels 1-5, unlinks and deletes /etc/rc\u003crunlevel\u003e.d/S90\u003cfile_name\u003e\r\nPerforms the command chkconfig –del \u003cfile_name\u003e\r\nPerforms the command update-rc.d \u003cfile_name\u003e remove\r\nEnds the process that was provided as an argument.\r\n3: Process name spoofing code path\r\nThe malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:\r\n/usr/bin/jwvwvxoupv “cat resolv.conf” 4849\r\n/usr/bin/jwvwvxoupv gnome-terminal 4849\r\n/usr/bin/jwvwvxoupv top 4849\r\n/usr/bin/jwvwvxoupv pwd 4849\r\n/usr/bin/kagbjahdic id 4849\r\nThe fake commands can include:\r\ncat resolv.conf\r\nnetstat -an\r\nbash\r\nwhoami\r\nid\r\ncd /etc\r\nifconfig eth0\r\nifconfig\r\necho “find”\r\nuptime\r\nsh\r\ntop\r\ngnome-terminal\r\nsu\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 14 of 24\n\nnetstat -antop\r\ngrep “A”\r\nwho\r\nls -la\r\npwd\r\nroute -n\r\nps -ef\r\nls\r\nsleep 1\r\nIn this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line\r\nat runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk\r\nrelated to the current process.\r\nIt then enters a five-second loop to perform the following checks:\r\nFetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on\r\n/proc/$pid/exe.\r\nIf the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:\r\nIntends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that\r\nallows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a\r\nsuccessful readlink API call.\r\nCreates directories similar to the standard code path scenario.\r\nCalls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy\r\nthe content of the current process’s image-file fetched earlier to the following locations with a random name:\r\n/usr/bin/\r\n/bin/\r\n/tmp/   \r\nCopies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on\r\n/lib/libudev.so.\r\nChanges the hash of the written or copied file and then runs it without passing any parameters.\r\nIf the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the\r\nremaining time out of five seconds.\r\nUnhides the current process and the $pid that was provided as part of the third argument.\r\nDeletes the on-disk file for the current process.\r\n4: Known locations code path without any provided arguments\r\nThis code path is similar to the standard code path, with the main difference being that the malware runs from one of the\r\nfollowing locations:\r\n/usr/bin/\r\n/bin/\r\n/tmp/\r\nOnce it runs from one of these locations, the malware calls the following functions to perform various tasks:\r\n1. InstallSYS – this function sets up the rootkit by extracting it under /usr/bin folder using a random name and loading it\r\ninto the kernel.  \r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 15 of 24\n\nFigure 18. Dropped files with random string names in /usr/bin\r\nAs mentioned in the XOR-based encryption section, the encoded string m7A4nQ_/nA translates to the folder path /usr/bin\r\nwhen decoded with the multi-byte key 0xBB2FA36AAA9541F0. The /usr/bin folder path is where the rootkit is dropped.\r\nThe dropped rootkit is further inserted into the Linux kernel module using the insmod command. This is followed by the\r\nremoval of the dropped rootkit from the disk.\r\nFigure 19. Screenshot of the XorDdos binary code where the highlighted insmod command calls functions to\r\ndrop the rootkit into the Linux kernel module.\r\nXorDdos uses /proc/rs_dev character device to communicate with the rootkit. It calls the CheckLKM() function to see if the\r\nrootkit meets the installation requirements, such as an exact kernel header match and no technologies present that can block\r\nthe rootkit’s installation, like secure boot or enforced signed loadable kernel module (LKM) loading.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 16 of 24\n\nFigure 20. The rootkit becomes accessible to the XorDdos malware by using the device handle /proc/rs_dev.\r\nXorDdos attempts to open /proc/rs_dev. If the Linux kernel module interface is up, XorDdos sends an IOCTL request with\r\nthe unique identifier 0x9748712 with argument “0” to open two-way communication between the XorDdos binary and its\r\nrootkit.\r\n2. AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system\r\nstarts.\r\n3. HidePidPort – Hides the malware’s ports and processes.\r\n4. CheckLKM – Checks whether the rootkit device is active or not, and to see if the rootkit meets the installation\r\nrequirements, such as an exact kernel header match and no secure boot or other technologies that can block the\r\nrootkit’s installation. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the\r\nrootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to\r\nchange the ownership of dropped files with the function lchown(\u003cfilename\u003e, 0xAD1473B8, 0xAD1473B8).\r\n5. decrypt_remotestr – Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar\r\nand the other directories. After decoding the URLs, it adds them into a remote list, which is later used to\r\ncommunicate and fetch commands from the command and control (C2) server:\r\nwww[.]enoan2107[.]com:3306\r\nwww[.]gzcfr5axf6[.]com:3306\r\nMalicious activity threads\r\nAfter creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a\r\ncyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is\r\ninitialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is\r\nused to maintain concurrency between threads accessing a shared object, such as kill_cfg data.\r\nThe malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP\r\nconnection, and retrieving kill_cfg data.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 17 of 24\n\nFigure 21. Semaphore and malicious thread initialization\r\n kill_process\r\nThe kill_process thread performs the following tasks:\r\nDecodes encrypted strings\r\nFetches file stats for /var/run/gcc.pid or, if none exist, then creates the file\r\nFetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the\r\nlocation /lib/libudev.so\r\nFetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the\r\ncurrent process\r\nReads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files,\r\nbased on the matching specified keys in the configuration file, such as:\r\nmd5=\r\nfilename=\r\nrmfile=\r\ndenyip=\r\ntcp_thread\r\nThe tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the\r\nfollowing tasks:\r\nReads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while\r\nconnecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte\r\nstring.\r\nCalculates the CRC header, including details of the device such as the magic string, OS release version, malware\r\nversion, rootkit presence, memory stats, CPU information, and LAN speed.\r\nEncrypts the data and sends it to the C2 server.\r\nWaits to receive any of the following commands from the C2 server and then acts on the command using the\r\nexec_packet subroutine.\r\nCommand Job\r\n2 Stop\r\n3 Create a thread pool for launching DDoS attacks\r\n6 Download file\r\n7 Update file\r\n8 Send system information to the C2 server\r\n9 Get configuration file to stop processes\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 18 of 24\n\nFigure 22. Collection of system information\r\ndaemon_get_killed_process\r\nThe daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier\r\n(hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30\r\nminutes.\r\nFigure 23. daemon_get_killed_process thread function fetches and decodes the kill_cfg data from the remote\r\nURL\r\nDDoS attack thread pool\r\nThe malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates\r\nthreads with twice the number of processors found on the device.\r\nInvoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands\r\nreceived from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.\r\nCommand Function Job\r\n0x4 fix_syn   SYN flood attack\r\n0x5 fix_dns   DNS attack\r\n0xA fix_ack   ACK flood attack\r\nDefending against Linux platform threats\r\nXorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system\r\narchitectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 19 of 24\n\nnumber of potential targets.\r\nAdept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and\r\nperforming DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems.\r\nMoreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.\r\nXorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with\r\ncomprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft\r\nDefender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation\r\nantimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat\r\ndata, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring,\r\nMicrosoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes\r\ndetecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a\r\nworld-writable location, and any potential follow-on activities on endpoints.\r\nDefenders can apply the following mitigations to reduce the impact of this threat:\r\nEncourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that\r\nsupport Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites,\r\nscam sites, and sites that contain exploits and host malware.\r\nUse device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for\r\nEndpoint. \r\nTurn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to\r\nuse cloud-based machine learning protections that can block a huge majority of new and unknown variants. \r\nRun EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.\r\nEnable network protection to prevent applications or users from accessing malicious domains and other malicious\r\ncontent on the internet. \r\nEnable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take\r\nimmediate action on alerts to resolve breaches, significantly reducing alert volume. \r\nAs threats across all platforms continue to grow in number and sophistication, security solutions must be capable of\r\nproviding advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will\r\ncontinue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting\r\nall the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.\r\nDetection details\r\nMicrosoft Defender for Endpoint detects and blocks XorDdos’s installer script and rootkit binary as the following malware:\r\nDoS:Linux/Xorddos.A\r\nDoS:Linux/Xorddos!rfn\r\nTrojan:Linux/Xorddos\r\nTrojan:Linux/Xorddos.AA\r\nTrojan:Linux/Xorddos!rfn\r\nBehavior:Linux/Xorddos.A\r\nBackdoor:Linux/XorDDoSRootkit.A\r\nTrojan:SH/XorDDoSinstaller.A\r\nWhen XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain,\r\nincluding the process tree, file information, user information, and prevention details.\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 20 of 24\n\nFigure 24. Microsoft 365 Defender alert for detection of XorDdos malware\r\nThe timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the\r\nMITRE ATT\u0026CK techniques and tactics, remediation status, and event entities graph.\r\nFigure 25. Microsoft 365 Defender timeline displaying that HFLgGwYfSC.elf was run from a world-writable\r\ndirectory and the remediation of dropped binaries\r\nEvents with the following titles indicate threat activity related to XorDdos:\r\nThe content of libudev.so was collected into libudev.so.6\r\nbash process performed System Information Discovery by invoking ifconfig\r\ngcc.sh was executed after being dropped by HFLgGwYfSC.elf\r\nA shell command was executed by crond\r\nSUID/SGID process unix_chkpwd executed\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 21 of 24\n\nFigure 26. Microsoft 365 Defender timeline with an event on a suspicious shell command run by crond after it\r\nwas dropped from HFLgGwYfSC.elf\r\nHunting queries\r\nTo locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365\r\nDefender or Microsoft Defender Security Center:\r\nFailed sign-ins\r\nDeviceLogonEvents\r\n| where InitiatingProcessFileName == \"sshd\"\r\nand ActionType == \"LogonFailed\"\r\n| summarize count() by dayOfYear = datetime_part(\"dayOfYear\", Timestamp)\r\n| sort by dayOfYear\r\n| render linechart\r\nCreation of the XorDdos-specific dropped files\r\nDeviceFileEvents\r\n| extend FullPath=strcat(FolderPath, FileName)\r\n| where FullPath in (\"/etc/cron.hourly/gcc.sh\", \"/lib/libudev.so.6\", \"/lib/libudev.so\", \"/var/run/gcc.pid\")\r\nCommand-line of malicious process\r\nDeviceProcessEvents\r\n| where ProcessCommandLine contains \"cat resolv.conf\"\r\nIndicators\r\nFile information\r\nFile name: HFLgGwYfSC.elf\r\nFile size: 611.22 KB (625889 bytes)\r\nClassification: DoS:Linux/Xorddos.A\r\nMD5: 2DC6225A9D104A950FB33A74DA262B93\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 22 of 24\n\nSha1: F05194FB2B3978611B99CFBF5E5F1DD44CD5E04B\r\nSha256: F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432\r\nFile type:\r\nELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for\r\nGNU/Linux 2.6.9, not stripped\r\nFirst\r\nsubmission in\r\nVT:\r\n2022-01-25 05:32:10 UTC\r\nDropped files\r\nDropped file path\r\nFile\r\ntype\r\nSHA-256\r\n/etc/init.d/HFLgGwYfSC.elf\r\nShell\r\nScript\r\n6E506F32C6FB7B5D342D1382989AB191C6F21C2D311251D8F623814F468952C\r\n/etc/cron.hourly/gcc.sh\r\nShell\r\nScript\r\nCBB72E542E8F19240130FC9381C2351730D437D42926C6E68E056907C8456459\r\n/lib/libudev.so ELF F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9\r\n/run/gcc.pid Text 932FEEF3AB6FCCB3502F900619B1F87E1CB44A7ADAB48F2C927ECDD67FF6\r\n/usr/bin/djtctpzfdq ELF 53F062A93CF19AEAA2F8481B32118A31B658A126624ABB8A7D82237884F0A\r\n/usr/bin/dmpyuitfoq ELF 798577202477C0C233D4AF51C4D8FB2F574DDB3C9D1D90325D359A84CB1BD\r\n/usr/bin/fdinprytpq ELF 2B4500987D50A24BA5C118F506F2507362D6B5C63C80B1984B4AE86641779FF\r\n/usr/bin/jwvwvxoupv ELF 359C41DA1CBAE573D2C99F7DA9EEB03DF135F018F6C660B4E44FBD2B4DD\r\n/usr/bin/kagbjahdic ELF E6C7EEE304DFC29B19012EF6D31848C0B5BB07362691E4E9633C8581F1C2D6\r\n/usr/bin/kkldnszwvq ELF EF0A4C12D98DC0AD4DB86AADD641389C7219F57F15642ED35B4443DAF3FF\r\n/usr/bin/kndmhuqmah ELF B5FBA27A8E457C1AB6573C378171F057D151DC615D6A8D339195716FA9AC2\r\n/usr/bin/qkxqoelrfa ELF D71EA3B98286D39A711B626F687F0D3FC852C3E3A05DE3F51450FB8F7BD2B\r\n/usr/bin/sykhrxsazz ELF 9D6F115F31EE71089CC85B18852974E349C68FAD3276145DAFD0076951F3248\r\n/usr/bin/tcnszvmpqn ELF 360A6258DD66A3BA595A93896D9B55D22406D02E5C02100E5A18382C54E7D\r\n/usr/bin/zalkpggsgh ELF DC2B1CEE161EBE90BE68561755D99E66F454AD80B27CEBE3D4773518AC45\r\n/usr/bin/zvcarxfquk ELF 175667933088FBEBCB62C8450993422CCC876495299173C646779A9E67501FF4\r\n/tmp/bin/3200\r\nELF\r\n(rootkit)\r\nC8F761D3EF7CD16EBE41042A0DAF901C2FDFFCE96C8E9E1FA0D422C6E313\r\nInstaller script\r\nBash\r\nscript\r\n8be8c950d8701ef1149c547ea3f949ea78394787ad1e19fc0eaa7bd7aeb863c2\r\n/usr/bin/djtctpzfdq ELF 53f062a93cf19aeaa2f8481b32118a31b658a126624abb8a7d82237884f0a394\r\n/usr/bin/jwvwvxoupv ELF 359c41da1cbae573d2c99f7da9eeb03df135f018f6c660b4e44fbd2b4ddecd39\r\n/usr/bin/kkldnszwvq ELF ef0a4c12d98dc0ad4db86aadd641389c7219f57f15642ed35b4443daf3ff8c1e\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 23 of 24\n\nDropped file path\r\nFile\r\ntype\r\nSHA-256\r\n/usr/bin/zvcarxfqul\r\nELF\r\n(rootkit)\r\n483451dcda78a381cc73474711bf3fcae97bd088f67b5a7e92639df52ef5ef25\r\n/usr/bin/zvzvmpqnv\r\nELF\r\n(rootkit)\r\nc8f761d3ef7cd16ebe41042a0daf901c2fdffce96c8e9e1fa0d422c6e31332ea\r\nDownload URLs\r\nwww[.]enoan2107[.]com:3306\r\nwww[.]gzcfr5axf6[.]com:3306\r\nhxxp://aa[.]hostasa[.]org/config.rar\r\nRatnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or\r\nwith Saurabh Swaroop\r\nMicrosoft 365 Defender Research Team\r\nSource: https://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nhttps://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/\r\nPage 24 of 24",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2022/05/19/rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices/"
	],
	"report_names": [
		"rise-in-xorddos-a-deeper-look-at-the-stealthy-ddos-malware-targeting-linux-devices"
	],
	"threat_actors": [
		{
			"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": 1775434424,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a73c1e1f8651692ddbb892b46e5847a85220656d.pdf",
		"text": "https://archive.orkl.eu/a73c1e1f8651692ddbb892b46e5847a85220656d.txt",
		"img": "https://archive.orkl.eu/a73c1e1f8651692ddbb892b46e5847a85220656d.jpg"
	}
}