Here is a quick follow up post regarding to our initial blog.
IoT_reaper Sample History
The historical delivery of the IoT_reaper samples we observed through our honeypot are as follow:
It is noticeable that most malicious samples for IoT_reaper are located at the following URL:
- Downloading URL: hxxp://126.96.36.199/sa
- Loader: 188.8.131.52
- Starting and ending time: 10-04～10-17
- Sample md5: 7, see IoC at the end of the article
The cohesion between the samples on this URL is fairly close, so we name it S cluster.
The S cluster also includes some other samples; and in addition to the S cluster, there is a LUA cluster, and other smaller unknown clusters. But we will focus on S cluster here.
About S cluster
S cluster contains samples on the following URLs:
The naming strategy within the cluster works like this:
- sa: arm
- sml：mips little endian
S Cluster C2 Layout, Infection Mechanisms and the Numbers
- loader : responsible for injecting malicious code to vulnerable devices via their corresponding vulnerabilities
- downloader : provides malware downloading
- reporter : receives information about potential vulnerable devices discovered by the bot net scanner
- controller : controls the bot, sends control commands
- We think there is a queue between the reporter and the loader, which the reporter will push the collected information on the potential vulnerable devices in, so the loader can take over and infect the targets
The number of potential vulnerable devices VS infected devices
- Number of potential vulnerable devices reported to one reporter's queue: over 2m till 2017-10-18;
- Number of infected bots controlled by one controller : over 28k till 2017-10-24
Note that there is a significant difference between the two numbers, the real reason is yet to be determined. But if we have to take a guess, it might be that IoT_reaper has some problem identifying potential vulnerable devices, so most devices in its queue are not really vulnerable. Or it may be because the attacker’s loader lacks the needed capacity and all the tasks get backlogged, or maybe the attacker deliberately slow down the infection rate to reduce the risk of exposure.
Infection Statistics on a Single S-cluster C2
From 2017-10-13 to 2017-10-23
Top 10 infected countries:
A comparison against Mirai early stage infection
The Most Recent S-clusters Sample Behavior
On October 23, we detected a change on following URL:
We have mentioned this sample in the original report, the "Sample Delivery, C2 Distribution and Traffic Pattern" section. This is a malware, which is placed on the downloader server and is delivered by the loader. After success delivery it will send heartbeat to controller, start scanning and then report the vulnerable device information to the reporter.
After a close look we find:
- A new exploit integrated : http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt
- Heartbeats go to e.hl852.com/e.hl859.com;
- 9 IP hard coded in sample, will always be scanned;
- Notice that there are 34 frequently scanned ports on the above 9 IPs. Within them, 17 ports are hard-coded, another 17 ports are not hard-coded in plain text in the sample, We speculate that the sample hides a logic somewhere to scan the last 17 ports.
About how this new 10th exploit get used by the botnet:
The 9 hard coded IP addresses:
184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168
And the corresponding network traffic for these 9 IPs. Note the traffic increased just after the new sample was released.
The 34 frequently scanned ports, hard-coded and non-hard-coded.
The DNS traffic of S-cluster C2s
- e.hi8520.com: the topmost blue curve in the corresponding graph
- e.hl852.com: the middle green curve
- e.ha859.com: the bottom yellow curve