Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

BrickerBot mod_plaintext Analysis

A week ago, the author of BrickerBot claimed that they retired and published their manifesto along with some source code of their bot.

In the manifesto, they wrote: "Take a look at the number of payloads, 0-days and techniques and let the reality sink in for a moment."

So I decided to take a look at the code and find those 0-days.

Breaking it down

The code "as is" can't be run, however we can see the payloads and techniques, so it is very likely those might be integrated into Mirai or other botnets. If there are indeed 0-days in the code, we could see a massive infection wave.

However, after analyzing the code, I was very disappointed to find only 1 "real" 0-day. Since it is Authenticated Remote Code Execution (RCE) vulnerability it shouldn't be that severe if you change default passwords.

The bot consists of 5 attack vectors:

  • SSH crawler that the author didn't publish, because, and I quote "My ssh crawler is too dangerous to publish"
  • Telnet crawler
  • HTTP module that use some Exploits as well as automated authenticated requests with default passwords
  • HNAP module that contains 1 exploit and Authenticated requests with default passwords
  • SOAP module that exploits 3 vulnerabilities

Detailed analysis of the code

The main purpose of the bot is to brick devices so they won't be usable. "Bricking" is the process of changing the code of the device such that the hardware can no longer be used, thereby turning the device essentially into a brick.

Why make a bot that simply wrecks devices? According to the author every unsecure device is a potential target to be hacked and integrated into a botnet. This project was meant to illustrate that point and remove these potential targets from the reach of IoT botnets such as Mirai. The author never seemed to care that the unfortunate side effect of this process is that the device is also rendered useless for its owner.

The author achieves this goal of bricking devices by gaining shell access or remote command execution using exploits. After gaining access commands are run that write garbage into the partitions of the hacked device and overwrite the file system, leaving the device without operating system, in "bricked" state.


Fig 1: Code snippet of the bot overwriting the file system

The code is very device-specific and each crawler scans for specific targets that the author knows are vulnerable. For each known vulnerable device, they wrote a specific command set to brick the device, as each device shell and file system is different. This targeted process is also meant to reduce "noise" and avoid attacking honeypots.

Attack Vector: Telnet

Although the ssh crawler code wasn't published, it is most likely very similar to the telnet crawler. The telnet crawler looks for specific telnet banners and tries to login with default credentials. The list of devices that the telnet crawler attacks include the following devices and manufactures:

Ingenic devices
3Com Access Points
Alcatel OmniSwitch
Aver DVR
Broadcom based products
BusyBox based products
CalAmp Fusion LTE
Cell-technology Janus
Dahua DVR
Dasan Networks
Digitel NetRouter
EV ZLX Two-way Speaker
Freescale Semiconductor
HiLinux cam
HooToo TripMate
HP Printers
Integrated Dell Remote Access
Intellisyn Intelliserver
Juniper Networks
KingType Modem/Router
KYlink SIP
Maxon Intelimax
Microhardcorp Bullet-LTE
NetScreen Technologies
Netween CCTV & cameras
Samsung Ubigate
Shanghai Telecoms E8
TrendChip Technologies
UTTGlobal ReOS
Windows CE Telnet Service
Xiongmai DVR

Attack Vector: HTTP

The HTTP module includes exploits & techniques that are described by the author in their previous manifest. If they are unable to brick the device, they will restore it to factory default settings, shut it down, or change some configuration option to force the device offline.

One method of gaining access to perform these attacks is to simply try default passwords. BrickerBot uses this technique against the following HTTP devices:

Observa Telecom Devices
Sifytechnologies Devices
Zyxel p66
Realtron Cameras
Supernet ADSL Modems
PLDThome DSL/Fiber Devices
Mediatek Devices
Grandstream Devices

Other HTTP devices are attacked with RCE exploits to gain access:

