Written by Kalle Bjorn, Director – Systems Engineering, Fortinet
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.
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.
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.
The CnC port, also included in the configuration table, is 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.
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.
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.
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
Copy
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.
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.
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.