[00:00.000 --> 00:03.220]  I like it.
[00:05.180 --> 00:06.800]  You see my botnet back there?
[00:07.240 --> 00:09.980]  I got buddhists connected to my botnet.
[00:10.220 --> 00:11.400]  I got hella buddhists.
[00:11.400 --> 00:12.560]  Hella buddhists.
[00:12.620 --> 00:13.740]  Buddhists.
[00:13.840 --> 00:15.140]  Hella buddhists.
[00:15.140 --> 00:16.260]  Buddhists.
[00:16.340 --> 00:17.720]  Hella buddhists.
[00:17.820 --> 00:18.680]  Buddhists.
[00:18.680 --> 00:20.360]  I got buddhists connected to my botnet.
[00:20.360 --> 00:22.960]  Hanging out on hack forums, best believe I got warrants.
[00:22.960 --> 00:25.480]  Telling all who listened that my botnet's not boring.
[00:25.480 --> 00:28.220]  Modified Mariah and I'm mixing in the minor.
[00:28.220 --> 00:30.480]  There's no surprise getting wrecked by a minor.
[00:30.480 --> 00:33.020]  Cover up his drop there, looking for me everywhere.
[00:33.020 --> 00:35.520]  No I'm really not there, places I will not share.
[00:35.520 --> 00:38.100]  Drop a couple backups, I know you won't find me.
[00:38.100 --> 00:40.500]  Buy a couple more smart balls, won't you kindly?
[00:40.500 --> 00:43.060]  Screening Captain Phillips, who the hell are you?
[00:43.060 --> 00:45.580]  Wonder why your toaster's connected to RU.
[00:45.580 --> 00:47.960]  Why your toaster's toasting, I'm using it for roasting.
[00:47.960 --> 00:50.680]  Some kid got busy boasting, now his modem's smoking.
[00:50.680 --> 00:53.180]  Keep the crypto flowing, I need my money now.
[00:53.180 --> 00:55.600]  But I gotta go, cause my mom said study now.
[00:55.600 --> 00:58.040]  I'm calling all the shots, and it's time for me to score.
[00:58.040 --> 01:00.800]  I got a couple spots, hit me up on Discord.
[01:00.980 --> 01:03.180]  Botnet, I got hella booters.
[01:03.600 --> 01:05.700]  Botnet, take over your rooters.
[01:06.160 --> 01:08.400]  Botnet, in your internet of things.
[01:08.640 --> 01:10.840]  Botnet, man this shit hella stings.
[01:11.060 --> 01:13.480]  Botnet, I got hella booters.
[01:13.640 --> 01:15.980]  Botnet, take over your rooters.
[01:16.160 --> 01:18.540]  Botnet, in your internet of things.
[01:18.720 --> 01:21.040]  Botnet, man this shit hella stings.
[01:21.200 --> 01:23.620]  Botnet, I got hella booters.
[01:23.800 --> 01:26.100]  Botnet, take over your rooters.
[01:28.440 --> 01:43.600]  Well, that was amazing. Well, thanks so much, Dave, for that amazing intro. I was not really
[01:43.600 --> 01:50.960]  sure what to think when I just got a PM saying that there was a theme song for my talk. So
[01:50.960 --> 01:56.680]  hi, everybody. Thanks for coming and hanging out. Let me... hold on. Making sure everybody can hear
[01:56.680 --> 02:02.440]  me, right? I'll chat. You can hear me? Say hi if you can. Just making sure. I've got a terrible
[02:02.440 --> 02:10.200]  microphone. All right. Cool, cool. Okay. So let's get going. So, yeah, this is my talk. I'll just
[02:10.200 --> 02:16.760]  get right into it. So who am I? I'm Ned Spooky, senior reverse engineer at Redacted Company.
[02:16.760 --> 02:23.000]  I primarily work on embedded devices, firmware, industrial control systems, and taking apart
[02:23.000 --> 02:28.880]  proprietary network protocols. You know me online as either Ned Spooky or you.
[02:29.300 --> 02:36.800]  And I contribute OSS tooling and other errata for 3rd Intel, RE, and offensive security.
[02:37.320 --> 02:43.560]  So, all right, we'll do a little background on this. So why do this talk? So I know that there's
[02:43.640 --> 02:49.920]  a lot of people that, you know, have seen IoT botnets, whether it be how you've been affected
[02:49.920 --> 02:55.300]  by it or see people talking about them online. And, you know, I had done a bit of my own research
[02:55.300 --> 03:01.680]  and I really kind of wanted to add, you know, a bit of perspective from my end on this. Because
[03:01.680 --> 03:07.500]  IoT botnets are definitely still incredibly prevalent. You know, we are all affected by
[03:07.500 --> 03:13.280]  them, whether we like it or not. You know, if your work slack is suddenly down because of somebody's
[03:13.280 --> 03:19.800]  fight on Xbox Live or Minecraft, you know, this is affecting you in some way. But I don't think a
[03:19.800 --> 03:23.320]  lot of people take them as seriously. A lot of people think it's like, you know, kiddy stuff,
[03:23.320 --> 03:29.200]  like script kiddy stuff, which is unfortunate because it definitely is something that is,
[03:29.200 --> 03:35.480]  you know, an issue that we all have to deal with. And so, I spent a good amount of time
[03:35.480 --> 03:42.120]  collecting malware sources. So I started doing this in about 2018. And I had been collecting
[03:42.120 --> 03:49.140]  and developing tools to analyze source code and analyze binaries, which I'll get into later.
[03:49.140 --> 03:52.420]  I studied a lot of the commonly exploited vulnerabilities and wanted to know more
[03:52.420 --> 03:57.780]  about, like, why they were so prevalent. Like, why can you have 4 million hacked routers
[03:57.780 --> 04:05.120]  on your botnet? You know, it's insane to me. So I wanted to inform others about the impact of
[04:05.120 --> 04:10.960]  their technology choices, specifically firmware devs and people who are also end consumers.
[04:10.960 --> 04:16.380]  And I also wanted to propose some ideas on how to address these. And so, I also, this talk,
[04:16.380 --> 04:22.600]  I should have given it about a year ago or so. It's just kind of been pushed under the back
[04:22.600 --> 04:27.080]  burner a bit. But I tried to update it as much as I could. And I also had to kind of cut out
[04:27.080 --> 04:31.860]  some of the parts, which I'll talk about as I go through the talk. So here's the outline real
[04:31.860 --> 04:36.120]  quick. So we're going to go over IoT botnet history. We're going to go over the actual
[04:36.120 --> 04:40.580]  botnet scene a little bit. Talk about the architecture of botnets and how they spread
[04:40.580 --> 04:44.920]  and propagate. And then we're going to talk about the firmware vulnerabilities that enable them
[04:44.920 --> 04:51.020]  and steps to move forward for vendors. So starting off just with IoT botnet history. So
[04:51.020 --> 04:57.780]  what is an IoT botnet? So if you're here watching for IoT Village, you probably are aware of IoT
[04:57.780 --> 05:03.640]  issues and botnets in general. But for those who haven't seen anything about them, they're
[05:03.640 --> 05:08.340]  basically a network of hacked IoT devices that are basically internet connected devices like routers,
[05:08.340 --> 05:14.920]  laptop boxes, webcams, your toaster. This little toaster on here has a little script on how to
[05:14.920 --> 05:21.100]  scrape Shodan for Linksys routers. But so they're used primarily for DDoS and they're sometimes
[05:21.100 --> 05:27.220]  used for crypto mining and also tunneling and proxying traffic. And so for this thing, I'm going
[05:27.220 --> 05:31.200]  to... this talk is kind of more of a cultural as it is technical and I kind of want to be able to
[05:32.320 --> 05:36.840]  kind of go through a lot of the confusing nomenclature that surrounds this because
[05:36.840 --> 05:42.020]  there's a ton of it. People call botnets by a million different names, whether you're talking
[05:42.020 --> 05:47.700]  to a researcher or talking to a person who develops them. There are a ton of different types. So let's
[05:47.700 --> 05:52.080]  kind of go through a little bit of the history here. So IoT botnets as they're known right now
[05:52.080 --> 05:59.140]  can be traced back to, I guess, 2014-ish when LizardSquad came out with the, I guess, the
[05:59.140 --> 06:04.920]  botnet, the malware with the most names available, like any malware. It's been termed a bashlight.
[06:04.920 --> 06:11.240]  It can also be called LulzBot, Torless, Lizkabob, LizardStressor, Ballpit, Gaffigat, and just a
[06:11.240 --> 06:16.000]  bajillion other names. And so it was spread by exploiting Shellshock vulnerabilities when
[06:16.000 --> 06:21.020]  Shellshock came out in BusyBox on a bunch of different devices. So there was... people were,
[06:21.020 --> 06:24.760]  you know, scanning the entire internet for Shellshock vulnerabilities because they were
[06:24.760 --> 06:31.360]  all over the place, but they were very, very common in a lot of IoT devices. And so when this
[06:31.360 --> 06:34.500]  was actually happening, though, there were actually a lot of different botnets or bots that were being
[06:34.500 --> 06:40.320]  distributed because there hadn't been as many sources as there are now. So you've heard of
[06:40.320 --> 06:46.420]  KITAN, which is like an IRC C2-based botnet that was spread a lot, as well as like just Perl bots
[06:46.420 --> 06:51.660]  that are just literally DDoS bots that are written in Perl. So the source code for this, though,
[06:51.660 --> 06:57.660]  was leaked in 2015, and a lot of people started to work on it. And so collectively, it's hard to
[06:57.660 --> 07:02.740]  choose one name for them, but collectively I would say that these would be categorized as QBot,
[07:03.520 --> 07:09.700]  which is unrelated, again, to the KAKBot malware, which people call QBot. And so,
[07:09.700 --> 07:14.400]  yeah, new devices that are still vulnerable to this exact same vulnerability appear online
[07:14.400 --> 07:22.160]  like newly to this day. And so fast forward a couple years, so MIRA came out in 2016,
[07:22.160 --> 07:29.000]  and so it was used in some famous DDoS attacks like the Dyne DDoS attacks, the ones on Brian
[07:29.000 --> 07:34.020]  Krebs and some other people. But it was leaked shortly after some of the bigger DDoS attacks
[07:34.020 --> 07:39.860]  happened, and people started to immediately use it because it was a lot more streamlined than the
[07:39.860 --> 07:48.060]  previous versions of DDoS malware. A lot of the stuff was in, you know, really simple one-file
[07:48.060 --> 07:55.140]  bots and servers, very, very basic stuff over telnet. So MIRA was a lot more streamlined.
[07:55.140 --> 07:59.460]  It was very modular, so there's different files. It made it easier for you to plug in new exploits
[07:59.460 --> 08:06.360]  into, and also made it easier for you to have access control for users that were coming on.
[08:06.680 --> 08:12.020]  And so it also had a bit better code. It was definitely still not the best, but it's a lot
[08:12.020 --> 08:19.800]  better than the previous code for LulzBot. It also had a SQL server on there, which made
[08:19.800 --> 08:24.820]  it running the server a lot easier for them. And so it seems like everybody has a botnet
[08:25.380 --> 08:31.280]  fork these days, since then. So there's other IoT botnets that are pretty major that have come out.
[08:31.480 --> 08:36.980]  A big one that you may have heard of was Satori or FBot or Okiru, and it's a pretty well-known
[08:36.980 --> 08:40.820]  MIRA fork that's a bit different from some of the other ones because a lot of them are kind of just
[08:40.820 --> 08:48.760]  very copy-pasted stack overflow questions fit into some Golang and C code. But so this one here
[08:48.760 --> 08:52.860]  had a bit... the person who was doing it definitely knew what they were doing a bit more than most
[08:52.860 --> 08:59.100]  people, and that person actually just went to jail recently. We've also seen BrickerBot, which is the
[09:00.300 --> 09:05.720]  botnet that would just basically infect and break IoT devices, and there's been a few iterations of
[09:05.720 --> 09:10.540]  it. There was one in 2017, and then there was one recently, I think it was like a 13-year-old
[09:10.540 --> 09:15.640]  kid or something like that that did it as well. A newer one, really interesting, is Kaiji, which is
[09:15.820 --> 09:21.360]  a Golang-based cross-compiled SSH brute-forcer, and it actually installs a root kit or tries to
[09:21.360 --> 09:25.760]  to establish persistence, which is really interesting. I'll get into that more later.
[09:26.360 --> 09:29.540]  AxisR is another one that I've seen. I just threw in there because I didn't hear anybody talking
[09:29.540 --> 09:35.520]  about that one, but it's more modular, still crappy. Then you have various Bitcoin miner
[09:35.520 --> 09:40.000]  botnets that you may have seen. It's harder to do Bitcoin mining on an IoT device because they
[09:40.000 --> 09:45.560]  don't have as much CPU power and no GPU, but they're still out there. And then I also did a
[09:45.560 --> 09:51.860]  write-up on some Mirai variants that are targeting FPGAs and some really exotic architectures,
[09:51.860 --> 09:57.600]  which I have a link in citations at the end here, or you can go on my website and see it.
[09:58.200 --> 10:03.320]  So yeah, botnet activity growth, I mean, like similarly to Qbot, Mirai just started popping
[10:03.320 --> 10:08.700]  up all over the place once it was leaked, and there became basically a huge marketplace for
[10:08.700 --> 10:13.620]  people who are trying to sell spots on the botnet, right? There's reseller markets, affiliate
[10:13.620 --> 10:19.600]  programs, and incentives for having it grow. And also booting itself, you know, DDoSing somebody,
[10:19.600 --> 10:26.600]  their home router, became a really common thing for people to actually, you know, try and do
[10:26.600 --> 10:30.800]  because it's just like a way to knock people offline, especially if you're mad at them
[10:30.800 --> 10:35.960]  in Call of Duty or something. And so yeah, it's basically just like the thing that people
[10:35.960 --> 10:41.060]  start to do. And so like, you know, though, as these things develop and grow, like a thousand monkeys
[10:41.060 --> 10:45.180]  at a thousand terminals will eventually take out the intranet, and that's kind of what's been
[10:45.180 --> 10:52.640]  happening. And so we'll get a little bit into the scene here. So the botnet scene at a glance,
[10:53.060 --> 10:58.300]  there's entire communities that are dedicated specifically to just one botnet
[10:58.300 --> 11:04.780]  or one botnet group, and they are usually talking on Discord, sometimes they're on forums or IRC.
[11:05.120 --> 11:09.800]  There used to be definitely more IRC back in the day where people would have C2s connected to IRC,
[11:09.800 --> 11:15.220]  but nowadays it's more Discord that people are talking. Advertising is done on literally
[11:15.220 --> 11:20.800]  every single social media platform you can think of. I think somebody found Pinterest that had
[11:20.800 --> 11:26.280]  somebody advertising botnets, but yeah, if you go on Instagram and just literally search botnet
[11:26.280 --> 11:31.520]  or Qbot or botnet setup or YouTube, you will find somebody advertising their latest
[11:32.000 --> 11:40.120]  slamming botnet. And so bootertime is generally sold people for DDoS or through a web panel
[11:40.780 --> 11:45.000]  or through a telnet interface, but that's like the main thing people are trying to do is just
[11:45.000 --> 11:50.060]  sell time on the botnet. And so you'll see here on the bottom, it might be a little small for
[11:50.060 --> 11:56.920]  some of you, but there's just some advertisements for different botnets and also some videos on
[11:56.920 --> 12:03.320]  how to boot people offline and how to do it using just an Android and best booters 2020. These all
[12:03.320 --> 12:08.900]  have hundreds of thousands of views too, so these are people that are really going hard with the
[12:08.900 --> 12:14.680]  advertising. So the sources, so I talked about the sources that have kind of been modified by people.
[12:14.880 --> 12:21.660]  They're usually distributed as Zips or RARs or whatever and they are sold for about $500 to $300
[12:22.220 --> 12:28.200]  USD from just what I've seen. So the authors will typically change very little of the code base,
[12:28.200 --> 12:33.580]  usually just involves something simple, just changing the ASCII art or changing the variable
[12:33.580 --> 12:39.800]  names, something like ctrl f and replace. Sometimes they might even add a new exploit,
[12:39.800 --> 12:46.080]  which is always interesting, but exploits themselves to load bots are sometimes sold,
[12:46.080 --> 12:50.220]  but a lot of them are literally like you can google any part of the script and you will find
[12:50.220 --> 12:58.020]  the exploit db link of where they took it from. The ones that are sold though from exploit db or
[12:58.020 --> 13:03.700]  metasploit modules are usually backdoored and it's really funny they just have like a base64 blob
[13:03.700 --> 13:10.560]  that just like runs like import os and then just run this or import sys and run this or whatever.
[13:10.880 --> 13:15.780]  And so when I was going through and finding a lot of these sources though, I would find that
[13:15.780 --> 13:21.020]  when people would scam each other or rip off somebody or somebody had a fight with them,
[13:21.020 --> 13:24.920]  they would leak each other's source code, which is great for threat intel people and
[13:24.920 --> 13:30.140]  reverse engineers who want to figure out what's going on because they would just be like, oh hey,
[13:30.140 --> 13:34.940]  here's this person, here's everything they've done, here's their botnet and here's their code
[13:34.940 --> 13:41.320]  and you can just kind of scoop it up and take a look at it. And so selling spots, primary source
[13:41.320 --> 13:48.000]  revenue, as I said, they're typically sold in weekly, monthly, or lifetime plans. You can see a
[13:48.000 --> 13:53.740]  breakdown of plans over here. Pretty cheap too. The lifetime is always really funny to me because
[13:53.740 --> 13:58.700]  it really just means for the duration of the bot's lifetime, botnet's lifetime, and sometimes that
[13:58.700 --> 14:05.880]  does not last longer than the three days or a month depending on how bad their operation is.
[14:06.560 --> 14:11.480]  Some more enterprising people, people who are a bit more advanced might use a web stressor and
[14:11.480 --> 14:17.820]  they can sell access to that with users and everything for a web browser. There's been a few
[14:17.820 --> 14:23.360]  big web stressors that have been taken down and some that are still up. Web stressor source leaked
[14:23.360 --> 14:27.800]  volumes in the web stressor. There's so much surrounding that it adds a bit of abstraction
[14:27.800 --> 14:33.840]  to it that makes it harder to manage. And then yeah, finally, some people act as resellers and
[14:33.840 --> 14:42.740]  they get a cut of the sales over time. So who runs a botnet, right? IoT botnet operators,
[14:43.100 --> 14:51.020]  based on what I've seen in the scene, I guess, they're usually pretty young, high school age,
[14:51.020 --> 14:55.540]  sometimes college age. They're somewhat experienced with computers, but they're usually not
[14:56.320 --> 15:02.960]  developers. They learn a lot through YouTube and through text files, which I have a collection of
[15:02.960 --> 15:08.920]  in the GitHub that I'll explain in a little bit, which are just tutorials on how to set them up.
[15:08.940 --> 15:17.380]  Basically, how to spin up a rel box and how to actually... hold on one second... how to actually
[15:18.080 --> 15:24.240]  just do the basic things that compile with GCC. A lot of the times, though, they really have no
[15:24.240 --> 15:29.180]  clue what they're doing. So you'll see people who are trying to get support for different botnets
[15:29.180 --> 15:37.840]  and they're really confused about GCC or what access control is. But more sophisticated people
[15:37.840 --> 15:43.640]  might have a web stressor or an API, like I said before. People will use cryptocurrency instead of
[15:43.640 --> 15:47.960]  PayPal, which is very common for some reason, even though it's tied to your bank directly.
[15:48.240 --> 15:52.580]  In some cases, though, people will also use botnets for additional purposes like
[15:52.580 --> 15:57.040]  proxying traffic. So sometimes you'll see fly-by-night VPN operations that
[15:57.040 --> 16:03.280]  might be doing something shady like, you know, routing their traffic through routers and that's
[16:03.280 --> 16:12.300]  just their VPN somehow. So why run an IoT botnet? So, I mean, just as much as most malware is,
[16:12.300 --> 16:15.860]  there's a lot of similar reasons, but there's a lot of stuff that comes with the fact that
[16:15.860 --> 16:20.640]  there's a lot of younger kids involved in this. So they usually do it for either money,
[16:20.640 --> 16:26.040]  you know, because people can earn money from the sale of botnet spots. A lot of
[16:26.040 --> 16:30.980]  people do this for attention. People, you know, seek attention for stuff, even if it's not even
[16:31.140 --> 16:36.200]  a DDoS, and it's just like a regular production outage. Some people might say, oh, yeah,
[16:37.980 --> 16:44.700]  my group, we DDoS these people, and, you know, we're gonna extort them for money. And then you
[16:44.700 --> 16:48.380]  look at their status pages like, oh, yeah, sorry, we had a blip in, you know, updating this thing,
[16:48.380 --> 16:54.480]  and we're back now, which is always awesome. Supply and demand. It's definitely people who
[16:54.480 --> 17:00.540]  want, you know, to DDoS each other. And so that's, you know, definitely wanting to meet that demand
[17:00.540 --> 17:06.220]  is something that, you know, it's good for any young entrepreneur. Revenge is also big. I see
[17:06.320 --> 17:10.800]  a lot of people claiming that somebody, you know, docks them or DDoS them, and they want to get back
[17:10.800 --> 17:16.300]  at them by getting their IP and booting them offline. And then people are also inspired a lot
[17:16.300 --> 17:21.420]  by past attacks, because people have seen what actually happens if somebody DDoS and takes out,
[17:21.420 --> 17:27.260]  you know, the internet. They want to be, you know, doing that. And also, it's incredibly easy
[17:27.260 --> 17:33.940]  to set up an IoT botnet. So let's take a little bit of time to go over the architecture of
[17:33.940 --> 17:41.260]  DDoS botnets. So as I said before, earlier botnets use standalone bot files and C2 files
[17:41.260 --> 17:47.920]  that were just compiled with GCC or UCLibc for cross-compiling. They're very, very simple
[17:48.620 --> 17:56.520]  to set up and deploy. Some of them for C2 itself, they used like IRC for command and control,
[17:56.520 --> 18:03.160]  and they'd have IRC, like very bare bones IRC clients connected to their... or within their
[18:03.160 --> 18:10.740]  bots. But Mirai modernized it, and they have actually a C2 protocol that is used, and they
[18:10.740 --> 18:18.840]  have like a SQL backend for tracking bots and all that. So web stressors will use PHP and some
[18:18.840 --> 18:25.320]  other, I guess, API stuff for managing the bots. But it's definitely evolved a lot more than it
[18:25.320 --> 18:31.980]  used to be like five years ago, which is interesting to see. So the life cycle of a botnet
[18:31.980 --> 18:39.460]  is usually very, very short. You don't see them for very long, not going to be over a month or two.
[18:40.020 --> 18:45.820]  Basically, somebody will set up a C2 on like a lax VPS host, they'll scan for their own devices,
[18:45.820 --> 18:51.620]  they'll get some bots to their botnet, they'll advertise their spots, and then use it. And then
[18:51.620 --> 18:57.000]  the takedown goes one of two ways. Either somebody, like say bad package report, will tweet out
[18:57.000 --> 19:07.540]  their botnet to the web host, and somebody will notice it and get it taken down.
[19:07.540 --> 19:12.300]  Or somebody else's botnet will start kicking their bots from the system, and they won't be
[19:12.300 --> 19:16.700]  able to keep up and they'll lose power. But then it'll just keep happening again. This is just the
[19:16.700 --> 19:28.880]  same thing you see over and over again. Hold on one moment. Okay, that's cool. I didn't think it
[19:28.880 --> 19:36.580]  was the water. So this inevitably leads to a king of the hill game for botnets. They're very
[19:36.580 --> 19:40.880]  territorial. People are, you know, targeting one specific type of device with one specific
[19:40.880 --> 19:45.060]  vulnerability that they've coded into their variants. And then when somebody else gets the
[19:45.060 --> 19:51.100]  same idea, you know, they'll start hacking and doing things like that, getting their bots on
[19:51.100 --> 19:56.200]  there. Anybody who touches the devices usually already has root access, but they might have
[19:56.200 --> 20:01.500]  either like some weird file system, or there's no way to really reconfigure it, or they might not
[20:01.500 --> 20:06.360]  know how to reconfigure the device to kick everybody else out. But basically, every bot
[20:06.360 --> 20:11.340]  will only last as long as it can before somebody else takes its place. And also, there's really no
[20:11.340 --> 20:17.100]  repercussions for this. So everyone's just kind of slamming on different IoT devices,
[20:17.100 --> 20:22.300]  and pictured as an IoT operator, or botnet operator watching their bot count drop.
[20:23.640 --> 20:29.360]  So evasion is definitely an interesting aspect of this. So there's a lot of very simplistic
[20:30.260 --> 20:36.760]  evasion that you'll see here. This one up at the top here is somebody just renaming their process
[20:36.760 --> 20:43.300]  to DropBear, which is, I guess it works, but it's also used by everybody. So then everybody will
[20:43.300 --> 20:49.280]  just kill the DropBear process once they log on. But that's realistically, this is not to hide
[20:49.280 --> 20:54.680]  from, you know, any sort of firewall or any sort of AV or anything. It's only really used to evade
[20:54.680 --> 20:59.520]  other botnet operators. And so they'll do things like, you know, the process masking, they might
[20:59.520 --> 21:04.620]  learn about a different area of the file system that they can put a bot in, they might hide a
[21:04.620 --> 21:09.960]  backup bot and have like, potentially something like a cron job. It's always very, very primitive,
[21:09.960 --> 21:16.160]  and like, very, very bespoke. And I actually had a whole code review section that could have
[21:16.160 --> 21:21.020]  actually been an entire talk, but I had to cut it for time here. But there's a lot of very,
[21:21.960 --> 21:28.020]  very strange ways that people try to do evasion, which I would love to talk about at another date.
[21:28.920 --> 21:36.060]  And so bot killing, as I said before, people will do this, you'll take a look at this, if you can
[21:36.060 --> 21:41.060]  see it on the side here, here's a, you know, an array that's just full of a ton of different bot
[21:41.060 --> 21:45.620]  names. And every time they updated this botnet, which I have multiple versions of it, they would
[21:45.620 --> 21:52.140]  add more and more of these, but you'll see they'll do things like iterate from one to however many,
[21:52.140 --> 22:00.080]  try to kill every process that's called that, or every single version of this specific JackBind
[22:00.080 --> 22:04.800]  MIPS or whatever, TwoFace. So people will like, be aware of different botnets that are operating
[22:04.800 --> 22:08.880]  and what they name them, and then put them into their scripts. And it's like a cat and mouse game,
[22:08.880 --> 22:11.600]  because nobody can fit everything in there, otherwise their binaries are going to be full
[22:11.600 --> 22:16.940]  of strings that ultimately are going to get detected by people who are reverse engineering
[22:16.940 --> 22:27.020]  the malware. And so, not some, not most, nearly all bots and C2s, I would say all, have really,
[22:27.020 --> 22:32.340]  really silly vulnerabilities that make them incredibly easy to knock offline. And I don't
[22:32.340 --> 22:37.180]  really see too many of these techniques really utilized or advertised by people, but in my next
[22:37.180 --> 22:44.180]  slide, I'll show you something interesting, I guess. So here's my non-live demo for a C2 killer.
[22:44.180 --> 22:49.320]  So this is something that I found. I definitely was not the first person to find this, but it was
[22:49.320 --> 22:54.480]  part of my testing when I was testing out these different things when I was researching. It's
[22:54.480 --> 23:01.320]  incredibly easy to kill, you know, Mirai C2s. This is a, you know, take your screenshots or whatever.
[23:01.320 --> 23:06.260]  I already put this out on Twitter at some point. But yeah, this is, if you send this to either the
[23:06.260 --> 23:14.700]  admin port or to the heartbeat protocol port, it just, it just segfaults the Mirai C2. And I've
[23:14.700 --> 23:19.100]  never seen anybody fix this. This isn't every version of Mirai that I've seen. Some people
[23:19.100 --> 23:23.960]  had claimed that it was fixed, but I've still, after reviewing every single one of them that I
[23:23.960 --> 23:30.280]  could find, I've never seen that. And so, take a bit of a second, the last little bit on the
[23:30.280 --> 23:35.500]  botnet scene here. You know, when I was going through and doing this work, I ended up creating
[23:35.640 --> 23:40.840]  a tool to help me track all this stuff. And I put it out on GitHub. It hasn't been updated for a bit
[23:40.840 --> 23:48.400]  because it just, I've gotten too many other projects to do. But it's, it's a static analysis
[23:48.400 --> 23:55.220]  and classification tool for zip files and binaries and things like that. It just feeds it on to a big
[23:55.220 --> 23:59.720]  Elasticsearch database. I definitely, I'm taking the next week off of work. So I'm going to take
[23:59.720 --> 24:04.420]  some time to push my big update to this. But if you want to check it out, definitely do it. I have
[24:04.420 --> 24:10.180]  some new things in API, different symbol hashes and key extraction techniques in there. But it's
[24:10.180 --> 24:15.800]  just mainly for me for fast analysis because I was, you know, I had, it's basically feeding in
[24:15.800 --> 24:23.060]  either new source code or new bot binaries into this and just tracking them. But it works for
[24:23.060 --> 24:29.460]  other malware too. Also, if you want to, I have a Twitter that was deleted by Twitter for some
[24:29.460 --> 24:34.740]  reason, that was called Threatland, but that was the name of the project that I used to track
[24:34.740 --> 24:42.580]  all these sources. So I have like every Mirai and Qbot and other botnet, just even beyond IoT.
[24:42.840 --> 24:48.380]  I tracked them all in a big repo called TLBots and have a few other repos if you want to check
[24:48.380 --> 24:52.700]  them out for like fraud tools and stuff. But yeah, there's literally, clone that,
[24:52.700 --> 24:57.540]  there's like a gigabyte worth of zip files of every malware source code that I could find.
[24:59.460 --> 25:02.940]  Yeah, so now we're going to get into talking about vulnerabilities. And this is kind of,
[25:02.940 --> 25:08.860]  this aspect of it is a bit more about like stuff for devs, because I wanted to be able to
[25:08.860 --> 25:14.560]  give info for developers who are working on IoT devices to take all of what I just said there
[25:14.560 --> 25:20.380]  and put it into context for their actual security architecture. So let me take another sip of water.
[25:28.500 --> 25:34.380]  So okay, so we're here, we're peering into the void here. So here is, if you ever have gone on
[25:34.380 --> 25:41.000]  Green Noise, they have a lot of tags for different either vulnerabilities themselves of the people
[25:41.000 --> 25:48.020]  are scanning for, or just classes of, you know, malicious traffic. If you do a search just for
[25:48.020 --> 25:54.460]  Mirai, you'll see here, it's very, very tiny, but there's four and a half million results for
[25:54.460 --> 25:59.800]  unique devices that have been scanning with Mirai-like traffic. So that gives you a rough
[25:59.800 --> 26:04.520]  example of how many people are, or how many devices are actually infected and actively
[26:04.520 --> 26:10.640]  scanning. And then the other one is a showdown search for this hacked router help SOS had do
[26:10.640 --> 26:17.160]  password thing, which there are still, this is, I think that that hack happened like four years ago,
[26:17.160 --> 26:23.760]  and there's still 6,500 devices that have been hacked and have this hostname. So it's always
[26:23.760 --> 26:28.820]  heartwarming to see, I guess. So what types of vulns are exploited by these botnets? So
[26:28.820 --> 26:34.540]  it's always very basic stuff here. We're talking about weak auth and auth bypass. So there's either
[26:34.540 --> 26:41.880]  admin admin as the credentials, or there's like a page that you can, you know, run OS commands on
[26:41.880 --> 26:47.500]  that doesn't actually need a password to be, you know, interacted with. There's also command
[26:47.500 --> 26:54.620]  injection like shell shock and other really silly command injection stuff. There's also a lot of
[26:54.620 --> 27:00.640]  common exploits and specific services and libraries like the Realtek UPnP SDK, which had a
[27:00.640 --> 27:08.100]  vuln that was like in everything. There's so many different devices. GoAhead webs and ThinkPHP
[27:08.100 --> 27:13.160]  also have vulns that were in a lot of places, thousands and thousands of stuff were affected
[27:13.160 --> 27:19.940]  by GoAhead. And so more rare though, you'll see actual shellcode and binary exploits,
[27:19.940 --> 27:23.300]  which is always interesting to see because, you know, you'll have devices that, you know,
[27:23.300 --> 27:30.440]  are using like the same base address and they can just do a shellcode exploit very, very easily.
[27:30.740 --> 27:36.900]  But if they're not as common as, as you'd think, and I think it might be because people don't know
[27:36.900 --> 27:42.920]  how to code a shellcode or how to inject shellcode, like with an NC, like when they're writing their
[27:42.920 --> 27:48.060]  bots. So who knows, but you'll see them in bot loaders for sure. A lot of other vectors include
[27:48.060 --> 27:53.460]  previously compromised devices. So like if you, people sell lists of compromised devices
[27:54.100 --> 28:00.000]  for a specific category of devices, which there might, I don't actually know if there's any in my
[28:00.000 --> 28:05.720]  repo, but I have seen a bunch of them where people are basically just passing those things around.
[28:06.100 --> 28:10.140]  So we're looking at the most targeted devices here. So if you want to see, you know, what vulns
[28:10.140 --> 28:15.900]  are most leveraged by these botnets, I have a command table or a table here of, basically,
[28:15.900 --> 28:21.820]  I went through every source code that we could find. There's like several hundred unique source
[28:21.820 --> 28:28.480]  codes. And these are the main ones that people are using. A lot of them here don't actually
[28:28.480 --> 28:33.340]  have any like CVE or CPE or any vendor acknowledgement. So you can only really find
[28:33.340 --> 28:39.020]  them by kind of looking up what the traffic is or what the command injection attempt was on,
[28:39.020 --> 28:44.440]  you know, in your log files. Actually, more than half of these don't have any CVE at all.
[28:44.440 --> 28:51.380]  The AVTech one, which I think is being used in the IoT CTF right now, doesn't have a CVE or
[28:51.380 --> 28:56.860]  anything. And it's just a blog post that, you know, people have written about it. Same with like,
[28:56.860 --> 29:02.220]  you know, some of these Netgear ones, the Netgear DGN 1000, that's a huge one that people have
[29:02.220 --> 29:09.800]  exploited. I've never seen a CVE for, you know, the HNAP, Vacron, like Zyxel stuff, even actually
[29:09.800 --> 29:15.420]  go-ahead websites have some. But here, these aren't even SSH or telnet brute force stuff,
[29:15.420 --> 29:19.920]  this is like, like, a lot of the stuff here, like buffer overflow, or like command injection,
[29:19.920 --> 29:24.060]  and some of these aren't even being tracked by anybody. So when a new exploit comes out,
[29:24.060 --> 29:29.140]  though, bot scanners will really just immediately start trying to load bots with like whatever PFC
[29:29.140 --> 29:37.140]  people have. And it's usually IoT bots, and it's very annoying. So the infections spill over from
[29:37.140 --> 29:41.700]  that. So like these malware families are, you know, running on a super diverse array of
[29:41.700 --> 29:46.320]  architectures, like there's every architecture you can think of has a Mirai variant for it at
[29:46.320 --> 29:52.240]  this point. Because of cross compiling, but this means that this can affect other hosts that aren't
[29:52.240 --> 29:58.380]  IoT. And so people will try to use and they'll try to get Mirai onto things like web servers
[29:58.380 --> 30:05.380]  using like Drupal get in or Apache struts, or, you know, CouchDB or whatever thing is running,
[30:05.380 --> 30:09.920]  they're going to try to do that to have that be the scanner as well. So these sort of infections
[30:09.920 --> 30:15.240]  spillover is really common. And you'll see, sometimes like IoT botnets are using Drupal
[30:15.240 --> 30:18.820]  get in and you're like, what router is running Drupal? It's because they're trying to get onto
[30:18.820 --> 30:27.080]  everything. And so why are these devices so easy to exploit? And so we've talked, we were talking
[30:27.080 --> 30:32.360]  about this in the last talk here about, you know, supply chain issues. And so there's,
[30:32.360 --> 30:36.740]  it's very difficult to validate supply chain is a big one. There's vulnerable software and
[30:36.740 --> 30:42.260]  libraries that people use, they might not be able to change or have the people to even, you know,
[30:42.260 --> 30:48.480]  make the changes for it. Easy to guess default passwords is a huge one. Devices by default,
[30:48.480 --> 30:53.020]  doing port forwarding, listening on the internet, giant list of phone devices are passed around,
[30:53.020 --> 30:57.560]  which makes it even easier for people who don't know what they're doing to just start exploiting.
[30:57.560 --> 31:02.640]  And then it all comes down to insufficient or non-existent security practices and development.
[31:03.000 --> 31:07.680]  And so we're gonna get a little bit into firmware bones now and security practices. So
[31:08.440 --> 31:15.560]  you'll see there was a awesome talk, I think two years ago, Shmoo Khan, about firmware bones by
[31:15.560 --> 31:22.920]  CITL. And so there's a lot of stuff like vendor security practices on a binary level are like,
[31:22.920 --> 31:27.120]  they're, you know, almost non-existent. And there's even regression analysis to show that
[31:27.120 --> 31:32.200]  firmware is actually becoming worse and having more vulnerabilities introduced to them in a 15
[31:32.200 --> 31:38.280]  year data set, which is insane to me. So you see here, here's like every vendor that they had
[31:38.880 --> 31:43.520]  looked at. And you see anything that's closer to the edge here is going to have more of these
[31:44.080 --> 31:50.660]  things like stack guards or non-executable stack or railroad, ASLR, things that are closer to the
[31:50.660 --> 31:55.940]  edge are scoring higher. And actually that means that more binaries have these mitigations in place.
[31:55.940 --> 32:02.520]  But if you can see, there's very, very few that actually have anything on the graph. And then
[32:02.520 --> 32:08.300]  the ones that do, they only have like one or two, and there's very few. It's kind of sad. You want
[32:08.300 --> 32:12.940]  this whole, all these things to be blue, all the way blue, and there's like lines of blue,
[32:12.940 --> 32:21.100]  which is really disheartening here. And so why is firmware so difficult to maintain?
[32:21.100 --> 32:25.200]  So there's so many reasons for it. And I used to have done firmware development before
[32:25.820 --> 32:34.020]  for embedded devices. And even the experience that I had doing that is still... I could see
[32:34.020 --> 32:38.940]  all the echoes of this throughout the process, right? Because re-architecting cost is a huge
[32:38.940 --> 32:44.800]  thing. Cost is usually the biggest factor for why things aren't changing. But you can also be
[32:44.800 --> 32:49.240]  locked into a vendor contract. You can be locked into like a middleware contract. So you can only
[32:49.240 --> 32:57.200]  use drivers for this one piece of your kit, and you have to use it for a certain period of time.
[32:57.200 --> 33:02.160]  You might have unsupported chips or hardware to work with. Another huge thing is outdated
[33:02.160 --> 33:07.100]  toolchains. You might be using some toolchain from like 2005, and that's how you build everything in
[33:07.100 --> 33:12.900]  2020. There's also a lot of things like hardware restraints, which sometimes you might not...
[33:12.900 --> 33:17.680]  like your hardware itself might not support the SSL version that you need to. That was an issue
[33:17.680 --> 33:23.640]  that I've had to deal with before trying to figure out how you can, you know, jerry-rig a new SSL
[33:23.640 --> 33:30.560]  encryption scheme and support newer versions of TLS in firmware that's, you know, 15 years old.
[33:30.740 --> 33:35.160]  Sometimes you also need to maintain backwards compatibility, which is a big thing to make
[33:35.160 --> 33:39.620]  this stuff really... it makes it very, very hard. You have to include stuff that you might not want
[33:39.620 --> 33:47.180]  to. A lot of stuff though is a lack of dependable updates for users to update their devices.
[33:47.680 --> 33:52.740]  So even if you have, you know, all the other things in place here, it's sometimes people don't
[33:52.740 --> 33:58.720]  have like a way to actually update the devices without some complicated process. Poor communication
[33:58.720 --> 34:04.040]  channels even tell people about vulnerabilities is also a big thing. And vendors might not have any
[34:04.040 --> 34:11.020]  sort of like channels for reporting bugs or telling people about bugs as well. And then,
[34:11.020 --> 34:15.940]  you know, lack of modern security measures like secure boot or binary hardening we talked about
[34:15.940 --> 34:21.400]  before or code signing are not going to really be in place. And it's hard to get those things back
[34:21.400 --> 34:27.220]  into your, you know, pipeline if you have to do a bunch of testing and you only have a couple
[34:27.220 --> 34:34.160]  people working on the thing. And so why do we see a lot of this older stuff working? So there's some
[34:34.160 --> 34:41.940]  sometimes you'll actually see Qbots or Kytenbots or even Perlbots trying to exploit stuff in your
[34:41.940 --> 34:49.160]  and, you know, if you download binary. And it's because the vulnerabilities are still there,
[34:49.160 --> 34:55.080]  right? And so this is something that I had actually to steal an analogy from Mudge, right?
[34:55.080 --> 35:02.040]  In mining, there's indicator minerals that can prove that there are other things that you,
[35:02.580 --> 35:05.940]  what's it called? There's like a, say you're looking for like diamonds or something.
[35:07.040 --> 35:13.540]  There's like indicator materials that prove that this might be there, the thing that you're
[35:13.540 --> 35:22.960]  looking for might be there. And so the security vulnerabilities that we're seeing are showing
[35:22.960 --> 35:29.820]  that there are not as many security practices that are being followed, which means that the
[35:29.820 --> 35:33.860]  older vulnerabilities are still going to be able to work, right? So like we're seeing like,
[35:33.860 --> 35:39.660]  you know, there's still command injection here in 2020, and then you can still run a Qbot or a
[35:39.660 --> 35:46.460]  Perlbot on this device. This means that there's really not anything that's going into the actual
[35:46.460 --> 35:53.440]  process of making the devices any more secure. And what's interesting is this is rare in other
[35:53.440 --> 35:58.740]  classes of malware, like say for desktop computers, because there's no patch really that you can
[35:58.740 --> 36:05.140]  apply to one specific device or whatever. So each time that there's a new vuln that comes out,
[36:05.140 --> 36:09.180]  there's all these new devices that are added to the pool, but there's still all the routers from
[36:09.180 --> 36:14.360]  2014 that had shell shock vulnerabilities in them, and DVRs that still have auth bypass in them,
[36:14.360 --> 36:17.840]  and those are all just getting added to the pool. So people are just trying the same old
[36:17.840 --> 36:22.000]  techniques and they're still getting the actual devices that they would have exploited, you know,
[36:22.000 --> 36:29.720]  before. So it's kind of frustrating. So moving forward, this is the big thing for
[36:29.720 --> 36:35.480]  vendors and people who are, you know, developers of firmware and embedded devices. So what can we
[36:35.480 --> 36:42.140]  actually do to solve any of these problems here? So we can only really fix them by having better
[36:42.140 --> 36:47.640]  development practices for security by meeting the developers and the vendors where they're at,
[36:47.640 --> 36:52.060]  because we want them to be, you know, on top of their game actually doing,
[36:52.060 --> 36:56.940]  you know, the work that we'd like them to put in so that our, you know, toaster isn't, you know,
[36:56.940 --> 37:03.520]  DDoSing somebody because of some Mirai variant that's run by, like, a 14-year-old kid.
[37:04.420 --> 37:08.700]  So we have to, like, actually talk to them, talk to vendors the way that they...
[37:08.700 --> 37:13.680]  things that they already know in their... the way that they're already developing things.
[37:13.740 --> 37:17.260]  So for vendors, I guess my big advice here is to invest in developer training
[37:17.260 --> 37:20.820]  and to establish best practices and create security testing pipelines
[37:21.420 --> 37:25.320]  and encourage researchers to actually find bones and disclose them properly.
[37:25.320 --> 37:30.580]  We can mitigate some of the existing bones by encouraging safer use of IoT devices,
[37:30.580 --> 37:34.680]  but it only works so much because... imagine trying to explain to your parents
[37:34.680 --> 37:40.160]  how to, you know, turn off port forwarding on their... on their router, right? Like,
[37:40.160 --> 37:43.700]  they're not really going to understand it in the way that you might... I mean, they might,
[37:43.700 --> 37:49.260]  but they... you know, it's sometimes hard to get end users to actually follow your guidelines at
[37:49.260 --> 37:55.320]  all. They might not even be able to be aware of it. But that's one specific way that we can
[37:55.320 --> 38:00.300]  mitigate that. Establishing best practices, though, is a thing I wanted to highlight for a second
[38:00.300 --> 38:05.860]  here. So, like, auditing your development cycle itself. It definitely depends on what you're
[38:05.860 --> 38:10.200]  building, and you have to tailor it to that and be able to audit and say, hey, yeah, we are using
[38:10.200 --> 38:18.460]  C, we are using, you know, this tool chain, we're using either GCC, or, you know, UC Lib C, or
[38:18.460 --> 38:25.080]  whatever, to, you know, develop our firmware. But there are there are best practices for these
[38:25.080 --> 38:31.900]  things. So, OWASP, something that I had when I was doing firmware stuff, I had made developers,
[38:31.900 --> 38:37.780]  I had them look at these cheat sheets for OWASP on, like, toolchain hardening on, like,
[38:37.780 --> 38:44.280]  input sanitization for web apps, and, you know, how to do other things, you know, the best
[38:44.280 --> 38:48.960]  practices that there are. And there's tons of different ones like this. I just post to OWASP
[38:48.960 --> 38:54.680]  because it's, you know, very accessible for a lot of people, and it's free. Another big thing is
[38:54.680 --> 38:59.620]  CIS benchmarks. You know, there's, depending on what you're building, there are benchmarks for
[38:59.620 --> 39:04.700]  security that you can follow, which are super duper useful. You know, you can even automate
[39:04.700 --> 39:09.600]  that. I had done, like, Ansible CIS benchmarks before. You can build those into toolchains pretty
[39:09.600 --> 39:15.100]  easily. And then also, if you really need to, hire a consultant to come in and do all this work with
[39:15.100 --> 39:21.060]  you and work through it with your team. That's definitely a huge thing for vendors. Vulnerable
[39:21.060 --> 39:25.280]  disclosure, though, is probably my favorite one to talk about and the biggest one. So, when you
[39:25.280 --> 39:31.100]  do find people that are actually poking at your stuff, allow them to disclose vulnerabilities.
[39:31.100 --> 39:36.980]  Please, if you are a vendor and you're listening, there are ways now. It's 2020. You can't have a
[39:36.980 --> 39:41.540]  VDP. You can't have a bug bounty. You have to go through the channel, the proper channels, and make
[39:41.540 --> 39:47.740]  sure it's right for you. But there are a ton of resources. Disclose.io has, like, really good
[39:47.740 --> 39:52.840]  legal language and other things, resources for vendors. But yeah, people who do IRT research
[39:52.840 --> 39:58.400]  sometimes either get no response or they get, you know, a summons, you know, get sued for something.
[39:59.040 --> 40:04.360]  Establish security contact, though, and listen to email. There's security.txt is a really easy
[40:04.360 --> 40:09.020]  way on your vendor website to just have a email that somebody who has an issue or a vulnerability
[40:09.020 --> 40:13.780]  can talk to and not feel like they're, you know, trying to chase you down. Because, like, how many
[40:13.780 --> 40:18.180]  times do you see people on Twitter going, hey, does anybody have a vendor contact for, like, this
[40:18.180 --> 40:24.220]  company? And, like, nobody responds. It's like, if we have to go on Twitter to ask about this, not only
[40:24.220 --> 40:29.760]  does it draw more attention to your, you know, the vulnerability, but it also makes you look bad.
[40:29.760 --> 40:34.840]  So definitely, you know, keep up with that stuff. Work with researchers, too, because people who
[40:34.840 --> 40:38.860]  are bringing stuff up to you, they want to help you. If somebody wants to just use your device
[40:38.860 --> 40:42.880]  or crypto mining or, you know, to DDoS, you know, some kid on Minecraft, they're not going to tell
[40:42.880 --> 40:47.460]  you about it. So if you have a researcher that's here and talking to you, they want to help you.
[40:47.460 --> 40:51.540]  You should definitely, you know, heed their advice. And have some open channel with your
[40:51.540 --> 40:55.380]  customers, too, to have the word out about vulnerabilities. Like, if you either you do an
[40:55.380 --> 40:59.960]  internal thing or you submit to CVEs and then you post them on Twitter, whatever you do, just have
[40:59.960 --> 41:05.960]  something so people can know, update their devices. And ultimately, all these are elements of a
[41:05.960 --> 41:11.640]  vulnerability disclosure program. So if you put this all together, you have, you know, the baseline
[41:11.640 --> 41:18.520]  for what you need to actually have one, which is awesome. And so I've done a little quick
[41:18.520 --> 41:23.640]  question out there on Twitter, which you can see, I have the link here. But these are some
[41:23.640 --> 41:29.200]  community suggestions for what vendors can do. You know, everything from automatic updates to,
[41:29.200 --> 41:35.920]  I like the make a security in named persons problem. So like having say, like, I don't know,
[41:35.920 --> 41:41.180]  like Sherry has to deal with the, you know, firmware bones that come in. So, you know, talk
[41:41.180 --> 41:46.940]  to her if there's an issue. You know, other things like minimizing attack surfaces, code signing,
[41:46.940 --> 41:52.280]  all of this stuff is going to be part of other, you know, best practices that you're going to
[41:52.280 --> 41:57.380]  have to implement. But these are all, you know, elements of things that might be good for you to
[41:57.380 --> 42:03.480]  consider moving forward. Default settings definitely should be sane, and with security in mind. And
[42:03.480 --> 42:10.140]  also, don't reinvent the wheel. So final thoughts here, I got two minutes left, just about. So we
[42:10.140 --> 42:14.620]  want to make it less easy for people to run botnets, right? Overall, the supply is already
[42:14.620 --> 42:20.360]  there. The demand is great. Everything is set up. People can off the shelf, you know, get several
[42:20.360 --> 42:26.500]  thousand bots on botnet in an afternoon. Botnets are definitely getting a lot smarter. People are
[42:26.500 --> 42:30.800]  using the messy landscape of this to take control of it. Like if you see with the Kaiji botnet,
[42:30.800 --> 42:35.980]  which is definitely a lot more advanced than previous stuff. People are going to be using this
[42:35.980 --> 42:42.980]  for more nefarious purposes. And because there's so much going on in this space, it's very hard
[42:42.980 --> 42:49.800]  to pick out who is either nation state trying to get access into your router, or just some
[42:49.800 --> 42:54.000]  random kid who has no idea what they're doing. And new devices and architectures are always
[42:54.000 --> 42:59.600]  being targeted. As I said, FPGAs, there's tons of new stuff. You can read that analysis that I wrote.
[43:00.180 --> 43:03.900]  If you don't act soon, like the new products that you put out are already going to be
[43:03.900 --> 43:11.080]  dead on arrival and exploitable once they come out. And so yeah, the Q&A for this is
[43:11.080 --> 43:14.200]  going to be done in the DEF CON Discord, as you might have seen in the Twitch chat. So if you have
[43:14.200 --> 43:20.560]  questions, or you can always hit me up on Twitter, at netspooky. My DMs are open there.
[43:20.860 --> 43:25.920]  I got some shout outs real quick. Shout out to the Safari Zone crew, which is the people that
[43:25.920 --> 43:30.640]  have always been there to look for weird stuff on the internet. Hopefully we'll have a zine coming
[43:30.640 --> 43:35.540]  out soon. Threatland, everybody who helped out with that project to collect sources. And of
[43:35.540 --> 43:40.440]  course, the entire community of Thug Crowd. A special shout out to Hermit for helping me go
[43:40.440 --> 43:46.660]  through so much of this and be such an awesome person for, you know, looking at logs and other
[43:46.660 --> 43:54.460]  weird stuff. I like being able to tell me about a lot of interesting things that she has found.
[43:54.580 --> 43:59.720]  Andrew Morris, thanks so much for letting me use your data set too before it was even publicly
[43:59.720 --> 44:05.660]  available. Thanks to Mudge for coming in hot with some hot takes for me when I was building this
[44:05.660 --> 44:11.060]  talk. Check out Ilya's IoT Village talk on emulating IoT devices and malware, because we
[44:11.060 --> 44:16.440]  actually did a lot of that when I was writing this talk. And then thanks also to Dave for that theme
[44:16.440 --> 44:20.860]  song. So I'll have slides out. I'll tweet them out. Just follow me on Twitter and you'll see.
[44:21.220 --> 44:24.700]  I have citations if you want to read them. But yeah, thanks, everybody.