Thousands of IoT Devices Bricked By Silex Malware

A 14-year-old hacker bricked at least 4,000 Internet of Things devices with a new strain of malware called Silex this week. Threatpost talks to the researcher who discovered the malware.

A 14-year-old hacker used a new strain of malware this week to brick up to 4,000 insecure Internet of Things devices – before abruptly shutting down his command and control server.

The malware, dubbed Silex, was first discovered by Larry Cashdollar, senior security intelligence response engineer at Akamai, on his honeypot. The malware, like the BrickerBot malware in 2017, targeted insecure IoT devices and  rendered them unusable.

Specifically targeted were Internet of Things (IoT) devices running on the Linux or Unix operating systems,  which had known or guessable default passwords. The malware would trash the devices’ storage, remove their firewalls and network configuration, and finally fully halt them.

The hacker, who got in touch with Cashdollar via Twitter, was “trying to take down targets for other script kiddies who might be looking to build botnets and he was just getting sick of it,” said Cashdollar. “So his sole motivation was to remove the vulnerable IoT devices that botnets are built on to stop other script kiddies from building botnets and I guess aggravating him with it.”

Within the first few hours of discovery, the malware had bricked 2,000 devices. Cashdollar told Threatpost that the total number had reached as high as 4,000. Then, he said, the hacker abruptly took the command and control server offline.

“What ended up happening was the person who wrote this [malware] didn’t expect all this attention and didn’t like it and made him nervous so he decided to stop the malware from spreading and decided that he wasn’t going to change it anymore to make it more destructive than it already had been, he’s planning on quitting, I think,” Cashdollar said.

Still, the incident is yet another reminder of the slew of IoT devices that consumers are actively still using, he said: “Vendors are coming to terms with having to build secure devices that can be updated. I just don’t know how many of them have actually gotten on board versus ones that are ignoring it.”

Click here to download the podcast. For a lightly-edited transcript of the podcast see below.

Lindsey O’Donnell: Welcome to the Threatpost podcast. This is Lindsey O’Donnell with Threatpost and I am here today with Larry Cashdollar, the senior Security Intelligence Response engineer at Akamai. Larry, how’s your Thursday going?

Larry Cashdollar: It’s pretty good. I’m excited for some warm weather.

LO: Same here, hopefully some beach days coming up. Today we’re going to talk about a discovery that you made this week about malware that is targeting and bricking IoT devices. But first, just to start out, Larry, do you mind giving a quick introduction of yourself and what you do?

LC: I’ve been doing sysadmin slash security research vulnerability research since the late 90s. I usually do a lot of vulnerability, research and discovery, finding vulnerabilities and writing exploits. But I tend to turn my focus towards phishing campaigns or malware depending on what mood I’m in.

LO: Great. Let’s talk about this new malware called Silex that is targeting and wiping the firmware of IoT devices that you discovered earlier this week. So you spotted this earlier this week attacking devices, can you kind of give some color into how you first stumbled upon this?

LC: So I have a honeypot that I run off my home network since I work at home. And I found that home networks are typically targeted by malware a lot more than say, a virtual private server network is, I suspect that the malware authors know this and specifically highlight user end networks like Comcast or Spectrum you know, those internet service providers, right, so I run my honeypot off of my home Comcast network, and it gets a lot of attack traffic. And I usually check my traps every day, like a lobsterman, and see what I’ve caught overnight, and I’d actually shut down my honeypot in order to rework some of the power consumption in my lab in the basement, it tends to keep my basement at 72 degrees, which is kind of annoying in the summer months. So I, I reshuffled some devices around and then I shut off my lab and I turned it back on. And after a few hours, I noticed that my honeypot was being hit pretty hard. And I started examining some of the binaries that I saw, and noticed that one of them had a particular string, where the malware author was calling out other malware botnet-slash-script kitties, saying that he was sick and tired of them running these botnets and then he was just going to brick all of the devices that were out and vulnerable to default login credentials. So I’m paraphrasing his actual statement, but he pretty much left a message in there. So I thought that was pretty interesting and then looking at the destructive commands in the botnet source code I figured I will just simply tweet it out because I was pretty strapped for time. I’ve been working on other stuff for Akamai, some other research. Normally I write something up in our blog, and I didn’t have time for this, and then tweeted it out. And it got a lot of attention off Twitter. So it ended up making the rounds with the news pretty quickly.