AVTECH Multiple Vulnerabilities
WIFICAM Multiple vulnerabilities
Dahua Backdoor
EnGenius RCE
CrossWeb DVR RCE
Hanbanggaoke IP Camera
WIFICAM cameras
D-Link DIR-600 / DIR-300 (Rev B) - Multiple Vulnerabilities
D-Link dsl-2750u ISP "backdoor" account
D-Link 850L Multiple Vulnerabilities
Unauthenticated command execution on Netgear DGN devices
NETGEAR R7000 / R6400 - 'cgi-bin' Command Injection
Vacron NVR Remote Command Execution
"JAWS" unbranded DVR
Ubiquiti AirOS 6.x - Arbitrary File Upload
Huawei B593 Authenticated RCE

The last one for Huawei routers is the only one you could consider a 0-day. Even though the vulnerability dates back to 2013, exploiting it on Huawei HG532 & HG532a model routers is a previously unknown attack vector. That said the attacker must be authenticated to exploit this vulnerability and, as we've already seen, authenticated access to the device is often all you need to brick it anyway.

Unfortunately, it is quite common in IoT devices to patch only a specific model against a known vulnerability while missing the exactly same vulnerability in other products. I myself stumbled upon this situation while finding a new vulnerability in NETGEAR routers.

Attack Vector: HNAP

The HNAP module uses an exploit for D-Link devices to achieve RCE.

It also tries to change network configuration to make the device unusable via authenticated requests with default passwords.

Attack Vector: SOAP

The SOAP module uses 3 exploits:

Eircom D-1000
Huawei CVE-2017-17215
Realtek CVE-2014-8361

Was this effective?

The author of BrickerBot claims they have bricked 10 million devices, but I believe this is an exaggeration.

Many of the devices they attacked can't be truly bricked and the author just restored them to default configuration, shut them down, rebooted them or changed configuration. This is more in line with a Denial of Service attack rather than a real "bricking".

Once the owners of those devices restore them to working order, the bot probably repeats the same attack on the same target. So while the bot may have successfully reached 10 million hits, many of those hits were likely duplicates and didn't really brick those devices.

Even if we take a look at Shodan we can see that BrickerBot managed to attack quite a few devices successfully, but the numbers are far lower.

You can find that the author left their manifest on few thousand devices:


And there are also quite a lot Ubiquiti devices successfully breached:


What we can learn from this?

Whether or not you support this bot's approach to raising awareness in regards to IoT security, the issue is real and there are takeaways here for both manufacturers and consumers of IoT devices.

If you are a manufacturer of devices that are connected to the Internet: don't use default passwords, don't leave "backdoor" accounts, and don't run everything under root. If you are not sure about the security of the products you offer for sale, you might want to open a bug bounty program. Many hardware manufacturers have discovered that the payouts for disclosure via these types of programs are lower than the cost of the implications if your devices are being compromised by a 0-day.

If you are an end user who has one of the devices that are on the BrickerBot list, make sure to install the latest firmware if there is an exploit for your device and make sure you didn't leave any default passwords intact.

Another good, basic security process is to disable remote administration unless you specifically need it. If you do require remote administration I recommend the following:

If you are a more advanced user, set it up so that you connect to your local network via a more secure channel first such as VPN or an SSH tunnel and then connect to your device.

If the above is still too advanced or too much work, you should at least use a strong password and keep the device patched and up to date, You may also look at changing the settings to run the service on a random port so it would be harder to find. It's not the greatest of solutions, but it helps.


Look for the following files in your device's filesystem:


Latest SpiderLabs Blogs

Secure Access Service Edge: Another Multi-Tool for the SOC

Over the years, several security defense architectures have merged into a single solution. Endpoint detection tools can perform sophisticated detections and correlations that used to require a...

Read More

Search & Spoof: Abuse of Windows Search to Redirect to Malware

Trustwave SpiderLabs has detected a sophisticated malware campaign that leverages the Windows search functionality embedded in HTML code to deploy malware. We found the threat actors utilizing a...

Read More

The Sentinel’s Watch: Building a Security Reporting Framework

Imagine being on shift as the guard of a fortress. Your job is to identify threats as they approach the perimeter. The more methods you have for detecting those threats, the better your chances of...

Read More