Playing with a Mirai honeypot: MTPot

A few weeks ago I ran into an open source honeypot developed by Cymmetria Research and I decided to give it a try. Its name is MTPot and it’s a fairly simple deception tool that is nevertheless able to give us a good understanding of how Mirai works and allow us to gather some interesting data. This article summarizes the results I have obtained from my testing and data collection and it is mainly focused on fingerprinting and identification of the botnet components and their distribution.

MTPot is written in Python and makes use of a JSON config file that holds some essential information:

• the ip and port to which the honeypot shall bind
• a list of commands expected to be sent by the scanners and the responses that MTPot shall give
• the name of the attack (Mirai)
• a session timeout value
• some optional syslog settings to collect the fingerprinted IPs

Deploying and running MTPot is quite straightforward, all it takes is to install Python and a couple of packages and you’ll be good to go. You’ll obviously want to make sure that MTPot is listening on a public IP or, in case your machine is behind NAT, you’ll have to resort to port forwarding.

MTPot in function showing logged interactions.

Let’s now see more in details where MTPot fits and, to better understand it, let’s have a look at a depiction of the Mirai structure

Source: “Techniques for detecting compromised IoT devices” Authors: Ivo van der Elzen, Jeroen van Heugten
University of Amsterdam.

The interactions that MTPot intercepts are the default credential scans performed by the bots on the potential victim (B to V in the picture) and the sessions established by the loaders, during which the victim is instructed to download the malware (L to V in the picture).

MTPot is not programmed to download and execute the malware.

As soon as I started collecting data, I noticed a few distinctive traits in the commands received by MTPot. The most noticeable one is the check string issued by the bot right after it has gained access to the device. As a matter of fact, Mirai executes shell commands within busybox and its first concern is obviously to make sure that busybox is available in the system. To do so, it sends the command

/bin/busybox

followed by an arguably random string. The response that the bot expects is the given string followed by “applet not found”. A few hypothesis were made on the additional purposes this string serves, the main one being a sort of testing instrument to discern between IoT devices’ OS and fully-fitted Linux distributions.

From the first tests, I have noticed that the string tends to vary but within the boundaries of a certain family. Below you can find a list of the strings that I was able to collect in 10 hours of logged sessions, with the number of times each string was observed.

786 MIRAI
486 FREEPEIN
120 OBJPRN
20 MEMES
20 MASUTA
18 ECCHI
18 zsqodmnvb
6 NJASD

This variety of strings, some of which are references to the anime world, seems to prove the fact that multiple variants of Mirai are currently available. It is important to note that the default JSON configuration file only contains the response to the string ECCHI, therefore the honeypot will not be able to effectively respond to other variants unless the configuration file is edited to do so.

Moving away from the string distribution, another interesting result of this first data collection is obviously the Source IP distribution. In this phase, I was able to observe a total of 139 scanners from every geographic area.

The chart below shows the Country distribution.

Geo distribution of scanner IPs collected in 10 hours. IP details obtained with https://www.infobyip.com/

It’s worth noticing how the China-based sources account for almost half of the total.

As we all know by now, behind the great success of Mirai, lies the infamous lack of security of many of the things that are part of today’s Internet. Many cameras, DVRs, printers, routers are in fact ready to work “out of the box”, with no need to change their default credentials. Below you can see the most used credentials during the scanning phase, preceded by the number of times they were used and, where possible, followed by an indication of a device that uses those credentials as default ones (ref: krebsonsecurity)

45 user:root pass:xc3511 — Device: H.264 — Chinese DVR
35 user:root pass:123456
30 user:admin pass:admin
29 user:root pass:vizxv — Device: Dahua Camera
28 user:support pass:support
28 user:root pass:juantech — Device: Guangzhou Juan Optical
28 user:root pass:888888 — Device: Dahua DVR
26 user:root pass:default
24 user:root pass:admin — Device: IPX-DDK Network Camera
24 user:admin pass:password

I used the results obtained during the first phase of data collection to try to make the honeypot more responsive and effective for the second phase.

I did so by adding the list of discovered check strings to the JSON configuration file, with the expected response for each one of them. I also took advantage of a contribution that was made to the original MTPot release. The branch version, now merged into the master one, added a response to the /bin/echo command (thanks to GitHub user morgajp for this). With such response in place, the honeypot is able to interact with the loader to the point where the latter instructs the former to download the malware, sending the URL to retrieve it.

Loader-Honeypot interaction with the instruction on where to retrieve the malware.

The results obtained in this second phase are very interesting as they allowed me to identify vital components of the botnet.

During this second data collection phase, lasted 10 hours, I was able to identify the IPs of 7 loaders. You can find them listed below, sorted by the number of times they told my MTPot where to get Mirai.

Loaders observed in a 10 hour window. IP details obtained with https://www.infobyip.com/

Last but not least, I was able to collect information about some of the malware distributors. This was possible as the malware URL is delivered to the potential victim in clear text, together with the instruction to fetch it (wget) and followed by a grant of permissions.

Detail of a session where the Loader instructs the victim to download a copy of the malware from a distributor.

Below are the IPs of the 6 distributors I was able to identify in this phase, sorted by the number of times they were passed to MTPot by the loaders.

Malware distributors observed in a 10 hour window. Details obtained with https://www.infobyip.com/

MTPot is a quite simple but functional low-interaction honeypot. As made clear by the authors, some functions that had initially been planned were not implemented due to limited time. The execution is not free of exceptions, but that has never become a blocking issue in my personal experience. It’s an open source project and it might go through future evolutionary stages.

In the same way it’s reasonable to assume that Mirai code, that with MTPot shares the open source nature, might evolve and become able to fingerprint this and other deception tools.