This talk is about VPN filter and the malware campaign and because this is the ICS village we're going to focus about half the talk on the ICS specific component of this which had some Modbus capability and try and give everybody a better understanding of exactly what that was. So this is I'm Patrick DeSantis. This is Carlos Pacho. We are two of many researchers at Cisco Telus that spent a long time working on this project. Many months, many hours, lots of really smart people doing really cool stuff with this. We're two small pieces of a much larger group that probably did a lot cooler stuff than we did but you get to talk to us instead. So some boundaries I'm going to set for the talk. I will talk about VPN filter and its technical capabilities. We'll talk about the targets and specifically we'll spend a lot of time talking about the Modbus module. I will not talk about attribution. The US government took care of that. I will not talk about any of our partners or victims associated with this campaign. So no. So VPN filter is a multi-year state sponsored very sophisticated malware campaign targeting primarily edge devices in the small office, home office realm. It's been going on since at least 2016. 2016 was the oldest sample that we are aware of. So it's been going since before that and at the time we went public in May we estimated there were about half a million infected devices globally. That number can go up and down depending on how active the actor is. So this is a nice conservative estimate at least half a million which is still a significant amount. And it's interesting because it's cross-platform. This is malware that runs on multiple operating systems and even multiple architectures. So we've got samples that run on MIPS, variant of MIPS, MIPS, Lexra, XC6, Tile, more. And then within the specific architectures that are targeted the biners that were compiled were specific for the devices that were going to run on and there were a lot of devices. So we're aware of over 75 distinct device models from several vendors that have capabilities compiled specifically for those devices, which is some pretty serious effort on the part of the actor to go through and put that much work into it. Especially when a lot of these are, you know, sub $50 SoHo devices. Other ones are like the Microtik or McCrotic, I'm not sure how the correct pronunciation is. Those are Rackmount, like enterprise-grade network appliances. Most of the rest are SoHo devices. Some are basic, like home wireless routers. And then QNAP stuff that we saw was mostly, I'm pretty sure was just network attached storage devices. So during the time that we were working on this, a vast majority of the activity was targeting Microtik and QNAP devices. But that was just during the time we were looking at it. If we had looked six months before, there may have been more or less activity. And you know, if we're looking six months from now, it may vary also. So but at the time we looked mostly Microtik, mostly QNAP, and lots of devices. So we needed to get into a position where we could bait the actor into delivering some of their, you know, some of those custom payloads for those other devices to us without tipping off our hand that we were actually working on learning more about it. And so we were kind of stuck in a position where we wanted to set up like a honeypot infrastructure, leverage honeypots. But your traditional honeypots are often limited in their capabilities. We couldn't give any indication that we were in a, you know, in a honeypot. So virtualized or emulated environment was a no go. So often your honeypot configurations don't capture full network traffic. We needed a full pcat. We couldn't deal or we couldn't handle just metadata about the traffic. We needed to be able to look at everything that the device has received and pull files out of them because if the actor brick the device, we lose all forensic artifacts. So we needed all network traffic. So we had to stand up our own, our own honeypot infrastructure. And we did that using real devices. So it was full interaction, honeypots, real devices. We bought about 40 of them.  This is the target zone. So these are real devices.  So we had real devices and they had to be not obvious that it was Cisco. And the switch here, these devices can talk out and everything can talk yet. So it's like they're on the internet directly, but they can't talk to each other unless it goes out and comes back in. So they don't see each other. And the switch has a mirror port, span port that goes to a network tap, one way network tap, which goes to our analysis work station, which was very locked down and is set up to not allow any traffic out. So we've got three places to block any outbound traffic from our analysis zone here. It would not be a good thing if the actor associated with this campaign were able to go from here to our internal corporate network. I wouldn't be here talking about it today if we did. I may be out there with you hanging on my resume. So we spent a lot of time and effort on this component. Right here, we had full network traffic. So gigabytes of traffic a day associated with activity on these devices was living here. And that's where we did our analysis. Sustaining up this full interaction, honeypot environment has some issues, some challenges. There's a reason why people use the limited interaction, honeypots and it's offers a lot more convenience, especially when you're spinning up VMs, you can just replicate them. You don't have to actually manage the physical devices. We had 40 devices, 40-ish. Some of them we bought used so you can't trust them. So we had to go through each device, validate that it wasn't already owned, set it up in an intentionally vulnerable configuration because we wanted them to get owned. So we had to put our firmware on there with known vulnerabilities and publicly available exploits. We set them up for configurations. There was a large volume of traffic and none of it was legitimate because these devices weren't doing anything, but it didn't show up on your screen. Flamingo wants you to join their wi-fi Larry. So all traffic going to these devices was malicious or even if it was benign, it was not legitimate. So there's an old phrase looking for a needle in a stack of needles. It applies very, you know, it's very applicable to this because every bit of traffic was not legitimate. And we don't really know what we're looking for. So we have to find something bad in gigabytes and gigabytes of bad stuff. And then there's the security versus usability. I think Carlos and I, well, we probably had each other in the headlock a few times as I'm advocating for security. As I said, if the actor made it their way into our network, bad stuff, but every time I lock something down or advocate for something to be locked on more, it's inconvenience and annoyance for the researchers that need to be able to interact with the devices and do analysis on the traffic. But because of the sophistication of the actor, we had to err on the side of security, much to my team and other people's, well, I owe them some beer, I guess. And then device limitations. So you see this is just like in control systems. These are often embedded systems. The legitimate management interfaces don't provide a lot of functionality for legitimate users. So you can't just drop down in the shell and log in as root and do whatever you want in Linux. You know, you might be in a limited environment or maybe the only administrative control you have is through a web interface. So just like an ICS, an attacker who owns the device has more control over it than the legitimate user. So we found ourselves in a position of actually exploiting and owning our own devices just to find out if they had been owned by somebody else, which is interesting. So that was kind of how we dealt with the risk associated with interacting with having live targets intentionally infected by a state actor. Now the Meller itself that we're going to get with, there were several groups that did reversing and analysis of the actual Meller, but I do have to clarify one thing before we go into that. And since we went public in May, there's kind of been, I don't know how it started, but there was an initial misconception about the relationship between VPN filter and Black Energy Meller. So Black Energy has a flaw in the implementation of the RC4 encryption algorithm, where it fails to properly initialize the S-boxes during their permutation stage. So it's a very, very, very specific flaw. It's not just like, oops, we used the wrong library. VPN filter has the exact same flaw and the exact same part of the implementation of the S-boxes in the permutation stage of the RC4 encryption algorithm. So there's overlap there and it's a very specific overlap. VPN filter does not contain a full copy of Black Energy. So it's just the overlap that was the only connection that Talus identified and reported. So if you see anything else out there, it's just RC4. It's a multi-stage Meller, very sophisticated. I'm going to probably say that 20 times, but you start with initial exploitation and the Meller drops a persistent loader that's specific for the target device that it drops on. The loader in stage one is the only part of the Meller that has persistence that can survive a reboot and that depends on the device. Aside from being persistent, stage one's only job is to find the stage two server, retrieve and install stage two. It has some really interesting ways of finding the stage two server.  You run it through a decoding routine which one of our guys reversed and you can pull out IP addresses out of the latitude and longitude. It'll then reach out to the IP address and try to get stage two if it doesn't work. It tries a couple more images. If it doesn't work, it eventually goes to a hard-coded domain. If that doesn't work, it does what I think is probably the most interesting part of this stage. It opens up a raw socket and listens for all traffic on all ports and if it receives a TCP SIN with a very, you know, with specific bytes, a specific value, it'll grab another set of bytes and that's the IP address for the stage two server. So it's basically it looks out, tries to get stage two, can't get it, it looks out another way, can't get it, falls back into this passive listening mode where the actor can intentionally task it with this but just by using one TCP SIN to give it the IP address of the current stage two server. When it gets stage two, stage two is your framework, it's the workhorse, closest equivalent I can give you is like it's the meterpreter component and that it has some baked-in functionality and it also has extensible and you can add other modules. So you can execute shell commands, it's got some collection capability, it's got some X-fill capability, some of the older stage twos we looked at had a built-in kill capability where it would actually brick the devices, talked about that in a second two, and then it's extendable through these stage three modules and plugins which because it's extensible through modules, the functionality is essentially unlimited, it's only limited by what the actor actually develops for it. So Carlos is going to talk about one of those stage three modules. This is a diagram of what I described the process of going from exploitation to stage one, to stage two, to stage three. I could spend an hour up here talking just about this slide, I can't do that, I'm not going to do that, I don't want to do that but everybody that worked on this will be, we sat through several hours trying to understand this from many angles. This image is on the Telos blog, the initial blog post that described when we went public with VPN filter. It's very interesting, obviously very sophisticated, when the takedown happened there was essentially the photobucket or two-no-all angle had been taken down, the only thing left was the raw socket. So the person had the device was in fact that if you rebooted it it would try to go to photobucket, this stuff wasn't there anymore, it would try to go to all, to no all, it couldn't. So it sit with the raw socket, it was still vulnerable but the actor is going to have to reach out and touch it manually at that point. So some of the stage three plugins that we've seen, these are the modules that come after stage two, these are the extensions, there's a packet sniffer, this is the one that Carlos is going to talk about, there's one that we refer to as ESLR, which is interesting because this module allows for modification of traffic as it passes through the compromised device. So you've got your perimeter device, your edge router, all traffic on port 80 or going to port 80 is getting man in the middle and JavaScript can be injected into the traffic that returns the devices on the inside of the network. So this module allows the actor to compromise devices on the inside of the security primer without actively scanning and exploiting them, it happens invisibly at the router. There's a tour module which gives stage two the ability to communicate with command and control over tour and then the kill brick component that I mentioned wasn't stage two, it meant the older stage two is we found had baked in kill. The newer ones it was missing and we had a suspicion that okay there's probably a stage three that does that and later on we confirmed. So this destroy will go through and clear artifacts like indicators of compromise is trying to erase any tracks of its presence and then it will brick the device. Usually the brick is by overriding the first I think 5000 was the most when we saw 5000 bytes of flash. So it's essentially wiping out the boot loader and the device is done unless you can reprogram that flash memory which you're not doing on any of these devices and 99.9% of the population couldn't even do it if the capability was there. So brick device bad. I said very specific or very sophisticated. So why would somebody go through the trouble of actually building something like this spending several years doing it deploying it globally. Obviously it probably costs millions of dollars over time. This is a global intelligence infrastructure. What we used to refer to is computer network operations are now referred to as cyber operations. This gives a massive distributed global network to conduct those cyber operations from and mask attribution. So any attacks or traffic that comes through this network is going to look like it comes from a SOHO device you know somewhere in wherever they choose to make it look like comes from makes it difficult to track people or track the or attribute attacks. It's also a data collection platform passively. What Carlos is going to talk about is going to mention some passive collection and active these devices have been used to scan for other things and then sometimes scan for other vulnerable things and then exploit them and add them to the VPN filter network. The destructive attack is the thing that we were the most worried about when we had to decide whether or not we were going to go public or when we would eventually go public but this kind of drove us to go public when we did. The actor had the ability to effectively knock about half a million networks off the internet all at once. So not half a million devices by knocking these routers off you're knocking everything behind the routers off the internet too. So to take a half a million networks off the internet all at once it's pretty serious stuff and we were pretty worried about that thankfully it never happened. Also we've got the ability to exploit inside the network. If the actor was on the internal network and had been kicked out they have a point of presence on the edge router and unless the incident response team actually went validated that they were booted off those edge routers they can come right back in and then everything that their botnet can do this can do too so it has a lot of value. So that's kind of a big picture overview. The the four hour discussion about what VPN filter is distilled down into 15 minutes. This is the ICS village we want to talk about stuff that ICS people care about. Carlos is going to talk about the technical aspects of the VPN filter Modbus module. Carlos. Thanks Patrick. All right so I'm going to talk about the VPN filter packets and different module. The packets and module was responsible for inspecting packets and logging certain connections. Specifically the packets for module would log connection information about HTTP and certain Modbus connections. The packets for module was targeting the R600 VPN router which is a five port SOHA router. When we did a quick search on showdown we found around 5,000 of these devices online. But I think it's safe to assume that there's a lot more than 5,000 devices online because showdown was showing us ones that had no management enabled and were accessible on the internet. So this is the picture of the device, the Tieflink R600 VPN router. The malware was specifically targeting this device. So the packet zipper is compiled for Lexra. Has anybody here heard of Lexra? Cool. Two people. All right. This project is the first time I've ever worked with or even heard of Lexra. It's really similar to MIPS but it's missing some instructions. Initially when I started working on this I thought the device and sample were MIPS and this was problematic because Patrick and I were attempting to get compiled MIPS code running on the R600 but we kept getting seg faults. Eventually one of our coworkers found out it was Lexra and helped us out with that. So it was good.  He works on our team at Cisco Talus and he was the first one to reverse the packets for module. The sample was first uploaded to virus total in 2016.  I wonder how long the module's actually been around because 2016 is just the first time it was uploaded to virus total. The module is a Linux elf. It's stripped and statically compiled. The fact that it was stripped and statically compiled made reversing a little bit more difficult. We had no function names, even libc functions. They were unnamed which was pretty annoying. So the sample will inspect every packet. It'll literally do some checks. So it'll first check to see if the packet is greater than 150 bytes, if the packet's IPv4, and if the packet's TCP. If all those conditions are met then the sample will look for modbus nhdp. So in order for the packets in it for module to run, two arguments need to be provided. The first argument is the logging directory. This is where the logs will be stored. And the second is an IP address. If these two arguments are not provided, the sample will just exit. But the two arguments are provided, immediately enter the packet parsing loop. So in the packet parsing loop, in the beginning we have some IP checks checking for IPv4, TCP, and the packet size. And if those checks pass then we will start looking for modbus. And if the loop does not detect modbus then it will check for hdp. So all network traffic passes through this loop. And the loop is specifically looking for modbus nhdp and it will discard anything else. So if something doesn't meet the criteria for modbus or hdp the packet will be discarded and the loop will be restarted with the next packet. So for each packet loop is going to check to see if the packet is greater than 150 bytes. Then the loop is going to make sure the packet's IPv4 and TCP. And finally we start the modbus and hdp checks. So first off, for those of you who may not know modbus is an ICS protocol. It's commonly used by PLCs, runs on port 502, and the protocol is open so you can grab it from modbus.org and it doesn't support encryption. So once the loop has done the initial IP checks, the loop is going to check for modbus. It does this by checking to see the packet's destination port and seeing if it equals 502. If it does then the next check is if the packet's destination address is the same IP as the IP provided by the second argument provided to the binary. If both those checks return true then the sample considers this packet, a modbus packet, and login code gets called. So the log file is stored in the location provided by the first argument. The log file will be named rep underscore percent u dot bin. Four percent u is the time the log file was written. The only thing that gets logged for the modbus portion is the source IP, source port, destination IP, and the destination port. So this is an example of what the log file might be named and what it might contain. So rep underscore and a time value dot bin would be the name of the file and then what's highlighted in orange is what would actually be inside the file. So we have asterisk modbus asterisk new line, source IP, colon source port with a little arrow, to destination IP, destination port. I wonder why a sample specifically designed for SOA router is looking for modbus. I don't know if this router will ever be in a position to look at ICS traffic or modbus traffic. And additionally I wonder what value the modbus log provides. The only thing that's log is the source IP, source port, destination IP, and destination port. And the destination IP address and the destination port have to be provided to the binary. So the only thing that you get really is the source IP address and the source port. So as loop continues, if the loop determines that the packet is not modbus, then it will start looking for HTTP authorization. So just a quick recap. In order for the HTTP checks to start, the packet needs to be TCP, IPv4, greater than 150 bytes, and not modbus. Then we have the HTTP checks start. So HTTP checks consist of checking the destination IP address, source port, length of the data, and then several strings checks. The destination IP must be the same as the IP address that was provided to the sample when the sample was initially started. So it's looking for a very specific IP address. The source port must be greater than 1024, but it can't be 80 or 8088. The length of the data must also be greater than 20 bytes, and then we move on to the strings check. So in order for the packet to be logged, the packet must not contain any of the strings in that code block. And additionally, the packet must contain the string authorization basic or a username and password combination, but it can contain both. If it contains both, the packet will be discarded and the loop will restart with the next packet. So in this code block on the left, I have user names or user parameters, and on the right, password parameters, so you have to have one from each side in order for the packet to be logged. If the HTTP login criteria has been met, the entire packet is logged to rep underscore percent u dot bin, where percent u is the time of logging. And the log will be stored in the location provided to the sample when you initially ran it. So it looks like the HTTP checks are looking for credentials to a specific website. It's highly targeted as the destination IP address is already known and needed for the packet zipper sample. Additionally, the sample does not send logs off to a remote server, but maybe another sample does this, I don't know. So in conclusion, the sample is targeting specifically the R600 VPN router, which is a SOHO router. The sample is looking for a specific IP address and is grabbing a modless of an HTTP information. The sample cannot modify traffic without a significant code rewrite, but we have, as Patrick said, we've observed other samples that are able to modify traffic. So thanks for coming to talk. Hope you guys enjoyed it. I just want to reinforce, it's very, very targeted. Just that model of device. You have to give it the destination IP address. It's logging just the source IP and source port of mod bus traffic, nothing else. And it's got a bunch of filters in place that discard a lot of the HTTP auth stuff. And it's storing the whole packet. But the filters in place will ensure that only a few of the packets that contain HTTP authentication stuff actually get saved. So the question is, in what environment are you going to find this router? And what ICS device would be on the, like, the target of this? Where somebody would be on one side of this router and be an ICS device on the other? And both mod bus traffic and HTTP traffic are passing to the same device, because the IP address is given as an argument when the module is run. So that is the question of the day. Where is this device being used? And what ICS device receives mod bus traffic and gets authentication over HTTP? We'll take questions. I was wondering, is it common at all for ICS type environments to use so-called routers? Is that been found? Is that possible that the attackers have a very specific configuration in mind they're going for somewhere that uses that sort of setup? So in this case, like, this is obviously intended to target either a specific individual or a specific group that does things a certain way. This specific module isn't going to work on any of the other. It won't work as a plugin to stage two on a different device. It only works on the TP-Link R600 VPN. And it only, like, you have to give it that destination IP before to log anything. So when the actor dropped this, it's obvious that they were looking for certain stuff and only certain stuff, because it filters out everything else, even things that would be valuable, like other HTTP credentials. They might be, I mean, it's hard to say, but they might have had something specific in mind. Yeah. And whether or not this device should be an ICS environment, no. But whether or not it is, yeah. So I think some bigger, like, low-comies and stuff, back home, the ICS, can you really see that setup? What type of, I would like to, and this is, you know, for you guys, if you can think of any field devices that maybe, you know, what the actor was looking to receive the information about, if you wanted, let me know, let me know. Otherwise, yeah. It's not, it's not like a module for another, you know, like industrial-hard type device. What do you mean? Well, you know, like, did they use that same core in another, like, industrial-hard device? But the TP-Link? Not to my knowledge. It's just that, yeah, as far as I know. And it's that weird, like Carlos said, it's that lecture architecture. So as we were writing our own proof of concept code and executing it on the device, it was, we were getting psych faults all day long. And it turns out we needed a custom tool chain to compile code for this device. So it's not like it's, you know, the code may be portable, but it's still got to be compiled specifically for this. I don't know of any, and there's strings in the code, in the binary that say R600 VPN. You know, so even if there was something else that, you know, using that border, right? Yeah. So just to be clear, is everything packet that travels through it? It looks at every packet that travels through it, and then it goes through the checks that Carlos explained to filter out the stuff that it doesn't want. And if it meets all the checks for MABUS, it just logs stuff that it already knew. Like, it knows the destination IP because it's an argument that was passed to it. When the module was executed, it doesn't log any of the MABUS data. It just, the IP address that the traffic came from and the port that it came from, and the IP address that it was going to, which we know, and port 502, which we know. So the only thing the actor learns that's new is source port and source IP. And then any HTTP traffic that meets all those filters going to the same IP address as the MABUS is going to, it'll log that entire packet. So in this instance, I would imagine they either did it manually, especially because since it's so targeted, or there may have been capability at the C2 node, it would connect and pull, right? No, stage two had the ability to execute shell commands. So it would be just like you're logged into the terminal as Linux root. Nothing has stood out at the time, but we have the map in slides. We can put it up on there. And if you can zoom into it. Most of the U.S., almost 900 in the U.S., 600 in Russia, Brazil, Ireland, Uruguay. And this is just specifically the TP-Link R600 VPN with remote management enabled. Oil and gas. Not a lot of evidence, it's not a lot of evidence. Right. No, it's not. Yes sir, pieces of the breadcrumbs together. Follow the breadcrumbs, you'll have pieces of it. Yes sir. Do you think of a whole box? Yes, so anybody that knows what that SIN packet is, can own any device that is in that passive raw socket mode. So you just have to send a SIN that has the right magic bytes, and then it's going to pull out an IP address, and it's going to reach out and you're going to have to deliver stage two to it. But if you know, so yeah, you could do it. For this module, because it's set up to just log the data about what goes through, it would need to be seriously modified to intercept. So instead of just looking at the packet and allowing it to go through, it's going to have to stop it, change it, pass it through. This module doesn't have any capability to do that. But that other module does, so they definitely have the ability to modify traffic. This module does not, but it's still possible. How alarming is this behavior? Has there been any sort of effort to go out? Like have you seen this router to potential industrial space and anything? Or is it kind of still a pretty passive collection? I'm here asking you guys. It's intriguing because it's so targeted, but because of the wide range of vendors and devices that were also known to be used, this type of activity could be used on any of those other devices. They just have to pile up for the device and push it out. So it depends on which stage it's in and what device it is. There's a whole bunch of weird ways to figure it out. If it's in that raw socket mode, you can detect it. So I rushed out of the script a few weeks ago. It's up on GitHub where it'll send the send packet and it'll reach out to an IP that the script gives. Also, I think once it's done, somebody correct me if I'm wrong. It's a tool that would let you know if I think it'd be a stage 2. That's it. Alright, well, yes? You mentioned that you found a module. Did you define that destination might be configured? Or did you just have a module? Just a module. I did my thing just to get live devices. If you have live devices established connection to command and control, they just never had that module pushed out. So one of the interesting things about the Stage 3 modules, the device has to be tasked to pull them down. There's no list of modules in Stage 2 that you have to know the name of the module. The device has to be told, reach out and get this module and it will reach out to command and control request the module, retrieve it, and execute it. I'd like to be able to say, I just requested all the modules from command and control without knowing the names of them. They could have had it and we never saw it. They were selective about what they deployed and where they deployed it. Saw another hand. What did you do? You got a virus code on 2.16? This module did, yes. Did somebody upload it in firmware? So this specific binary is ElfXQ, so LinuxXQ, and they uploaded that XQ. Did you ask the virus code to upload it? I mean, should be able to do that. I'm just wondering how they would have got it? I would love to know. I would love to know who uploaded it. So in order to get off of the device, you've got to own the device. Some of the older TV link R600 had basically a backdoor web shell that was known. Somebody could have used that and saw that they were infected, pulled it off and uploaded it. Some people work tradecraft, it's a little... Everybody's been known to make mistakes. Other than that, it would have had either been pulled out of never traffic and uploaded, pulled off the device and uploaded, or uploaded by the actor. I would love to hear ideas and scenarios and this is just one of countless modules. So we know how many we've seen but theoretically it's up to the actor to write it and push it out to their plugins. So that's one thing I don't know if you've mentioned it or not, but... Yeah, so it's in their own possible that the actor put that in there to kind of distract you.  You know? Yeah, exactly. That's what I went to over here, right? Right. Were they really looking at my bus or they want us to think they were looking at my bus? I don't know. If you guys know, I'll buy you a beer. The sample? Well, I mean, if you have paid a comment by yourself you don't have access to all that stuff. So anybody in this room could search. So Talos is working with several partners, and that's one of those things that I'm not going to get into. But the blog post that initially disclosed this will tell you as much as we're comfortable releasing. But we work with people outside of Talos. So if you have any... Sure. I don't remember the VPN function in that. I don't remember. I'm pretty sure it was just using open VPN. It was busy box and I opened SSL and open VPN. I'm pretty sure. I'll double check. But if anybody has any other questions or follow-ups you can just send me or Carl us up here or afterwards. And in my result we specified admin for life one-to-one as this nature the module can see basic authentication provision as an IP address. So if you specify any IP address as the destination IP address and then if the traffic passes through it'll log the actual credentials going to that IP. And that is that what you're saying you found? We think there's a couple. Yeah. So it can take three parameters or arguments but it only takes two. So what's the third? What was the other? So it'll accept it'll log the traffic. It said if it has HTTP basic authorization or a username and password combination but at both are present it ignores it. So I mean there were a few things where my theory was that they were eliminating as much noise as possible because if you start logging everything that matches HTTP basic auth and everything that matches Modbus the device is going to fill up and you're going to have a brick. So you want to filter out everything except what they were specifically looking for. That's just my theory. And yeah, I think there's a couple of cool things to do. Thank you. Appreciate it.