OMG: Mirai-based Bot Turns IoT Devices into Proxy Servers

Haythem Elmir

In preparation for our talk entitled “IoT: Battle of Bots” at the RootedCon Security conference that will be held in Madrid, Spain this March 2018, the FortiGuard Labs team encountered yet another new Mirai variant.

Since the release of the source code of the Mirai botnet, FortiGuard Labs has seen a number of variations and adaptations written by multiple authors entering the IoT threat landscape. These modified Mirai-based bots differ by adding new techniques, in addition to the original telnet brute force login, including the use of exploits and the targeting of more architectures. We have also observed that the motivation for many of the modifications to Mirai is to earn more money. Mirai was originally designed for DDoS attack, but later modifications were used to target vulnerable ETH mining rigs to mine cryptocurrency. In this article we will discuss about how a Mirai-based bot called OMG turns an IoT device into a proxy server.

In October 2016, an article was published by Brian Krebs about how cybercriminals earn money by converting IoT devices into proxy servers.  Cybercriminals use proxies to add anonymity when doing various dirty work such as cyber theft, hacking into a system, etc. One way to earn money with proxy servers is to sell the access to these servers to other cybercriminals. This is what we think the motivation is behind this latest Mirai-based bot.

In this article, we will also take a look at its similarities compared to the original Mirai.

Mirai vs OMG

We begin by taking a look at the configuration table of OMG. The table, originally encrypted, was decrypted using 0xdeadbeef as the cipher key seed, using the same procedure adopted for the original Mirai. The first thing we noticed are the strings /bin/busybox OOMGA and OOMGA: applet not found. The name Mirai was given to the Mirai bot because of the strings /bin/busybox MIRAI and MIRAI: applet not found, which are commands to determine if it has successfully brute-forced its way into the targeted IoT device. These strings are similar with other variations such as Satori/Okiru, Masuta, etc.

For this reason, we decided to name this variant OMG.

This variant also adds and removes some configurations that can be found in the original Mirai code. Two notable additions are the two strings that are used to add a firewall rule to allow traffic on two random ports, which we will discuss in the latter part of the article.

Fig 1. Configuration table of OMG

It looks like OMG keeps Mirai’s original modules, including the attack, killer, and scanner modules. This means that it can also do what the original Mirai could, i.e. kill processes (related to telnet, ssh, http by checking open ports, and other processes related to other bots), telnet brute-force login to spread, and DOS attack.

Fig 2. Mirai’s main modules

After initializing the modules, OMG proceeds to connect to the command and control (CnC) server. The configuration table below contains the CnC server string,, which resolves to

Fig 3. CnC domain resolution

The CnC port, also included in the configuration table, is 50023.

Fig 4. CnC port 50023

Unfortunately, the CnC server was not responding when we did our analysis, so much of our findings are based on static analysis.

When connected, OMG sends a defined data message (0x00000000) to the CnC to identify itself as a new bot.

Fig 5. Data sent identifies it as new bot

Based on the code, the bot receives a 5-byte long data string from the server, with the first byte being the command on how the IoT device will be used. Expected values are: 0 to be used as a proxy server, 1 for attack, and >1 to terminate the connection.

Fig 6. Expected option from CnC server

OMG using 3proxy

This variant of Mirai uses 3proxy, an open source software, to serve as its proxy server. The set up begins by generating two random ports that will be used for the http_proxy_portand socks_proxy_port. Once the ports are generated, they are reported to the CnC.

Fig 7. Proxy setup

For the proxy to work properly, a firewall rule must be added to allow traffic on the generated ports. As mentioned earlier, two strings containing the command for adding and removing a firewall rule to enable this were added to the configuration table .

To read the original article:

Laisser un commentaire

Next Post

The Blue Whale Suicide Game : conseils préventifs pour protéger son enfant

Pour protéger nos enfants de ce jeu morbide, on propose aux parents de modifier certains comportements responsables de la réclusion de la victime. Mettre son enfant à l’abri de ce jeu, n’est pas une tâche évidente, dans une époque où même les petits et les adolescents ont un accès libre […]