Attackers use a Linux / Remaiten bot to compromise embedded devices, part 2
In the first part of our research, we looked at several features of the Linux / Remaiten malware, namely, the internal structure of the bot loader, its interaction with the C & C server manager, the command bot processes, and the telnet scanner to search for other potential victims. We also noted the presence of malware components for microprocessor architectures MIPS and ARM. In addition, we were surprised to find a hint of the presence of bots for such platforms Power PC and SuperH.
In the second part, we will focus in more detail on the process of malware infection of other devices, as well as another interesting feature that allows Linux / Remaiten to complete the processes of other bots and programs on Linux.
')
Infection of other devices
The first step in this process is to search for a writable directory. The bot contains a list of popular paths to such directories, their list is shown below in the screenshot.
Fig. 19. List of directories on the victim's device where the bootloader can be copied.
After this, the bot, for unknown reasons, creates executable files called “ .t ”, “retrieve” and “ binary ”. The retrieve file will contain the loader itself, and the binary is requested by the bot from the C & C server manager. The “ .t ” file is not used by malware.
Fig. 20. The tenth case specializes in preparing the transfer of the payload to the device and its execution.
The malware uses a strange way to create empty executable files: it copies a standard executable file called busybox , which is present in most embedded devices, and then deletes all the contents from it with the " > file " command. The loader is transmitted to the device via telnet with a simple echo command, with each byte of the executable file being encoded using the “xHH” escape sequence. We observed a similar spreading technique in another malware called Linux / Moose .
Fig. 21. The code from the 11th case, which specializes in the transfer of the payload using the echo command.
Execution bootloader and IRC bot
After the bootloader has been copied onto the victim's device, it tries to load the payload of the malware onto it. The loader requests the bot's executable file from the C & C server manager and writes it to the stdout stream. At the beginning of its launch, the loader redirects the stdout stream to a file called “ binary ”. Finally, the file “ binary ” is launched for execution and the IRC bot becomes active.
Fig. 22. The code from the 13th case, which specializes in launching the execution of the loader and the bot.
Sending status to the managing C & C server
The last step for the bot is informing the C & C server about the success of infecting another device. In both cases, i.e., both in the case of a successful infection, and no, the bot also sends a login / password pair to the server, which was used to access the telnet account. It is possible that operators will try to infect the device manually if the automatic method of the malicious program used cannot cope with this.
Fig. 23. 14th case code that specializes in informing the C & C server about the infection status of another device.
Shut down other bots
Another interesting bot command is the KILLBOTS team. In the case of its receipt, the malware retrieves the list of running processes and searches for those that need to be completed. The search is based on several criteria, the main one being the search by name.
Fig. 24. List of process names to complete.
Fig. 25. List of processes that the bot ignores.
The Linux / Remaiten malware specializes in terminating only those processes that were launched from the interactive shell (shell) / dev / tty. It also sends the name of the completed process to the C & C server. Perhaps such an operation is carried out to improve the white and black lists of the processes of the malicious program.
Fig. 26. A bot sends a message to the server, and then kills the process itself using the kill API function.
Bot evolution
There are insignificant changes between different versions of the bot, for example, the composition of the white and black lists of processes to complete is different, the directories used by the loader to copy the bot’s body etc. are different. It is logical to assume that these and other similar changes are present in each new build of the malware in the same version of the malware. The bootloader is not subject to change, except for changing the list of hard-wired IP addresses and port numbers.
However, in version 2.2 of the malware, the authors made a significant change. It consists of using wget / tftp commands to load a shell script, which, in turn, specializes in booting the bot. A similar scheme is used by the Gafgyt malware. In the case when these two commands do not perform their work correctly, it loads the loader itself onto the device.
Fig. 27. The malicious program informs its C & C server about the deployment of the bot using the tools wget / tftp .
The command line script is distributed through another server, which is also used for the Gafgyt malware .
Fig. 28. Command shell script that is distributed through another server.
The batch file al.sh indicates the presence of intruders for microprocessors of PowerPC and SuperH architects. Prior to the Remaiten malware, we did not observe the use of bots by attackers for such architectures.
Fig. 29. Attackers supported architecture.
Fig. 30. The beginning of the script file.
The managing C & C server used in version 2.0 of the malware uses a strange welcome message. It contains a link to a well-known malware blog called MalwareMustDie .
Fig. 31. The welcome message for bot version 2.0 contains a link to the MalwareMustDie blog.
We assume that this is an attempt to discredit the MalwareMustDie team in the eyes of the users, since they placed a sufficient amount of material that Gafgyt and Tsunami expose.
Compromise Indicators (IoC)
Bot version 2.0
Bot version 2.1
Bot version 2.2
Bootloader Version 2.0
Bootloader version 2.1
Boot Loader Version 2.2
C & C version 2.0
Bot: 185.130.104.131:443
Loader: 185.130.104.131:25566
C & C version 2.1
Bot: 185.130.5.201:53
Downloads: 185.130.5.201:25566
C & C version 2.2
Bot: 185.130.5.202: 23
Loader: 185.130.5.202:443
In the second part, we will focus in more detail on the process of malware infection of other devices, as well as another interesting feature that allows Linux / Remaiten to complete the processes of other bots and programs on Linux.
')
Infection of other devices
The first step in this process is to search for a writable directory. The bot contains a list of popular paths to such directories, their list is shown below in the screenshot.
Fig. 19. List of directories on the victim's device where the bootloader can be copied.
After this, the bot, for unknown reasons, creates executable files called “ .t ”, “retrieve” and “ binary ”. The retrieve file will contain the loader itself, and the binary is requested by the bot from the C & C server manager. The “ .t ” file is not used by malware.
Fig. 20. The tenth case specializes in preparing the transfer of the payload to the device and its execution.
The malware uses a strange way to create empty executable files: it copies a standard executable file called busybox , which is present in most embedded devices, and then deletes all the contents from it with the " > file " command. The loader is transmitted to the device via telnet with a simple echo command, with each byte of the executable file being encoded using the “xHH” escape sequence. We observed a similar spreading technique in another malware called Linux / Moose .
Fig. 21. The code from the 11th case, which specializes in the transfer of the payload using the echo command.
Execution bootloader and IRC bot
After the bootloader has been copied onto the victim's device, it tries to load the payload of the malware onto it. The loader requests the bot's executable file from the C & C server manager and writes it to the stdout stream. At the beginning of its launch, the loader redirects the stdout stream to a file called “ binary ”. Finally, the file “ binary ” is launched for execution and the IRC bot becomes active.
Fig. 22. The code from the 13th case, which specializes in launching the execution of the loader and the bot.
Sending status to the managing C & C server
The last step for the bot is informing the C & C server about the success of infecting another device. In both cases, i.e., both in the case of a successful infection, and no, the bot also sends a login / password pair to the server, which was used to access the telnet account. It is possible that operators will try to infect the device manually if the automatic method of the malicious program used cannot cope with this.
Fig. 23. 14th case code that specializes in informing the C & C server about the infection status of another device.
Shut down other bots
Another interesting bot command is the KILLBOTS team. In the case of its receipt, the malware retrieves the list of running processes and searches for those that need to be completed. The search is based on several criteria, the main one being the search by name.
Fig. 24. List of process names to complete.
Fig. 25. List of processes that the bot ignores.
The Linux / Remaiten malware specializes in terminating only those processes that were launched from the interactive shell (shell) / dev / tty. It also sends the name of the completed process to the C & C server. Perhaps such an operation is carried out to improve the white and black lists of the processes of the malicious program.
Fig. 26. A bot sends a message to the server, and then kills the process itself using the kill API function.
Bot evolution
There are insignificant changes between different versions of the bot, for example, the composition of the white and black lists of processes to complete is different, the directories used by the loader to copy the bot’s body etc. are different. It is logical to assume that these and other similar changes are present in each new build of the malware in the same version of the malware. The bootloader is not subject to change, except for changing the list of hard-wired IP addresses and port numbers.
However, in version 2.2 of the malware, the authors made a significant change. It consists of using wget / tftp commands to load a shell script, which, in turn, specializes in booting the bot. A similar scheme is used by the Gafgyt malware. In the case when these two commands do not perform their work correctly, it loads the loader itself onto the device.
Fig. 27. The malicious program informs its C & C server about the deployment of the bot using the tools wget / tftp .
The command line script is distributed through another server, which is also used for the Gafgyt malware .
Fig. 28. Command shell script that is distributed through another server.
The batch file al.sh indicates the presence of intruders for microprocessors of PowerPC and SuperH architects. Prior to the Remaiten malware, we did not observe the use of bots by attackers for such architectures.
Fig. 29. Attackers supported architecture.
Fig. 30. The beginning of the script file.
The managing C & C server used in version 2.0 of the malware uses a strange welcome message. It contains a link to a well-known malware blog called MalwareMustDie .
Fig. 31. The welcome message for bot version 2.0 contains a link to the MalwareMustDie blog.
We assume that this is an attempt to discredit the MalwareMustDie team in the eyes of the users, since they placed a sufficient amount of material that Gafgyt and Tsunami expose.
Compromise Indicators (IoC)
Bot version 2.0
Bot version 2.1
Bot version 2.2
Bootloader Version 2.0
Bootloader version 2.1
Boot Loader Version 2.2
C & C version 2.0
Bot: 185.130.104.131:443
Loader: 185.130.104.131:25566
C & C version 2.1
Bot: 185.130.5.201:53
Downloads: 185.130.5.201:25566
C & C version 2.2
Bot: 185.130.5.202: 23
Loader: 185.130.5.202:443
Source: https://habr.com/ru/post/280672/
All Articles