Virustracker · 2016/04/08 10:56…

0 x00 preface

ESET researchers are actively detecting trojans that target embedded systems, including routers, gateways and wireless access points. Recently, we found a related bot that incorporates Tsunami (also known as Kaiten) and Gafgyt with some improvements and new functionality. This new threat is Linux/Remaiten. So far, we’ve found three versions of Linux/Remaiten, version 2.0, 2.1, and 2.2. Based on its code, the Trojan’s authors called it “KTN-Remastered” or “KTN-rm.”

In this article, we’ll explain the special propagation mechanisms of Linux/Remaiten, the new features, and the differences between versions.

0x01 Improved propagation mechanism

The most prominent feature of Linux/Gafgyt is Telnet scanning. When a Telnet scan is performed, the Trojan attempts to connect to a random IP address through Internet port 23. If the connection is successful, the Trojan attempts to guess login credentials based on a built-in list of user names/passwords. After a successful login, the Trojan will issue a shell command to download multiple bot executables of different architectures and try to run them. This method of infection is simple, but can cause a lot of interference because only one binary can run under the current architecture.

Linux/Remaiten improves on this propagation mechanism by carrying downloaders. Trojan downloaders are dedicated to CPU architectures for embedded Linux devices, such as ARM and MIPS. After logging in to the affected device through Telnet, the Trojan horse tries to determine the device platform and transfers a downloader applicable to that platform. The downloader’s job is to contact the CC server and request a Linux/Remaiten bot binary for the device platform. Then, run the BOT binary on the new victim device to create a new BOT for the attacker to use.

0x02 Technical analysis downloader

Linux/Remaiten Downloader is a small ELF executable embedded in the BOT binary. When executed, the downloader will connect to the BOT’s CC server and send one of the following requests, followed by another line:

  • mips
  • mipsel
  • armeabi
  • armebeabi

The CC server responds with an ELF BOT binary based on the requested architecture. Note that the TCP port used to connect to the CC server is not the BOT’s IRC server.

Figure 1- Downloader requests a BOT binary from CC

Figure 2- Downloader connecting to CC

The downloader’s only job is to send one of the previously mentioned commands to the CC server and write the response to stdout. In this case, the command sent is MIPS.

Figure 3- Downloader requests a MIPS bot from CC

0 x03 bot analysis

When executed, the bot runs in the background by default. When running the bot with the “-d” command, the bot stays in the foreground. Once started, the process masquerades as a legitimate name, such as “-bash” or “-sh.” We observed that versions 2.0 and 2.1 used “-bash” and version 2.2 used “-sh”.

Figure 4 – bot start

Next, create_daemon creates a file named “.kpid “in one of the following default daemon directories (the first one has write permission) and writes its PID to this file.

Figure 5- Daemon file directory

If the. Kpid file already exists, the running Trojan process will be killed according to the PID in the file. The file is then removed, a new “.kpid “is created, and execution continues.

Figure 6- Trace pid file creation

0x04 Connects to the CC server

In bot binary, a CC server IP address table is hardcoded. The BOT randomly selects an address and connects to the selected CC via a hard-coded port. Different variants will use different ports.

Figure 7-bot Connecting to a CC server

If the connection is successful, the BOT then enters the IRC channel. CC responds with a welcome message and subsequent instructions. The BOT parses and executes these instructions on the infected device.

Figure 8-CC responds the welcome message to bot

0x05 Handle IRC command

The BOT can handle a variety of generic IRC commands. These command and function handlers are listed in an array.

Figure 9 – IRC command

The most interesting of these is the “PRIVMSG” command. This command will require the bot to perform some malicious operations, such as flooding, downloading files, and Telnet scanning. Commands sent via “PRIVMSG” are also rendered as static arrays.

Figure 10- Bot commands available

Most of the functionality is from Linux/Tsunami and Linux/Gafgyt. The following strings in binary are associated with malicious behavior. This detailed introduction gives us an idea of what these strings do.

Figure 11 – flooding function

Figure 12-Telnet scan, download files, and kill other bots

0 x06 built-in downloader

As mentioned earlier, Linux/Remaiten is unique in that it carries multiple small downloaders, and if there is a version that fits the architecture of the victim device, the Trojan will transfer the corresponding downloaders to the device. On execution, the downloader contacts the CC and requests a BOT binary.

