BrickerBot only attacks compromised devices
BrickerBot uses a network of globally distributed devices that are passively detecting exploit attempts from devices infected with IoT bots such as Mirai and Hajime. BrickerBot reacts to an exploit attempt by scanning the source of the exploit for a set number of ports, trying to secure the device (assumption based on Janit0r statements) and if not able to, ultimately attempting to brick the device using exactly 90 brick sequences over the telnet session.
As long as IoT devices stay clean from any of the known IoT bots, there is no reason to fear the BrickerBot. While Hajime might have the best of intentions and is trying to proactively protect IoT devices from known malicious bots, it inadvertently will trigger the wrath of BrickerBot.
First contact
Our first contact with BrickerBot was on March 20th. A total of 1,895 PDoS attempts rolled by in little over four days. Then BrickerBot was gone, and while we knew little about the origin of the attempts, Catalin Cimpanu was able to get in touch with the author, going by the name ‘Janit0r.’ It was not until April 10th that we got a new, more intense visit from BrickerBot on another honeypot. 1,293 PDoS attempts in less than 15 hours. Two different honeypots, not immediately correlated except for running the same honeypots.
In the meantime, the Janit0r made some statements that kept resonating in our minds. In his first interview with Catalin, the Janit0r said that ‘the Radware writeup made BrickerBot sound simplistic’ and that ‘if security researchers … hosted their honeypots on dirtier networks they would find even more interesting things going on…’ Soon after that first interview, Catalin got tipped by the Janit0r about an outage that affected Sierra Tel customers in the cities of Mariposa and Oakhurst, California. In that article, the Janit0r said ‘BrickerBot was active on the Sierra Tel network at the time their customers reported issues, but their modems had also just been mass-infected with malware.’ The Janit0r suggested the other culprit was Mirai.
It was not until last week, while correlating honeypot data with blocked infection attempts from dynamic analysis of Hajime in our IPS logs and looking for new patterns that we started to see some evidence of how BrickerBot might identify and target victims. There is no evidence of active scanning before the attacks, at least not from the same devices that were used during the attacks.
[You might also like: BrickerBot.3: The Janit0r is back, with a vengeance]
How to detect compromised devices?
From the BrickerBot data, it became apparent that a limited number of devices performed attacks, and most of them did exactly 90 of them and subsequently disappeared. The number 90 was even more apparent in the second BrickerBot wave. One big question remained: how does it detect infected devices? The answer was in front of us all the time, we just looked over it. Our honeypots are built to listen on known exploit ports, so what if BrickerBot did the same? What if it is passively detecting exploit attempts by botnets such as the Mirai variants and Hajime? Instead of actively scanning the internet for new victims, it could just be listening on port TCP/23 (telnet) and port TCP/7457 (TR069) for scans from infected IoT devices. This technique is more efficient and stealthier compared to actively scanning most of the internet from each device.
Dial 23 for BrickerBot
Using one of the more recently discovered BrickerBot source IP addresses, we performed a TCP connection test on port TCP/23. The connection got established and was immediately closed by the server. Within seconds, the honeypot deployed on the same internet connection started revealing BrickerBot sequences from the same BrickerBot source IP we just dialed. The same BrickerBot kept attacking until it reached exactly 90 attempts and then left.
Further testing of several BrickerBot infected devices from previous attack waves showed that more ports are open. Telnet to port 7547 and 19058 consistently triggered the BrickerBot attacks, which makes us believe that the bot is listening on most of the known ports used by IoT bot exploits.
Upon poking a BrickerBot, it comes back with 190 probes to 22 different ports, all of them corresponding to ports known to be exposed or used in exploits on IoT devices.
Slightly different brick sequence
A slightly different sequence was seen in most of the new BrickerBot brick attempts. This might have to do changes in our honeypot code or improved BrickerBot code by Janit0r.
Notice new commands ‘mtd_write erase mtdX’ and the omission of ‘&’ in the last erase command. Assuming this is not erratic behavior, as per Janit0r’s statement “The bot’s every action has a statistically determined purpose and what might’ve seemed like buggy behavior in the honeypot really isn’t.”
[You might also like: BrickerBot – The Dark Knight of IoT]
What we know
For now, we know that BrickerBots operate in a larger botnet and that they are silent until poked. The passive detection allows BrickerBots to operate independently of each other, without a need for command and control (C2) servers.
The attack sequences change between waves, indicating adaptive behavior and more effective brick sequences depending on the victims’ hardware, software and/or state. The ‘sysctl’ commands to disable TCP timestamps and reduce the max kernel threads are consistent and do provide a signature allowing identification and detection of the BrickerBot.
The BrickerBot botnet is globally distributed and we were able to identify 223 active nodes. Using Shodan.io and zoomeye.org queries, it appears that nearly all devices are running an older version of the Dropbear SSH server and most seem to have outdated firmware, some with hostnames ‘HACKED-ROUTER-HELP-SOS-DEFAULT-PASSWORD’ and ‘HACKED-ROUTER-HELP-SOS-WAS-MFWORM-INFECTED’ indicating the devices known to be vulnerable.
