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.

Figure: BrickerBot probed ports

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.

Figure: New commands in brick sequence

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.

Figure: Geographic distribution of BrickerBot – 1 dot = 1 bot, 223 bots in total
ert_2016-17_cover-2

Read the 2016–2017 Global Application & Network Security Report by Radware’s Emergency Response Team.

Download Now

Pascal Geenens

As the Director, Threat Intelligence for Radware, Pascal helps execute the company's thought leadership on today’s security threat landscape. Pascal brings over two decades of experience in many aspects of Information Technology and holds a degree in Civil Engineering from the Free University of Brussels. As part of the Radware Security Research team Pascal develops and maintains the IoT honeypots and actively researches IoT malware. Pascal discovered and reported on BrickerBot, did extensive research on Hajime and follows closely new developments of threats in the IoT space and the applications of AI in cyber security and hacking. Prior to Radware, Pascal was a consulting engineer for Juniper working with the largest EMEA cloud and service providers on their SDN/NFV and data center automation strategies. As an independent consultant, Pascal got skilled in several programming languages and designed industrial sensor networks, automated and developed PLC systems, and lead security infrastructure and software auditing projects. At the start of his career, he was a support engineer for IBM's Parallel System Support Program on AIX and a regular teacher and presenter at global IBM conferences on the topics of AIX kernel development and Perl scripting.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center