LO: So it was targeting IoT devices with default passwords. So I feel like that’s such a prolific issue, that there must be a lot of open vulnerable devices out there, too.

LC: Yeah, it’s using Telnet, which is an older protocol and that predates the encrypted SSH protocol. And typically IoT devices, the ones that are vulnerable still have that Telnet protocol running. Yeah, it’s typically it’s targeting IoT devices that have known default login passwords and usernames and then literally doing as much destructive damage to the device as possible before the device is rendered unusable.

LO: So did you get a sense of what types of IoT devices were being targeted or was it mostly very vague to that degree?

LC: It was a broad spectrum attack where it was targeting any Linux or Unix-like operating system that had any of the known or guessable default passwords, you know password combinations like “root” and “admin” or “root password.” So at this time it was targeting was targeting your consumer-grade cameras, DVRs, routers, things like that, that have been known in the past to be deployed with known login credentials.

LO: So it’s targeting these IoT devices – from a technical standpoint, how does it then go about bricking the devices? Is that something you were able to get any insight into?

LC: Yeah, first it tries to write a data from /dev/random to all of the disk partitions it discovers. So it looks for any mounted partitions or existing partitions on the storage that it sees. And then it writes over those partitions with contents from /dev/random, which will just be a bunch of garbage. Then it tries to shrink the partition table sizes down to one cylinder … which would probably make the … partitions extremely small and likely, I think, corrupt the partition tables, then it goes ahead and it deletes the network interfaces, it deletes the default route. So it disables the network connectivity of the device. And then it actually, if there’s any IP tables or firewall rules, it deletes the firewall rules and adds firewall rules to reject any outbound traffic or any traffic being forwarded through the device, so it pretty much takes it off the network, even after it’s been rendered a lobotomy for writing over all data on the disk. And then as a final step … it goes ahead and tries to delete any remaining files off of the storage. I’m not exactly sure how far it gets through this because the first couple of things are pretty destructive. I’m not sure if it makes it actually to the removal part, but that that would be the most likely one to succeed first on most operating systems, since that command is pretty generic across Unix so it’s pretty destructive. Right?

LO: Yeah, it sounds like it trashes their storage, their firewall rules, as you said, and stops the device entirely for the victims of this attack. On the user end of things would that just mean that the devices just completely stop? And there’s no way to get them started again? Or what does that mean from the consumers who are actually using these devices?

LC: I think consumers would have to reflash their device, the firmware on it, which for most consumers, this would be a lot more tedious than they’re willing to do when it comes to a $30 Wireless IP camera, they’re more likely going to throw the camera out and buy another one and just assume it just stopped working. That would be the really the only way.

LO: Wow. And you had mentioned in earlier reports this week that the number was at – I think you said 2,000 devices that were wiped – due to the malware in the first few hours of discovery. I mean, has the attack continued, has that number gone up at all?

LC: The number I think peaked at 4,000 and the command and control server was taken offline. And it looks like that pretty much stops the malware, as far as I can tell in its tracks as it, it first tries to reach out to the command and control server. And if it can’t reach it, it just hangs. Because I actually ran the malware on one of my spare Raspberry Pi’s and it hung when it was trying to reach the command control server. What ended up happening was the person who wrote this didn’t expect all this attention and didn’t like it and made him nervous so he decided to stop the malware from spreading and decided that he wasn’t going to change it anymore to make it more destructive than it already had been, he’s planning on quitting, I think.

LO: And we’ve seen something similar to this before. Right, Larry? It’s almost like BrickerBot, which for listeners, was the malware that back in 2017 attempted to permanently destroy insecure IoT devices as well. Did you see any similarities or differences between those two strains of malware?

