New Mirai variant Aisuru detects Cowrie opensource honeypots

A well-known honeypot used by malware researchers has been compromised by an evolution in the IoT botnet, Mirai. The new variant, named Aisuru, was first identified by researchers in Avira’s IoT Labs.

The research team at Avira have followed the evolution of the Mirai botnet that caused so much disruption to internet services in 2017: from its HolyMirai re-incarnation, through its Corona phase, and now into a complete new variant, Aisuru.

Aisuru is the first variant discovered with the capability to detect one of the most popular open source honeypots projects; Cowrie. Although opensource security projects are very worthwhile, this evolution is further evidence that they cannot be relied upon to provide full protection.

Hamidreza Ebtehaj, specialist researcher at Avira’s IoT  labs takes a deep dive into this new, and up until now, previously unidentified variant of Mirai.

Introducing Aisuru

In this article, we will analyze the newly identified Mirai variant and describe the honeypot detection methods that occur during Aisuru’s scanning phase.

In traditional Mirai, the scanning phase happens in three steps. An infected node:

1. Scans the internet for open ports (mostly Telnet and in some cases, SSH)
2. When an open port is found it tries to brute-force the login credentials.
3. After a successful guess it infects the new target by employing various techniques.

However, this new sample found in Avira’s IoT Labs has an additional step prior to infection: It checks if the target is a true device or a honeypot. If it identifies a honeypot, the infection operation is terminated, and the honeypot details are sent to the C&C server. The information obtained by this reconnaissance can be used later to avoid future interaction with the honeypot, or for a variety of other uses.

This honeypot detection mechanism should not be confused with honeypot evasion techniques. Honeypot evasion techniques have been used for a long time and are still common. Such techniques are briefly reviewed in the next section before we move on an analysis of the main sample.

A brief review on honeypot evasion techniques

Honeypot evasion techniques are a set of passive methods designed to prevent execution of malware when it is in a honeypot system. These methods are designed to prevent the disclosure of malware samples to security firms. A multi-layered infection vector is the most common evasion technique, and is used by various malware, including variants of Mirai and Hajime. This method leverages the fact that most common honeypots are simulation-based. They are incapable of executing payloads by infecting a device by a malware downloader first. This way, the downloader fails to run on a honeypot, and the actual malware will not be downloaded or exposed. However, the malware downloader will effectively operate on a real device and infect it.

Below, is an example of a malware downloader evading a honeypot. The code is self-explanatory and does not require any further investigation.

Analysis of the Aisuru bot

Aisuru bot, the new variant of Mirai, can detect and report back honeypots to its C&C. For that purpose, it has a function named “init_honeypot_report“.

As shown in the figure above, this function stores the honeypot address and port in a string of the form “IP:port” and sends it to the C&C server on port 5768, where a service runs to gather reconnaissance information. This function is triggered when one of three conditions are met:

1. The device name is “LocalHost“
2. Any service on the device is started on Jun 22nd, or Jun 23rd
3. A user exists on the device named “richard“

First condition: the existence of “@LocalHost:]”:

As shown in the figure below, the first honeypot indicator is the existence of “@LocalHost:]” in any of the command responses

When a shell is invoked, a prompt is the first thing displayed on every line. A user prompt looks like this:
user@computername:~$

Some honeypots use LocalHost as a default computer name when being set up while real devices are using more specific names. Logging into a computer named “LocalHost” indicates the existence of a honeypot.

Second condition: the existence of a service, started on Jun 22nd, or Jun 23rd:

The figure below shows the conditions when met, triggers honeypot detection

The existence of “Jun22” or “Jun23” in response to any commands sent to the device indicates the presence of a Cowrie honeypot. Cowrie is a well-known open-source Telnet and SSH honeypot project. Looking at Cowrie’s source code, we observe that in the response to “ps” command (process snapshot), We will receive a list of services that are all started on “Jun22″ or Jun23”.

In reality, there is little chance a device was rebooted or started on these two specific dates.

Third condition: when a user exists on the device named “richard“:

Looking at the last condition, the offset “.text:00012BBC”, we observe that honeypot detection is triggered when a string at the index of 162 of strings table is found in response to any of issued commands.

In the figure above, “table” is an array of string pointers. In the received versions of Aisuru bot, the strings table is initialized with 164 encrypted strings as shown below.

The encryption algorithm used in Aisuru botnet is simple, but unique. Is has never been used in any other Mirai variants before,  and does not exist in the original Mirai. As shown in the figure below, the decryptor is implemented by having three iterations on strings. In each iteration, the ASCII code of each character is subtracted by one and the order of characters in the string is reversed.

With a simple decryption script, we can unveil the list of strings, particularly the string at index 162.

The string at the index 162 of Aisuru botnet is “richard“. An another look into the list of users at Cowrie honeypot shows that,  a user exists in the Cowrie honeypot named “richard“.

Conclusion

Cowrie is one of the best honeypot projects ever with over 3000 stars at its GitHub repository and  thousands of installations. The smarter generation of IoT malware, particularly the Aisuru botnet, proves that open-source security projects in cybersecurity space, although very worthwhile, can fail in providing full protection.

At the Avira IoT Lab, we have developed our own honeypot and we regularly maintain it to ensure up-to-date protection for our customers. Our research team monitors such new malware families or variants and provide detections for them. Integrating Avira SafeThings and anti-malware technologies can help protect customers from such attacks.

Decryption script

Malware Hashes: