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

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, ccnew.mm.my, which resolves to 188.138.125.235.

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_port and 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 .

  TABLE_IPTABLES1 -> used to INSERT a firewall rule.  iptables -I INPUT -p tcp --dport %d -j ACCEPT;   iptables -I OUTPUT -p tcp --sport %d -j ACCEPT;   iptables -I PREROUTING -t nat -p tcp --dport %d -j ACCEPT;   iptables -I POSTROUTING -t nat -p tcp --sport %d -j ACCEPT    TABLE_IPTABLES2 -> used to DELETE a firewall rule.  iptables -D INPUT -p tcp --dport %d -j ACCEPT;   iptables -D OUTPUT -p tcp --sport %d -j ACCEPT;   iptables -D PREROUTING -t nat -p tcp --dport %d -j ACCEPT;   iptables -D POSTROUTING -t nat -p tcp --sport %d -j ACCEPT  

Fig 8. Firewall enable/disable function

After enabling the firewall rule to allow traffic to pass through the randomly generated HTTP and SOCKS ports, it sets up 3proxy with predefined configuration embedded in its code.

Fig 9. Proxy configuration

As the server was not alive during analysis, we are assuming that the author sells access to the IoT proxy server, providing them access credentials.

Conclusion

This is the first time we have seen a modified Mirai capable of DDOS attacks as well as setting up proxy servers on vulnerable IoT devices. With this development, we believe that more and more Mirai-based bots are going to emerge with new ways of monetization.

As always, FortiGuard Labs will continue monitoring Mirai and its derivatives and share interesting insights from our research.

Thank you for additional insights from our colleague Artem Semenchenko

-= FortiGuard Lion Team =-

IOC

All samples detected as Linux/Mirai.A!tr

9110c043a7a6526d527b675b4c50319c3c5f5c60f98ce8426c66a0a103867e4e

a5efdfdf601542770e29022f3646d4393f4de8529b1576fe4e31b4f332f5cd78

d3ed96829df1c240d1a58ea6d6690121a7e684303b115ca8b9ecf92009a8b26a

eabda003179c8499d47509cd30e1d3517e7ef6028ceb347a2f4be47083029bc6

9b2fe793ed900e95a72731b31305ed92f88c2ec95f4b04598d58bd9606f8a01d

2804f6cb611dc54775145b1bb0a51a19404c0b3618b12e41b7ea8deaeb9e357f

CC

54.234.123.22

ccnew.mm.my

rpnew.mm.my

Sign up for our weekly FortiGuard intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.