A few years ago, the Mirai botnet was talked about because it caused a few major DDoS attacks around August 2016. The author later released the source code on hackforums under the name Anna-senpai. The source code of it is now available on GitHub.

Mirai botnet included a few innovative ideas that allowed it to spread blazing fast. One of them was to use a stateless port scanner. Stateless means that no state is kept during a port scan, and so, no memory needs to be used. This allows even low-spec hardware with few available memory (such as IoT devices) to scan a large number of IPs.

TCP Handshake

If you are unfamiliar with the TCP handshake, I recommend you reading the following Wikipedia article about it. Here’s a small reminder:

From the TCP RFC 793:

1) A --> B  SYN my sequence number is X
2) A <-- B  ACK your sequence number is X
3) A <-- B  SYN my sequence number is Y
4) A --> B  ACK your sequence number is Y

Because steps 2) and 3) are sent in a single packet, we call it a 3-way handshake. The sequence number sent from A to B is called the Initial Sequence Number 1 or ISN1. The sequence number sent from B to A is called the ISN2.

According to the TCP RFC, when a client initiates a connection to a server, it should use an ISN generator which selects a new 32 bit ISN. The generated number, then needs to be saved on the client-side, waiting for the SYN+ACK from the server. The Mirai ISN generator is very simple:

The ISN is simply set to the destination IP. This way, the scanner does not have to save the ISN into memory and checks the SYN+ASK this way:

When a Mirai scanner receives a valid TCP SYN+ACK, it opens a socket using the built-in TCP API, so the ISN is managed by the operating system. This way, the connections kept in memory are only connections to open ports, and memory is not wasted with half-open TCP connections.

Identification

The tcp->seq = ip->dst_addr is easily identifiable (either by the human eye, either by a computer) because all packets going to the same IP (even from different IPs) have all the same ISN. This can be seen looking at the ISN1 numbers or the graphics. Thanks to this pattern, we identified such scans on ports unused by the initial Mirai scanner. Indeed, the initial Mirai scanner was only looking at port 23 (9 out of 10 times) and port 2323 (1 out of 10 times):

An easy fix to get the scanner less identifiable is to XOR the destination IP with source IP. This pattern is still trivial to check with code, but would be less identifiable by the human eye because the ISN number would change more often.

Statistics

At D4, we have some packet captures coming from a black hole. A black hole is a monitoring network that has never been announced. As such, it should never receive traffic, except for Internet scans, mistaken systems and spoofed requests’ backscatter. By curiosity, we were wondering how the Mirai scanner trick is used and which ports are most targeted. We made a few statistics with data collected from 2020-01-16 to 2020-02-26 for a total of 42 days. Here are the most interesting ones:

Port 37215

The winner is port 37215 with 96.35% of Mirai-like scan:

Scan of port 37215 mainly targets CVE-2017-17215 affecting the router Huawei HG532 with unpatched firmware, making it possible for a remote user to execute arbitrary shell commands. The official security notice is available here. Further analysis is available here.

Port 9530

Second place is given to port 9530 with a very interesting pattern. This port started to be actively scanned on 2020-02-11:

This is in sync with ICS data:

This scan happened a few days after the full disclosure of a 0-day vulnerability affecting Xiongmai security camera from Vladislav Yarmak on 4 February 2020. This vulnerability allows an attacker to open a Telnet daemon on port 9527. Connecting with default credentials, an attacker can execute shell commands as root. The official security notice is available here.

PS: according to an article from OSM Solutions, this backdoor is a feature (not a bug).

HTTP ports 8[0-8]+

HTTP port 80, along with its most common alternatives 81, 82, 83, 85, 88, 8000, 8001, 8080, 8081 are the ones widely used for device administration. If the device’s owner did not change the administration password, there is a chance the valid password will be hardcoded and weak. Even if the password is complex, there is a chance the HTTP server is old and is subject to a public vulnerability, as we will see it later. The Mirai-like scanner developed a massive interest in those in January. In February, a few ports are forsaken: 82, 83, 85 and 8081. We can guess the success rate was not high enough:

Port 4567

This port is used by the protocol Technical Report 069 or TR-069. Interesting information can be found on Wikipedia and in the specification from the Broadband Forum (updated in 2018). This protocol is used for routers remote administration and firmware upgrades.

According to ISC, it is used by Verizon and other ISPs having Actiontec routers. We can find really old complaints about that back to 2007 for Verizon, 2010 for BT, 2014 for Century Link or more recently in 2019 for Plusnet. As we can see, this feature looks quite standard and is widely used. What about security? Here’s an overview:

The protocol makes use of a shared secret between the Customer Premise Equipment (CPE) and the Auto-Configuration Server (ACS) but gives no hint about the exchange of the secret. Because it is not standard, not all ISPs will have the same way of exchanging the secret. We can assume some may take the easy way out and use a common default password for all devices.

Even when secure and unique passwords are used, some devices make use of outdated web servers allowing authentication bypass. As an example, an analysis from Shahar Tal and Lior Oppenheim in 2015 revealed that more than 13 million devices were using RomPager 4.07 (released in 2002). An exploit is now publicly available since 2016.

Telnet ports 23(23)?

Unsurprisingly, since it was the original Mirai target ports, Telnet ports 23 and 2323 have a very high Mirai-like rate:

Port 5555

This port is used by the Android Debug Bridge (ADB) daemon on Android devices. As its name suggests, it is used for debugging purposes. Stock Android does not allow debugging by default. The user has to enable USB debugging first in the hidden developer menu and then run tcpip command over USB to enable network debugging . Moreover, Android 4.2.2, released in February 2013, added a security layer: the user has to unlock the device and accept the USB connection. It is hardly possible that a large number of users ran through all those steps to generate that interest:

According to an article from Hui Wang on Netlab and an analysis from Kevin Beaumont on DoublePulsar in February 2018, some manufacturers shipped Android devices with the network ADB bridge enabled and unauthenticated. Most devices are phones and TVs. Massive scans targeting this port started back in February 2018. At that time, the malware was using infected devices to mine cryptocurrencies. I doubt that a TV or a smartphone is very efficient for this job, but maybe this was profitable on a large scale. We can also find other analyses from TrendMicro and from ISC proving that the botnet was still active in July 2018.

Port 26

Port 26 is also interesting because we can see a huge increase in traffic from 2020-02-18. Mirai-like scan accounts for 47.43% of scans on this port.

An analysis has already been done by the Internet Storm Center and it seems like the scanner is trying to connect to a Telnet-like terminal. This may be explained by some network devices exposing a Telnet on this port.

Future work

During the next few weeks, we have planned to set up a few honeypots to emulate vulnerable devices and carry out interesting attacks. We hope to get more information about the current botnet ecosystem to confirm or invalidate our thoughts.

Any idea?

For non-described ports, we are still unsure about what kind of hardware the attacker is trying to detect. If you have any idea about that, feel free to contact us at d4@circl.lu.

Data

Here are the ports receiving the more Mirai-like scans:

IP==DST_IP is Mirai-like scans for this port / all scans for this port * 100

Graphics

Here are the graphics of those aforementioned ports:

Image from Unsplash, icons from FlatIcon.