Figure 13- Built-in payload

Figure 14- Payload structure

0x07 Telnet scanner

Figure 15- Guessing Telnet login credentials

Remaiten’s Telnet scanner starts when CC issues the “QTELNET” command. Analysis shows that the command description provided by the Trojan author is correct: this Telnet is indeed an enhanced version of the Gafgyt Telnet scanner.

Telnet scanning is done in stages and can be summarized as follows:

  1. Select a random public IP address and connect it to port 23
  2. Try username/password grouping
  3. Determine the architecture of the affected device
  4. Sends and executes the corresponding downloader

The Trojan horse checks the architecture of the device by running the cat $SHELL command and parses the result. The SHELL environment variable contains the path to the executable, which currently serves as a command line translator. If the file is an ELF executable, the file header is parsed to determine its schema.

Figure 16- Identify victim platform & check if there is a downloader suitable for this platform

Figure 17- Part of the function responsible for parsing ELF headers

The BOT then selects the appropriate payload and sends it to the new victim device.

Figure 18- The function responsible for selecting the payload based on the device architecture

The first step is to find a directory to write to. There is a common table of writable paths in Linux/Remaiten.

Figure 19- Directory for saving the downloader

Several empty executables were created: “. T “, “Retrieve” and “binary”. The “Retrieve” file will contain the downloader, and the “binary” is the bot requested from the CC server. It appears that the ‘. T ‘file was not used until version 2.2.

Figure 20- Preparing the payload for transmission and execution

Linux/Remaiten takes a strange approach to creating empty executables: Trojans copy the Busybox binary (found on most embedded devices) and use the >file command to short the binary.

The downloader is transmitted through Telnet, and each byte is encoded with a hexadecimal “\x” transposition byte by issuing the echo command. We’ve seen trojans using this technique spread across embedded Linux devices, such as Linux/Moose.

Figure 21- Transferring the payload HexString with echo

When the transfer is complete, the downloader starts and retrieves the full Linux/Remaiten payload. The downloader requests a BOT binary from CC and writes it to standard output, and the deployment command redirects the output to a “binary” file. Finally, launch the “binary” file to activate the new IRC bot.

Figure 22- Executing downloader and bot

0x08 Sends status to CC

Before resuming a Telnet scan, the BOT reports its progress to the CC server. The bot sends the new device IP, the correct user name/password, and whether it has infected other devices. If automatic infection fails, could botnet administrators manually infect other devices or collect data from unsupported architectures?

Figure 23- Notify the CC server of bot deployment status

0x09 Kill another Bot

Another interesting command is “KILLBOTS”. After issuing this command, the bot enumerates the running process and then decides whether to ignore or kill the process based on certain criteria, mainly the process name. Different bot versions may choose different process names.

Figure 24- Name of the process to kill

Figure 25- Process name to ignore

Linux/Remaiten kills only processes started by an interactive shell based on the tty device number of the process. In addition, the Trojan also reports to the CC server which processes it has killed, perhaps in order to modify its process whitelist or blacklist.

Figure 26- The bot is killing the process

0x0A Linux/Remaiten Change log

There are only slight differences between bot client versions, such as process whitelist and blacklist changes, downloader directory changes, etc. It is reasonable to suspect that there may be differences between compiled versions, even if the version number does not change. Among the bots we analyzed, their downloader binaries were the same, but their IP addresses and ports were different.

As with Gafgyt, v2.2 will still download the shell script by executing the wget/ TFTP command, which will then download the BOT binary. The propagated code first tries this method before transferring the downloader.

Figure 27- Notify CC to deploy bot via WGET/TFTP

The shell script is published by another server, which is also responsible for sending the Gafgyt bot.

Figure 28- Shell script published by another server

From the al. Sh file, this is the first time we’ve found bots for platforms like PowerPC and SuperH. Although cross-platform compilation tools are available, it is surprising that attackers have problems compiling their own trojans. We don’t know which device is running on the PowerPC or SuperH.

Figure 29- Shell script download bot

Figure 30- The beginning of a shell script

The CC server used in version 2.0 provides an unexpected welcome message: it references a MalwareMustDie blog.

Figure 31- version 2.0 of CC references the MalwareMustDie blog

Perhaps this was in retaliation for MalwareMustDie exposing Gafgyt and other trojans.