Mirai is somewhat unique in the computer underground because its source code was leaked to the internet and posted on Github for everyone to see. This has been a boon to both the defensive and offensive computer security communities alike. If you’re on defense, you can use the source code as map to building better detection and prevention mechanisms, and if you’re on offense you can tweak the source code to create new versions of Mirai that enhance its destructive power and simultaneously evade whatever the defense comes up with. This is a perfect illustration of the constant cat and mouse game played between the computer offense and defense, but in this case it is more “out in the open” than usual.

At Extreme Networks, since we try to help customers instead of attacking them, let’s dive into how to detect Mirai network communications. Broadly speaking, there are two classes of activities that Mirai performs:

1. Compromising new hosts to force them into the botnet (including command and control once they are compromised).
2. Attacking systems worldwide with various types of DDoS attacks.

In this article, we are going to focus on the first activity and leave a discussion of DDoS attacks to a future post.

So, how does Mirai compromise new hosts? Recall the Mirai botnet is built on top of IoT devices which typically do not have the latest and greatest defensive security mechanisms in place. Actually, it is worse than this. Mirai doesn’t need to have any sophisticated exploit capability – it just looks for devices with default administrative credentials left enabled. This is a common problem for network-connected systems in general, but is more common for IoT devices that typically have custom management interfaces that are not as familiar to users as, say, Windows. Given the massive number of IoT devices already connected to the Internet today and the acceleration of this looking into the future, it is no wonder Mirai packs an enormous punch.

Mirai scans the Internet looking for open telnet servers running on either port 23 or port 2323. When it finds one, it then tries to authenticate via a set of known default credentials. If the authentication is successful, it has just found a new device to compromise and bring into the existing botnet. The first step in detecting Mirai botnet scanning is to look for port sweeps on ports 23 and 2323. However, in a quirk unique to Mirai, scanning nodes do not scan for these two ports on an equal basis. As you can see from the connection counter “i” in the following code snippet, Mirai scans for port 23 vs. 2323 in a 1/10^th ratio.

Mirai likely does this for practical reasons – the vast majority of telnet servers run on port 23 instead of 2323, so it would waste resources to scan for them evenly. On the defense side of things, we can use this distinct pattern as means to differentiate scans. That is, many malicious nodes scan for port 23, and some scan for port 2323 too, but those that scan for ports 23 and 2323 in a 1/10^th ratio are almost certainly infected with Mirai. In other words, the particular implementation chosen by Mirai to efficiently find targets is used by the computer defense as a means to enhance detection of Mirai scanning nodes. Developing such a detector is beyond the scope of this article, but would be fairly easy to implement. Further, even without the knowledge of the 1/10^th scanning ratio, traffic collected from Mirai scanning and used as input to a machine learning detector could likely also extract the same signal from the noise.

Now, what happens when a Mirai scanner finds a new reachable telnet daemon? It then tries a series of default administrative credentials to see if it is able to authenticate to the target. These default credentials can be found here, and a screenshot of a few of them is included below:

Similarly to detecting Mirai port scans, we can also develop a detector to parse network traffic and watch for telnet connections with username/password combinations that match the list Mirai uses. This has already been done in publicly available intrusion detection rule sets. Here is an example of such a rule for the Suricata IDS:

alert tcp $EXTERNAL_NET any -> $HOME_NET [23,2323] (msg:”ET MALWARE Linux.Mirai Login Attempt (xc3511)”; flow:to_server,established; content:”xc3511|0d 0a|”; dsize:8; reference:url,www.flashpoint-intel.com/when-vulnerabilities-travel-downstream; classtype:trojan-activity; sid:2023333; rev:4; metadata:affected_product DVR, attack_target IoT, created_at 2016_10_10, deployment Datacenter, malware_family ddos_bot, performance_impact Low, signature_severity Major, updated_at 2016_11_08;)

Given the discussion to this point, it is reasonable to ask the question “how many IoT devices today offer an unprotected telnet server to the Internet?”. To explore this question and many others, the venerable Shodan search engine comes to the rescue. A personal favorite source of mine for interesting Shodan queries can be found here. As a spectacular example of finding an interesting set of IoT devices, you can find all Tesla Powerpack web interfaces connected to the Internet via this Shodan search. An example screenshot of the Tesla web interface found through Shodan appears below:

In conclusion, the Mirai botnet will remain an important source to inform both the computer security offense and defense for years to come. Because its source code is publicly available, we can build decent detectors for Mirai communications, but the offense can also more easily create new versions of Mirai that evade these measures. In the long term, it is an open question as to whether the offense or the defense will gain the upper hand in this game, but one thing is clear – the IoT target environment is massive and only increasing. Defense had better win.