{"id":11558,"date":"2018-02-21T22:40:20","date_gmt":"2018-02-22T06:40:20","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2018\/02\/21\/news-5329\/"},"modified":"2018-02-21T22:40:20","modified_gmt":"2018-02-22T06:40:20","slug":"news-5329","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2018\/02\/21\/news-5329\/","title":{"rendered":"OMG: Mirai-based Bot Turns IoT Devices into Proxy Servers"},"content":{"rendered":"

Credit to Author: Jasper Manuel, Rommel Joven, Dario Durando| Date: Thu, 22 Feb 2018 05:30:59 +0000<\/strong><\/p>\n

\n

\"\"<\/p>\n

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

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<\/a> and the targeting of more architectures<\/a>. 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<\/a> 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.<\/p>\n

In October 2016, an article<\/a> 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.<\/p>\n

In this article, we will also take a look at its similarities compared to the original Mirai.<\/p>\n

Mirai vs OMG<\/h3>\n

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<\/em> and OOMGA: applet<\/em> not found<\/em>. The name Mirai was given to the Mirai bot because of the strings \/bin\/busybox MIRAI<\/em> and MIRAI: applet<\/em> not found, <\/em>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.<\/p>\n

For this reason, we decided to name this variant OMG.<\/p>\n

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.<\/p>\n

<\/p>\n

Fig 1. Configuration table of OMG<\/p>\n

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.<\/p>\n

<\/p>\n

Fig 2. Mirai’s main modules<\/p>\n

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, <\/em>which resolves to 188.138.125.235.<\/p>\n

<\/p>\n

Fig 3. CnC domain resolution<\/p>\n

The CnC port, also included in the configuration table, is 50023.<\/p>\n

<\/p>\n

Fig 4. CnC port 50023<\/p>\n

Unfortunately, the CnC server was not responding when we did our analysis, so much of our findings are based on static analysis.<\/p>\n

When connected, OMG sends a defined data message (0x00000000) to the CnC to identify itself as a new bot.<\/p>\n

<\/p>\n

Fig 5. Data sent identifies it as new bot<\/p>\n

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<\/strong> to be used as a proxy server, 1<\/strong> for attack, and >1<\/strong> to terminate the connection.<\/p>\n

<\/p>\n

Fig 6. Expected option from CnC server<\/p>\n

OMG using 3proxy<\/h3>\n

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<\/em> and socks_proxy_port<\/em>. Once the ports are generated, they are reported to the CnC.<\/p>\n

<\/p>\n

Fig 7. Proxy setup<\/p>\n

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 .<\/p>\n

  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  <\/code><\/pre>\n

  Fig 8. Firewall enable\/disable function<\/p>\n
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.<\/p>\n
<\/p>\n
Fig 9. Proxy configuration<\/p>\n
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.<\/p>\n
Conclusion<\/h3>\n
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.<\/p>\n
As always, FortiGuard Labs will continue monitoring Mirai and its derivatives and share interesting insights from our research.<\/p>\n
Thank you for additional insights from our colleague Artem Semenchenko<\/em><\/p>\n
-= FortiGuard Lion Team =-<\/p>\n
IOC<\/u><\/p>\n
All samples detected as Linux\/Mirai.A!tr<\/p>\n
9110c043a7a6526d527b675b4c50319c3c5f5c60f98ce8426c66a0a103867e4e<\/p>\n
a5efdfdf601542770e29022f3646d4393f4de8529b1576fe4e31b4f332f5cd78<\/p>\n
d3ed96829df1c240d1a58ea6d6690121a7e684303b115ca8b9ecf92009a8b26a<\/p>\n
eabda003179c8499d47509cd30e1d3517e7ef6028ceb347a2f4be47083029bc6<\/p>\n
9b2fe793ed900e95a72731b31305ed92f88c2ec95f4b04598d58bd9606f8a01d<\/p>\n
2804f6cb611dc54775145b1bb0a51a19404c0b3618b12e41b7ea8deaeb9e357f<\/p>\n
CC<\/u><\/p>\n
54.234.123.22<\/p>\n
ccnew.mm.my<\/p>\n
rpnew.mm.my<\/p>\n
 <\/p>\n
Sign up for our weekly FortiGuard <\/em>intel briefs<\/em><\/a> or<\/em> to be a part of our <\/em>open beta<\/em><\/a> of Fortinet’s FortiGuard Threat Intelligence Service.<\/em><\/p>\n<\/div
https:\/\/blog.fortinet.com\/feed<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
<\/p>\n
Credit to Author: Jasper Manuel, Rommel Joven, Dario Durando| Date: Thu, 22 Feb 2018 05:30:59 +0000<\/strong><\/p>\n
In preparation for our talk entitled \u201cIoT: Battle of Bots\u201d 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.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10424,10378],"tags":[],"class_list":["post-11558","post","type-post","status-publish","format-standard","hentry","category-fortinet","category-security"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/11558","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=11558"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/11558\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=11558"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=11558"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=11558"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}