Security researchers warned last week that attackers are building a massive botnet of more than a million routers and wireless cameras. However, additional research has revealed that the number of devices actually enslaved by the botnet is only around 20,000, for now.
“Over a million organizations have already been affected worldwide, including [in] the U.S., Australia and everywhere in between, and the number is only increasing,” researchers from Check Point said in an initial report Oct. 19 about the botnet, called IoT Reaper or IoTroop.
However, according to a new analysis by Arbor Networks, the botnet’s size currently fluctuates between 10,000 and 20,000 bots. This was also confirmed by researchers from Chinese security firm Qihoo 360, who said that around 28,000 devices have been infected in total so far.
Both Arbor and Qihoo warned that the botnet’s scanners have identified an additional 2 million potential targets that have not been infected yet, and it’s not entirely clear why.
“Possible explanations include: misidentification due to flaws in the scanning code, scalability/performance issues in the Reaper code injection infrastructure, or a deliberate decision by the Reaper botmasters to throttle back the propagation mechanism,” the Arbor Networks researchers said.
The Reaper botnet depends on four servers serving different purposes. Infected devices first scan ranges of internet IP addresses for other vulnerable devices. The bot has tests for various vulnerabilities in devices from GoAhead, D-Link, Netgear, AVTech, Vacron and Linksys.
Once a potentially vulnerable device has been identified, the bot sends information about it to a “reporter” server. This server then notifies a secondary one called the “loader,” which then sends an exploit to the vulnerable device.
If the exploit is successful, shell code is executed that reaches back to a third “download” server to obtain a payload compiled for the specific device architecture (ARM or MIPS). Finally, once the payload is executed and the infection is complete, the malware reports back to a fourth “controller” server.
The Reaper botnet was created by Chinese attackers and its main purpose appears to be the launching of distributed denial-of-service (DDoS) attacks. A year ago, another IoT botnet called Mirai was responsible for some of the largest DDoS attacks ever recorded on the internet, highlighting the danger of insecure IoT devices being connected to the internet.
“While Reaper is capable of launching SYN-floods, ACK-floods, http floods, and DNS reflection/amplification attacks, it is likely to have other, yet-to-be-determined DDoS attack capabilities, as well,” the Arbor Networks researchers said.
Fortunately, according to a new report Thursday from Check Point, the botnet’s control infrastructure has been taken down and the botnet is currently dormant, for now.
Files Encrypted by Bad Rabbit Are Recoverable in Certain Cases
Security researchers from Kaspersky Lab discovered some oversights in the Bad Rabbit ransomware that might allow victims to recover their files for free, though only in special conditions.
Like all threats from the Petya family of ransomware, Bad Rabbit has a two-step encryption process: First it encrypts files with certain extensions in user mode and then it replaces the system bootloader and encrypts the entire disk so the computer is completely locked after reboot.
Bad Rabbit uses strong encryption algorithms for both steps with no apparent implementation flaws, but the malware’s creators failed to take certain actions to ensure files can’t be recovered if the process is interrupted.
For one, the Kaspersky researchers found that Bad Rabbit doesn’t delete volume shadow copies before encrypting files. These are copies created by the Windows Volume Snapshot Service (VSS) and can be used to recover files encrypted by Bad Rabbit if the secondary full disk encryption step fails to execute for some reason.
The disk encryption is performed through a component called dispci.exe which is executed through a scheduled task. If there is software that monitors scheduled tasks and blocks suspicious ones, it might be possible for the process to fail, in which case files encrypted in the first step can be recovered from shadow copies.
Even if dispci.exe gets executed and encrypts the disk partitions, it might be possible to recover if the computer has not been rebooted, because apparently dispci.exe fails to remove the encryption password from memory before it exists.
“We found a flaw in the code of dispci.exe: the malware doesn’t wipe the generated password from the memory, which means that there is a slim chance to extract it before the dispci.exe process terminates,” the Kaspersky researchers said in their analysis.