IoT Reaper

Short facts:

Reaper (aka IoT_reaper or IoTroop) is a growing botnet identified in September 2017. The malware facilitates various exploits of IoT devices which makes it impossible for common IT security solutions to detect the malware, identifying it as yet another Advanced Persistent Threat. Like the 2016 detected Mirai botnet, Reaper could potentially be used for large-scale DDoS attacks as well as any for other cyber attack.


On October 20, 2017, the IT analyst known as yegenshen at Chinese cybersecurity firm Netlab 360 reported a new botnet targeting IoT devices. Yegenshen called the botnet »IoT_reaper« which since then has become known as »Reaper«. In his first blog post the analyst spoke of about 10,000 infested devices that are controlled solely by one C2 (Command And Control Server). Just five days later, the number had risen to 28,000. He went on to name the C2 server as an example and expected further C2 servers down the line. In addition, at least two million IoT devices were suspected in a waiting loop, which were intended to test for use in the botnet and subsequently to infect.

All information in this article as of November 23, 2017.

Origin of Reaper

So far, the authors of Reaper are unknown. Initial analysis shows that the malware is based in part on the code of the Mirai botnet. In 2016, Mirai compromised approximately 500,000 IoT devices and used them for repeated Distributed Denial-of-Service (DDoS) attacks. Among other things, the DNS service provider Dyn was attacked at that time making a number of websites such as Twitter, Netflix and Reddit unavailable for a longer period of time. Furthermore, the Mirai botnet was used for the hacking of Telekom DSL routers on November 27, 2016.

Although there is a certain relationship between Reaper and Mirai, both botnets differ significantly. Above all this concerns their attack vectors. Mirai gains access using default passwords from IoT devices, which are set up by default by the manufacturer and are often left untouched by users.
Reaper, however, uses specific exploits of IoT devices to take control.

Special features of Reaper

According to yegenshen's analysis, Reaper uses vulnerabilities from a total of nine IoT devices. The use of default passwords is waived. Device Remark Source D-Link 850 L router Multiple vulnerabilities





D-Link 850 L Router

Multiple vulnerabilities

D-Link DIR-300 und DIR-600 (rev B) Router

Multiple vulnerabilities

Various Goahead IP-Cameras

Multiple vulnerabilities


Multiple vulnerabilities

Netgear ReadyNAS Surveillance Systems

Netgear DGN Router

Vacron NVR IP-Surveillance Systems

VacronLinksys E1500 / E2500 Router

Multiple vulnerabilities

VacronAVTech IP-Cameras

Multiple vulnerabilities

The authors react very flexibly to changes. For example, the vulnerability of the Vacron NVR IP surveillance systems was integrated into the botnet just days after it was discovered. This speaks for a very active support of the botnet. At the same time, the comparatively slow spread of Reaper so far suggests a very careful approach by the authors. Most likely they are still mainly testing its functionality.

The malware is integrated in a LUA environment. LUA is known as a simple yet powerful scripting language that is used for complex and efficient programming. This increases the potential to use Reaper to perform equally complex, agile attacks that go far beyond Mirai's DDoS attacks.

The botnet has already embedded over 100 DNS Open Resolvers in its LUA sample. This makes it very easy to perform massive DNA amplification attacks using the Reaper botnet.

Architecture of Reaper

Reaper consists of four components that can be reached via different IP addresses. Presumably, this structure is mirrored on several C2 servers: 

1. Downloader: Samples (eg other malware programs) can be downloaded via this IP address.
2. Controller: Controls the bots and sends commands.
3. Reporter: Potentially vulnerable IoT devices are reported to this IP address.
4. Loader: Loads the bots via the mentioned exploits on potentially vulnerable IoT devices.

Functionality of Reaper

After the initial check of an IoT device, the Loader loads the bot program onto the device via the corresponding exploit. Upon successful installation, the Controller immediately takes control of the device and downloads additional programs / samples to the infected device via the Downloader. In addition, the infected device is used to examine the network for other potential devices. Identified devices are reported to the Reporter.

Potentially, any downloadable malware can be downloaded to an infected device via the Downloader. Hence, the Reaper acts exclusively as a door opener and »hostage taker«.

Purpose and Risk of Reaper

At the time of the article, neither the purpose nor the effects of the botnet were known. The authors of the Reaper were still in the process of expanding and testing the botnet. So far, the botnet is inactive except for the ongoing infection of new IoT devices.

Potentially, every form of cyberattack is conceivable, including:

  • large-scale DDoS attacks as in 2016 with the botnet Mirai;
  • facilitation of other malware that attacks, disturbs or paralyzes the systems behind it (eg via ransomware);

For example, Reaper could also spill over to other systems and network components. This can affect both corporate IT and industrial control systems (IIoT devices).

For the latter, three possible ways are briefly presented here:

1. Facilitating exploits of IIoT devices:
The authors of Reaper work very agile. They react immediately to newly discovered exploits and add them to previous attack vectors. It seems they are just waiting to discover new vulnerabilities. Currently, no IIoT devices are directly affected. This may be because the authors so far lack exploits for the corresponding devices. However, as new loopholes become known (or become available in the Darknet), that could change quickly.

2. Spreading of the infection on basis of the operating system:
Reaper attacks mostly Linux-based devices. The botnet uses infected devices to scan and infect the network to other devices. In addition to the device-specific exploits, generic Linux vulnerabilities could also be used as an entry gate. This allows the authors to expand the device types and manufacturers. 

3. IoT devices as a middleman:
Reaper uses a powerful LUA environment. Therefore, it can not be ruled out that a complex malware that targets »underlying« devices or entire networks is channeled through the infected IoT devices into the systems. Since IoT devices, office devices and IIoT devices have long been interconnected, a network penetration could be holistic.

Why did common IT security technologies fail with Reaper?
Reaper has so far been able to fly under the radar for three reasons:

1. Common security solutions such as virus scanners, firewalls and intrusion detection systems are neither aware of the devices’ exploits nor of the malware. As a result, they did not recognize the Reaper as a malware.

2. Few companies have so far installed a system that completely recognizes changes within their own network and within the communication structures (level 2 protection). They limit themselves to the perimeter backup, which, however, is powerless against Advanced Persistent Threats.

3. Because of compatibility issues and availability requirements, organizations often cannot update their components on an ad-hoc basis to install security updates that close the vulnerabilities. Hence, devices usually run with old security settings over a longer period of time, thus remaining vulnerable or infected.

How to detect Reaper?

A real-time anomaly detection solution based on Deep Packet Inspection technology immediately detects a Reaper infection and immediately reports it to the administrator.

With regard to IIoT devices, the industrial anomaly detection solution Rhebo Industrial Protector would already detect the infection as a new, unusual communication in the network during its first steps of take over. It would report it directly to the administrator as a high-risk anomaly, due to Reaper's interference with the administrator rights of the IIoT device. This would enabled a prompt introduction of countermeasures (eg blocking, quarantine or segmentation).
The initial infection - the basic penetration of the network - would probably not be avoided per se. For this purpose, the level 1 security tools at the perimeter of the network (eg firewall, IDS) would have to detect the attack reliably. Since this is not possible, Rhebo Industrial Protector acts as a level 2 tool that detects and reports all hazards and anomalies which slipped through the security barrier of level 1 tools. However, with the early detection of suspicious communication Rhebo Industrial Protector can prevent the botnet from spreading and getting active (via new commands from the Controller or download of other programs from the Downloader). Hence, operators would have full transparency on any actions within their network and could react in real-time.


You might also be interested in