LC: Yeah, it was. The BrickerBot malware, I think was built as a Python script I thought. This was actually contained different architectures – or binaries of different architectures – But the intent and you know the commands were similar. So it was it was similar to BrickerBot but implemented in a different way.

LO: Right, yeah, I feel like kind of the motive behind both BrickerBot and this malware was clearly to say, look how insecure IoT devices are, we need to destroy them so that they won’t be, at least for BrickerBot so that these devices wouldn’t be infected with Mirai. It’s definitely an interesting motive for sure. And I’m sure there’s a mixed bag of opinions out there in terms of either empathizing with this effort versus thinking that this is just malicious and not the right way to do things.

LC: Right.

LO: I’m curious too I did see reports that pointed to a 14-year-old hacker who was behind this, is that something that you were able to get any insight into, or were those more, you know, third party reports?

LC: No he’s 14, he’s from Europe. I talked to him over Twitter, he reached out to me over Twitter over DM, and told me that he was planning on quitting because he didn’t expect this was going to be a big deal. And he got nervous and doesn’t want to get in any trouble. So he decided he was going to stop before things got worse, and then somebody had misattributed him to Iranian hackers, which really got him aggravated and scared, because he’s not Iranian and this had no motivation to do anything between Iran or the United States. It was just him trying to take down targets for other script kiddies who might be looking to build botnets and he was just getting sick of it. So his sole motivation was to remove the vulnerable IoT devices that botnets are built on to stop other script kiddies from building botnets and I guess aggravating him with it. The machine was hosted in Iran, the IP was, but we all know that IPs don’t mean attribution. Because you can easily proxy through IP addresses in any country you want and pretend to come from any country you want. So IPs don’t really mean anything. It’s just interesting to know you know where the IP was.

LO: Right.

LC: So, you know, his choice of servers.

LO: I’m curious, taking a step back and looking at the IoT market in general, you know, it’s obviously insecure. And there’s obviously big issues and stemming right down to that default password issue that is really at the heart of all this. I’m curious your thoughts on the IoT security market in general and whether you think that more malware such as Silex, such as BrickerBot will be seen in the future?

LC: Uh, I’m hoping not, I think the IoT manufacturers have made some strides to secure devices. I’m not 100 percent positive that they’ve completely cleaned up the security. But I know that some vendors have removed some vulnerable services on devices and I’ve actually made devices upgradeable where they push new firmware out. I actually have an IoT device in my lab that has been asking me to update its firmware for a year. But I don’t want to because I want to keep it vulnerable for other testing. So I know that you know, vendors are coming to terms with having to build secure devices that can be updated. I just don’t know how many of them have actually gotten on board versus ones that are ignoring it. So I guess the future will tell if there’s still new devices being deployed and rampant botnet activity, we’ll know that they haven’t, they haven’t come full circle on their security standards.

LO: Well, fingers crossed that there’s a little more awareness out there from the vendors and manufacturers part. And then from the actual consumers themselves, I mean, is there any kind of best practices out there as well? In my opinion, it should be more on the vendors’ shoulders, but do you think that the consumers can really do anything?

LC: Generally, you know, if you’re, if you’re buying a device, and you’re buying it off of some third party site, like what’s the big Chinese one, Alibaba is it? You’re sort of taking a risk when you’re putting that device on your network. In regards to security, it’s more likely you might get a better device from something that might be like a Ubiquitirouter would be a better choice than, say, a highway router from China. So  that’s my recommendation is to stick to known vendors like Ubiquitithat are known to try and take some pretty serious seriously and patch their devices that they deploy.

LO: Larry, thank you so much for coming on to the Threatpost podcast today and telling us a little bit about your discovery of Silex and the story there. Sure. And once again, this is Lindsey O’Donnell with Threatpost talking to Larry Cashdollar of Akamai about IoT security and the Silex malware. Catch us next week on the Threatpost podcast.

Click here to download the podcast.

Suggested articles