 For the next 45 minutes, we're going to be talking about a series of offensive RF exploitation techniques, particularly ones aimed at the physical and MAC layers of wireless communication systems. Reason why is because mobile and IoT means that wireless technology is more diverse and incumbent than it's ever been. So with that comes many more attack surfaces that we're excited to talk about in enumerate. So my name is Matt Knight, this is Mark Newlin. We're both security researchers with Bastille Networks. We're motivated by wireless security. We think it's really exciting. We're happy to be here. So we're going to begin with a brief historical rundown of the development of wired and wireless security technology. After that we're going to move on to introduce some key RF concepts and this is going to be pretty light, just enough to frame the rest of the discussion. And then we're going to move into what is really the body of this talk, which is our methods of wireless exploitation. What we've done with this is we've looked at a number of high profile attacks from the last couple of years and for each one we've categorized them and we've broken them out in terms of the mechanics of how the attack is performed. And then what we're really going to try to emphasize is analogs that exist on wired networks. And the purpose of this is to try to demystify really what's happening in the wireless domain. We're going to have some demos and videos and then we're going to leave you with some advice. So let's jump right in. So say you're a network security administrator in the 1990s and you want to take a look at what's going on in your network, get some bits out and see what's happening. Well, there were really two protocols that you were concerned about. You had ethernet and token ring. Looking into these protocols involved buying an expensive computer, running some proprietary software on it, totally proprietary, not that great. Fast forward to 1998 and ethereal comes out. It's sensory branded, we know it is wire shark. What this did was it massively it took the proprietary solution and it made it a commodity. So very cheap, very easy to use and people were able to hack on it and extend it. So that's great. So let's look at what's happened since the 2000s. The map of protocols that we're concerned with is a little more complicated, right? So 802.3 and you can probably still find token ring some places, they're still there. But additionally we have tons of wireless, right? We've got all these new protocols coming online. So it's a lot more complicated. If you wanted to take a look at what was actually going on in the air in the 2000s, you could go out and buy an early software defined radio. And this would, you know, could easily run you six figures, be a big PCI card that you'd have to hook into a powerful computer or network of computers. So, you know, it's proprietary, it's expensive, it's not that great. Fast forward to 2012 and a finish, I believe it's a finish, hacker named Antipol Sari was looking at his DVBT over the air receiver. It's a USB stick that you can plug in and anywhere where there's digital television with the DVBT standard, you can pull that down and watch it on your computer. Well, he was looking at the front end for that and realized that you could put it into a debug mode that would stream raw IQ that's complex samples of the radio domain back up to your host. So with a promiscuous driver, you can turn this into a poor man's software defined radio. It's pretty sweet. So fast forward to 2017 and software defined radios are totally commodity. For all sorts of price points, capability levels, targeting, you know, the hacker all the way up to the professional, something you can put into a product. This is revolutionized wireless security and the ability to look into these proprietary protocols. So in 2017, 802.11 is really just a piece of the puzzle when it comes to securing RF. We know that with the growth of mobile and IoT, there have emerged a number of different files. So really there's a physical layer for every use case. And many of these use cases target embedded systems. So embedded systems, we know to have been designed around compromise. You know, oftentimes they're battery powered. So they have to last for years at a time. Maybe they're limited in terms of the type of processing they can do on it, their ability to do cryptography, you know, good and bad reasons for why systems might not support that. Additionally, they may have limited network. So you might not be able to push forward to them. Maybe they have non-rewritable flash memory. So you can't push a new image to them. And just one picture that I really love just to emphasize how complicated the deployment of embedded systems can be, I have it there on the slide. What you can't see are three literal embedded systems. They're embedded in concrete. So you can think that pushing firmware to that is quite a bit more complicated than patch Tuesday. So combine that with an industry reliance on security through obscurity means that we as attackers have loads of targets. So that was a whirlwind run-through of the history. I'm going to hand it off to Mark and he's going to get started. So as security practitioners, you're probably familiar with using tools like Wireshark to look at Layer 2 traffic from 802.11 and 802.3 networks. And these allow you to use commodity hardware that give out these Layer 2 packets. With this kind of sniffing, you can't really look at the physical layer simply because the hardware you're using does not support it. So in the case of a Wi-Fi adapter, this is something called a hardware-defined radio. And we say it's hardware-defined because the logic that makes it speak 802.11 is baked into silicon in the chip. However, in order to look at wireless protocols, and we say wireless, we mean non-802.11, you need some different type of hardware. So on the left here we have a picture of a spectrogram showing a few different RF physical layers. And we can see that they're visually different. This is manifested in how they actually communicate over the air. And because we have all these different physical layers that you can't communicate with using a Wi-Fi adapter, we need to use something called a software-defined radio. And a software-defined radio is a flexible, generic, reconfigurable radio front end. And so you can change the center frequency, you can change your channel bandwidth, which is how much data you're pulling down. And you stream this raw radio data either to an FPGA or to your host computer. And this is great because all the logic that defines how the protocol operates, so whether it's 802.11 or Bluetooth or some proprietary protocol, this all exists in software. So instead of having one hardware-defined radio for every different protocol, you can have one software-defined radio and simply change a software on your host computer to speak these protocols. And one of the downsides of software-defined radio is that it can be fairly complex. And if you look at this image on the left, this is some RTL from a 802.15.4 software-defined radio decoder that Matt implemented. And as you can see, it's super clear what's happening there, nice and low complexity. And one of the concerns people have with SDR is this assumption that you're going to need to know a lot of digital signal processing and other complex domain-specific knowledge. And Matt and I have given a lot of time thinking about how to make software-defined radio more accessible to people. And to this end, we've given a series of talks titled, So You Want to Hack Radio. And the whole point of these talks is to explain how you can use great open source software and hardware written by some very smart people to extract away a lot of the complexity. And one of our favorite tools for this is called GNU Radio. And on the right here, we have a picture of a GNU Radio companion flow graph. And this allows you to drag and drop these great open source signal processing blocks and implement your transceivers, transmitters and receivers without having to understand the math that goes on under the hood. And I want to point out that Michael Osman and Balint Sieber have some great videos on SDR and GNU Radio in general up on YouTube, and I highly encourage you to look at those. Also a lot of very, very smart SDR people hanging out in the wireless village if you want to go talk to them. And now I'm just going to talk to you a little bit about some fundamental RF concepts. All right, so the purpose of this next section is not to make you experts with digital signal processing. It's just to provide enough context around communications in the wireless domain to be able to frame the rest of the discussion. So when we talk about wireless protocols, we're invariably involving the physical layer. The physical layer is the lowest layer in our communications model. And in wired protocols, it essentially defines how your ones and zeros get mapped into voltage timing and wiring, kind of the physical properties that underline the communication standard. In wireless, however, it defines how your ones and zeros get mapped into patterns of energy that are being sent over the RF medium. So RF is essentially the electromagnetic spectrum. You know, all wireless signals, if you sum them all up, you get a picture like this. This is a spectrogram. You have signals of different frequencies, carrying information. It's kind of just like one big shared medium. So manipulating RF can be done with a radio. As Mark outlined, they can either be hardware-defined or software-defined. But the key function that the radio performs is called the modulation. And the modulation is a function that exactly maps how those digital values get mapped into RF energy. It's kind of the core element of your wireless physical layer. So I'm briefly going to run through what happens from the perspective of a radio when you tell it to send a message. If you've developed a wireless system before, you probably get to the point where you call driver.send and you pass it a buffer. So you make an API call. And then that writes it out over spy or ITC or some interface to radio chipset. But what does that really do to make your bits magically appear in another system that could be some distance away? So the first thing that radio is going to do when it receives the buffer is it's going to append some information to it. It's going to prepend a header, which includes a preamble, a sort of frame-to-limiter and maybe some header-specific values. It's going to append a CRC so that it can check for errors that might occur during transmission. It's then going to perform that modulation function where those ones and zeros are going to get turned into a waveform. That waveform then gets run through an RF front end, which can include some filtering and some gain stages to make it more powerful. And then it gets pushed out to an antenna. And it goes out into the electromagnetic spectrum, into the RF medium that carries it to its destination. The receiver is a little more complicated. So your waveform gets picked up by the antenna, gets run through a demodulator, and that produces a stream of bits that wind up in a physical layer state machine. And if you were to break this down, it looks something like this. We're not going to go through this in detail. If you want to learn about how these physical layer state machines work, that's all with that talk. So you want to hack radios is all about, the one that Mark mentioned earlier. So we're not going to cover that here. There's some content out there if you want to know how it works. But essentially the physical layer state machine spins on that stream of information coming from the demodulator and ultimately presents a layer 2 frame back up to your host. So the key concept to take away from this is that radios are state machines and they're deterministic, right? What happens isn't magic. And the implementation of these state machines is informed by the fact that RF is very complicated. You have lots of contention from other interferes, other actors within the medium, whether they be unintentional or intentional. You could be unintentional just in terms of being in the 2.4 gigahertz ISN band where Wi-Fi lives, Wi-Fi is really active or it could be intentional if you have the case of somebody trying to jam you. Anyway, these radios are designed with features to compensate for the fact that this medium is very complicated and failure prone. So between all this we can find some interesting cases that we can begin to abuse to construct some novel attacks. So that brings us to our methods of wireless exploitation. So what we've done here is we've categorized the major wireless attacks that have occurred in the last couple of years and we're going to present them to you. For each category, we're going to show the method of how the attack is performed, the impact it enables, and number 3 is the big one. We're going to highlight analogous attacks that exist on wired or IP networks if such ones exist. Again, this is just to provide as much context around the wireless domain in terms of how it's similar and how it's different than wired attacks. We're going to present some limiting factors, whether it's incidental or intentional mitigations or limitations. We're going to provide some examples and then we're going to provide some demos as well. So to kick it off, I'll pass it back over to Mark and he's going to take you through sniffing. So when we speak about sniffing in this context we're talking about sniffing the physical layer. And there's really no analog to this in the wired domain. As I said with like an Ethernet adapter for example, you're unable to see the physical layer package you're only looking at layer 2 and higher. Sniffing allows you to observe the RF medium that's in use by other devices that you do not control and recover data that they're transmitting if they're unencrypted for example. Or you can have a reconnaissance goal and enumerate devices and environment for future attacks. The big limitation of RF physical layer sniffing is range and you have to be physically proximate to a device. And when we say physically proximate, we don't mean in the same room, we just mean within range of the budget of your antenna and your amplifier. There are a couple interesting sniffing attacks in the last couple years. Matt has demonstrated that you can recover the cryptography key from this Zigbee door lock by sniffing the pairing sequence that happens between the lock and the smart hub. And then you can operate the lock yourself and walk into somebody's home. Last year I did a bunch of research into wireless keyboard security. And I demonstrated that a lot of keyboards on the market are actually unencrypted and vulnerable to keystroke sniffing. So for a demo here, I'm going to be looking at the HP classic wireless desktop keyboard. And this is based on a transceiver from a company called Mozart semiconductor. And this is an unencrypted wireless keyboard transceiver that I reverse engineered last year. And it's actually over the air compatible with these common Nordic semiconductor NRF 24L transceivers. So it's possible to use this off the shelf, hardware-defined radio to sniff unencrypted key strokes from this particular device. Now we're just going to switch over to a quick video demo here. So on the left, we have a keyboard focus on this terminal. On the right, we're running a sniffer script with one of these Nordic NRF 24 dongles. And as we see when I'm typing with the focus on the left terminal, that's the actual input from the keyboard. And on the right, it's actually sniffing these unencrypted keystrokes and putting it out. And this is a, you know, pretty low complexity example of a sniffing attack. And now Matt is going to speak to you about war driving. Okay, so war driving is really a nuance on the sniffing attack. Essentially war driving involves conducting sniffing, but while doing so scanning for identifying features of a protocol or device of interest. Optionally, we have the ability to actively beacon to attempt to induce traffic from devices that we're looking for. So the impact here is we're able to discover and enumerate exploitable devices or networks that might be present within your physical environment. And a wired analog to this is port scanning. You know, using end map to go and knock on doors to see what services might be present on a system or a network. On the right, we have a screenshot from Kismet, which is a really popular, really popular wireless kind of reconnaissance framework that enables war driving. Among other things. So some limitations. You have the same constraints placed on you that you do with sniffing. Additionally, you need to manage channels. If you're looking for a system that might be on multiple channels. You might have some front ends to manage in terms of how you share your time among all the different frequencies you could be looking at. Additionally, active war driving can be very easy to spot if your defender knows to look for it. Because you might be hopping from channel to channel, if you're aware of that, that's going to leave a big footprint that you're going to be able to identify. So a classic example of war driving is, of course, your 802.11 AP Discovery. And you know, think guys like back in the early 2000s driving around with their laptops and custom-made cantinas looking for free Wi-Fi. It's kind of the classic example. However, a more modern and IOT focused example is war driving for 802.15.4 coordinators. So 802.15.4 war driving, I'm going to show you a quick video of it in a minute. For this, I used the Killer B Exploitation Framer to crash broadcast beacon request messages. And then I used the APiMode hardware defined radio board to send them out and listen for responses. So what this will do is it'll channel hop through all the 802.15.4 channels in the 2.4 gigahertz band, sending out these requests, and if a coordinator is present and sees that, it'll respond with a response. We'll see what that looks like. Do we have made the transition with all the AV stuff? So we'll get that up online, you can watch it afterward. So the next attack is a replay attack. And a replay attack is a command injection attack that involves retransmitting a previously captured physical layer frame. Now this can either be a frame that you demodulated and have the bits for, and then you re-synthesize with the modulator and send out, or it can even be as easy as retransmitting a raw captured physical layer frame, your raw radio information. The impact here is command injection. You can change the state of a network or device by getting it to recreate previously observed activity. So the wired analog is exactly the same. You can have replay attacks on wired networks too. So some limitations of this is that the replay attack is pretty easily defeated with using and enforcing freshness, so sequence number, or authentication, having a cryptographic handshake to establish the authenticity of the message. So one high-profile example of this came just a couple months ago. You may have seen in the news that at around 1.30 in the morning on a Tuesday or Wednesday, all 156 emergency tornado alert sirens in the Dallas metropolitan area started going off and just playing this really shrill loud noise. It took the authorities about 90 minutes to get under control and get those turned off. Obviously that inconvenience people in Dallas who were woken up by it, but it also gave people a lot of cause to turn because this is right around when some saber rattling with North Korea was happening, so it made a lot of people pretty uncomfortable. We at Bestial have done a lot of analysis on what we believe this is. We've concluded that we believe it's an RF replay attack. The systems are tested, I believe it's quarterly, so it would be trivial for an attacker with a soccer-defined radio to capture that signal and then go back and replay it at a later date to induce that behavior. So the logistics of getting an authentic response to Caesar's Palace is a little bit much. So instead I have a surrogate that I'm going to show you. I have a Fortress Security Safeguard panic button. So this is going to be our surrogate. Essentially you've got this little siren remote controller to control it. It's a very simple on-off-key protocol, no freshness or authentication, so I'm just going to grab some raw IQ and then we're going to replay it to induce the attack. And I'm going to do it within the fair day cage here. We were our cellular demo in here, but I brought it all this way and I want to use it, so bear with me. So now we're going to capture the output from the transmitter for this device. Then we're going to replay this and demonstrate that we can set off this siren just from this RF capture. I had the siren turned off, I'm going to turn it on again and we're going to play the signal into it. You really shouldn't clap for that. It's very easy. Okay, so that brings us to our next attack which is jamming and I'll pass it over to Mark. So the concept behind jamming is pretty straightforward and it's somewhat analogous to a denial of service attack except a little bit lower complexity. So imagine we have Alice, Bob and Carlos trying to communicate on a wireless medium and Donald wants to come and blast a bunch of nonsense noise to prevent them from communicating. In this case Donald will be implementing a jamming attack and jamming allows you to transmit noise to prevent the RF medium from being used by other devices or networks. So you can block traffic or potentially disrupt the network state. There are a couple of general limitations to jamming attacks. One is that a lot of devices implement a jamming detection mechanism where they can see if somebody is trying to jam them and then alter their behavior. The other big downside is that if you're trying to jam a network, you don't have the ability to both jam and listen to the network at the same time. So if you're trying to do reconnaissance, you can't prevent traffic as well as receive it. It was a good example of a jamming attack that our colleague Logan Lamb discovered two years ago. He was looking at home security systems provided by ADT and he discovered a wireless link between these door and window sensors and the control panel that sets off the alarm. So in this case the door and window sensor when you open and close it, it will transmit a RF message to the control panel and tell the control panel that the state has changed, in this case a door or window has opened or closed and then set off the alarm. What Logan discovered is that you can jam the 345MHz channel that these devices operate in and then simply walk into somebody's home and the alarm system will not go off. So here we have the control panel from the home security system. We're opening and closing the sensor and we can see that the alarm state has not changed. In this case we're jamming it. So now we go and we stop the jammer and now we'll be able to actually open and close the sensor and we see that the alarm is triggered. This is a very, very simple attack. So for these simple kind of jamming attacks, there are actually some different types of smart jamming that we can use to evade these jamming detection mechanisms. So there's a feature called clear channel assessment where a hardware defined radio will listen to the energy level in the channel it's trying to use and if it detects another device, it will not transmit. So for example, if we have a packet length of 10 milliseconds, the device will say if the channel is occupied for more than that 10 milliseconds and it's likely somebody's jamming and then alter the behavior. So what we can do is pulse our jamming and then alter the behavior. So what we can do is pulse our jammer on it off and we can jam for 9 milliseconds and then turn it off for a millisecond and then turn it back on and by doing this we can still effectively jam a channel without actually triggering these jam detection mechanisms and Matt has publicly demonstrated this with an 802.15.4 anti-jam detection evasion. We also have something called reflexive jamming and this allows you to target specific devices or packets on a wireless network. The way this works, you listen to the packet coming in, you can jam the information based on one of the addresses in the header or the specific packet that's being transmitted and then you start jamming as soon as you make this determination and this allows you to jam the end of the packet and for example cause a CRC failure. A good public example of this is Sammy Kamkar's role jam device which you released. Now there's a bit of a virtual jamming we can do that takes advantage of a MAC layer reservation system in 802.11 networks. So if you're a 802.11 packet you can include a duration field in the MAC header and this duration field specifies the amount of time you expected to take for you to transmit your packet and receive an AC. Other devices on the network or within range will listen to this duration field and assume that the channel is going to be occupied for this amount of time. They will then turn off their radios to save power instead of sensing the RF energy on the channel. So we can actually take advantage of this by sending a zero trick other devices for not transmitting for the next 32 milliseconds and this allows us to have a very low duty cycle of transmission but effectively jam a channel. So for a demo here I have a single one line ScapiScript which I'm going to transmit some of these packets on and will demonstrate that we can prevent another device on a separate network from communicating. So here on the right we have a device, a client pinging its access point. I run the ScapiScript and on the right we can see that the ping starts again, 50 packets in this case. Then after a few seconds we'll see that the ping starts again and this is pretty neat because we can send only 50 packets and effectively jam the channel for several seconds. Now we have a type of attack called an evil twin and this is something you may have heard of. As you can see by the beard here on the right this is an evil twin access point and the concept behind an evil twin is that we can convince other devices to connect to our traffic. This is very similar to an ARP spoofing or ARP cash poison attack on a wired network. The big limitation here is that there is often trust that exists between client and access points or base stations and so in order to effectively implement an evil twin attack we need to be able to either turn off that trust or replicate the state of that property. The Wi-Fi pineapple is a good official device that allows you to implement a Wi-Fi evil twin attack. Their device is called empty catchers and convince devices to connect to your malicious base station. So for a demo here we're going to use a fake base station that we spun up with a software defined radio and use the open BTS software and I want to point out that it's very, very illegal to try and trick other people's phones to connect to your base station so please do not do this and I will show a quick video demo. So here we have a cell phone and a Faraday cage and at the time we started this video I've also turned on a phone connected and as soon as we turn on our fake base station the phone is searching for the network and it's starting to register and then now we have the phone, you can see the change here, the phone is now registered on our network and this is something we've spun up with open source software on a software defined radio. And now Matt is going to speak to you about malicious over-the-air firmware updates. Okay, we're going to cover this one quickly. So a malicious over-the-air firmware update attack involves you then exploit the fact that your target device, if it has one, has an over-the-air firmware update mechanism where you can use its wireless network to deliver new software to it. So the impact here is you can basically extend the device to conduct behavior that the manufacturer didn't intend. So this can include remaining persistent on the device, denial of service is a big one that we saw last year with Bricker Bot which is a Mirai variant. It can also be self-propagating too, just like a traditional endpoint malware or worms. So limitations here is that this is pretty easily defeated by signing your code, using secure boot or an equivalent technology, or encrypting your network and doing so well. If you do either of those things, you're going to make it a lot harder to execute an attack like this. So there are two examples we're just going to describe briefly. The first was Cesar Cerudo from IOActive, his hypothetical traffic light sensor worm which was an 802.15.4 based system. He analyzed it a couple of years ago at Black Hat, found that it was completely unencrypted and they weren't signing their images so it was trivial for him to make his own and push it. He then theorized that you could make it self-propagating and go from there. Such an IoT worm was actually demonstrated at the end of last year with a Philips Hue Zigby light link worm. There were a number of researchers that contributed to it. They did such a good job with this, I'm just going to say the paper's really good and their video's awesome. They strap a 15.4 radio to a drone and fly it up to an office building and hacks the lights. It's cool. So check that out. They do a better job of showing it than we could. So this is our last attack that we're going to highlight in this session. And that's what we're going to call physical layer selected targeting. And I'm just going to first talk about this. I think it's pretty interesting. So when it comes to developing wireless standards, you have 3GPP. They get together and they determine what they want the protocol to look like. What features they want it to have, what the physical layer looks like, how it integrates with other systems, et cetera. They then take those thoughts and they turn them into a several thousand page document. It's very technical. Lots of details. That document, they get handed off to a chipset manufacturer who has to interpret it. So they take that and they kind of take their best effort to implement that standard as well as you might imagine, they there are some nuances as to how accurate or how similar they all do that. So we can exploit that. We can exploit the fact that different chipsets have different radio state machines. So what we can do is we can fingerprint the state machine and then send standards non-compliant transmissions to exploit corner cases within it. And the impact here is we can do things like selectively avoid certain targeted receivers which is useful in the case of for example, we can also do device fingerprinting. We can send a number of frames of different characteristics, see what comes back and with that we can figure out what kind of radio chipset is present within our environment. So this has been demonstrated on 802.3 Ethernet networks in the case of avoiding land taps, but this is far more practical in the RF domain where the domain is really defined by promiscuity. The fact that you don't have to be physically connected to a bus in order to do that. So some limitations here, in order for this to work, you're counting on network participants being on different chipsets. If they're all in the same chipset, they're going to be able to see the same type of malformed message. So I'm going to show you a quick example of an 802.15.4 receiver of Asian attack. It's pretty interesting. Essentially I'm using one transmitter in API mode to craft various, variously deformed 15.4 messages and then I'm going to use two different receivers that have different chip sets so I'll just roll a quick video and talk you through it. So up on top we have our transmitter and then we have two 15.4 receivers on the bottom. On the left we have an ATML receiver and on the right we have a TI receiver. Five compliant messages to get started. Now I'm going to insert two extra symbols into the header of the 15.4.5 and you'll see that the RZ USB stick receives that but the API mode does not. Now the video is cut short. I'll release the full video online by taking two symbols out of the header. We're able to target the TI radio and avoid the APML radio. This brings us to the end. So we've looked at a number of different types of attacks and we've drawn some analogs between them. The key thing that I want to highlight with this is that some attacks are quite difficult to implement but some are very hard to mitigate. So anything involving RF promiscuity is very hard to avoid just the nature of how the RF medium works. The fact that your electromagnetic energy radiates outward means that for a stood up attacker there are lots they can do with it. It's very hard to conceal that. Additionally this is a non-exhaustive list. As you start to get into wireless I'm sure you'll find many other ways of exploiting wireless. We think we've done a fairly comprehensive job of boiling down kind of the essence of many of these attacks into a few different categories to kind of get you started. So as attackers the bits of advice I'll give you here are the easiest attacks because the easiest attacks are you want to start with easy attacks before you get more complex things because the complexity goes up in a hurry. As we've seen there are analogous attacks on wired networks so you can lean on your existing skill set wherever possible. Additionally leverage open source intelligence. Those are things like FCC regulatory filings and data sheets because they'll make your life easy. If you want to learn more about that in one last note this is both a challenge to everybody in the room and also a warning to developers. Know that we're living in the golden age of our hacking. It's because software defined radio has been commodity for more than five years. That really means that every wireless spy is in scope. Obscurity is not relevant anymore. You can buy the tools, you can make the tools to expose just about any wireless spy that you'd like. So go forth. Own the airwaves if you're an attacker. Go make your defender. Be aware of these threats. We have some radio resources if you want to learn more about this. We just tweeted them out so don't try to take pictures of the slide. You'll be able to get them online. Want to acknowledge our team at Bastille and DEF CON for having us. And thanks very much. Appreciate it.