'Reaper': The Professional Bot Herder’s Thingbot
Is it malicious? So far it's hard to tell. For now it's a giant blinking red light in security researchers faces warning us that we’d better figure out how to secure the Internet of Things.
Justin Shattuck contributed to this article.
This isn’t your mama’s botnet. This is a proper botnet. If you were the world’s best Internet of Things botnet builder and you wanted to show the world how well-crafted an IoT botnet could be, Reaper is what you’d build. It hasn’t been seen attacking anyone yet, and that is part of its charm.
The interesting aspect of Reaper is not its current size, but its engineering, and therefore its potential. But from a pure research perspective, we’re interested in how Reaper is spreading. Instead of targeting weak auth like a common thingbot, Reaper weaponizes nine (and counting) different IoT vulnerabilities. Consequently, we think the current media focus on “the numbers,” instead of the method, is a tad myopic.
Size and Position
Brian Krebs puts the current size of Reaper at over 1M IoT devices. We have data that suggest it could grow to include over 3.5M devices and growing at 85,000 devices per day. The reason Reaper could get so big is that, unlike its predecessors, Mirai and Persirai, Reaper uses multiple attack vectors. Mirai used default passwords. Persirai used the blank username+password combo, which, frankly, we think is such a doofus security error on the part of the manufacturer that we feel it barely deserves to have a CVE.
Reaper is almost showing off by not even trying the password cracking, and instead just exploiting different vulnerabilities (RCE’s, web shells, etc.) in nine different IoT vendor devices.
Reports on the “size” of Reaper vary. We’ve scanned 750,000 unique devices that match the nine vulnerabilities currently exploited by Reaper. We regularly scan 85,000 new “reaper-compatible” devices per day. We don’t know which of them are actually infected, but there’s no reason that Reaper itself couldn’t infect them, unless its authors didn’t want it to.
The nine vulnerabilities currently used by Reaper are fairly rudimentary, as vulnerabilities go. If the thingbot authors were to include a few dozen, existing vulnerabilities that fit Reaper’s device targeting profile, we think they could grow the thingbot an additional 2.75 M nodes. If they wanted to. Adding that 2.75 M to the 750,000 that are currently “Reaper-compatible” gives the number 3.5 M. (Note: We will not be disclosing the additional CVE’s, as that would simply expedite the authors’ exploits.)
The actual size of Reaper is probably limited to whatever size its authors want it to be. Right now it feels like its authors are experimenting. Building and testing. Maybe Reaper is pure research. We don’t know, and that’s kind of why we respect it.
Is It Malicious?
So far, Reaper hasn’t been seen attacking anyone with massive volumetric DDoS attacks. Yes, that’s a good thing. At least one of us thinks it might never be seen attacking anyone. If Reaper were to start being used as the ultimate Death Star weapon, that would cheapen its value. It would also result in active takedown campaigns.
Remember how at least two strike-back bots were created to combat Mirai after it attacked Krebs, OVH, and Dyn? Brickerbot actively wiped the filesystems of infected IoT devices (in many cases, turning them into little more than bricks). Hajime was more polite and merely blocked ports and left a cute little note informing the device owner that their device was participating in attacks and please stahp!
If Reaper starts attacking people with DDoS, it will turn from a marvel of thingbot infrastructure engineering into (yawn) another volumetric attack tool. The bot herders would be hunted down by law enforcement (ala the Mirai case), and the bot would be disassembled.
What Is It Doing?
Right now, Reaper is an object lesson for IoT manufacturers and security researchers. It’s like a giant blinking red light in our faces every day warning us that we’d better figure out how to secure IoT.
We’ve been monitoring the Persirai botnet for the last six months. We regularly measured Persirai at 750,000 IP cameras. Persirai was never seen attacking anyone, either, and we speculated about what it could be doing. For example, besides DDoSing victims, there are about a dozen different ways that a bot herder could monetize a botnet of this size. Off the top of our heads, in no particular order:
Spam relays (each bot could send 250 emails a day)
Digital currency mining (increasingly unlikely, though)
Tor-like anonymous proxies, which can be rented
Crypto ransom
Clickjacking
Ad fraud
Fake ad, SEO Injection
Fake AV fraud
Malware hosting
Reaper’s mission could be any one, or even several of those.
Since Reaper is also composed of many digital video devices, we could speculate this: What if both Persirai and Reaper are actually surveillance networks? Think of the intel you could gather with access to millions of video cameras. Nation-states with active intelligence programs would be drooling all over themselves to get access to that data. The US, China, Russia, and North Korea are all obvious suspects because who else but a nation-state could process or store all the input?
Is There a Lesson Yet?
We expect to see to see more thingbots arise as IoT becomes the attack infrastructure of the future. Just because Reaper is the latest, doesn't mean it will be the last. If Reaper doesn’t attack anyone or give away its intentions, it may enter the same mythical space occupied by the Conficker worm of the 1990s. At its peak, Conficker infected over 10 million Windows computers and caused great concern because it could have done an insane amount of damage. But it was never activated, and it remains a study in bot construction.
The obvious lesson is that the state of IoT security is still incredibly poor, and we need to do a better job of threat modeling the Internet of Things.
Get the latest application threat intelligence from F5 Labs.
About the Author
You May Also Like
Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024Safeguarding GitHub Data to Fuel Web Innovation
Nov 21, 2024The Unreasonable Effectiveness of Inside Out Attack Surface Management
Dec 4, 2024